oss-security - Re: CVE request: vulnerability in the kernel tty subsystem.

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150526145247.GB23156@kroah.com>
Date: Tue, 26 May 2015 07:52:47 -0700
From: Greg KH <greg@...ah.com>
To: oss-security@...ts.openwall.com
Cc: cve-assign@...re.org
Subject: Re: CVE request: vulnerability in the kernel tty
 subsystem.

On Tue, May 26, 2015 at 02:18:53AM -0400, Wade Mealing wrote:
> Gday,
> 
> An issue was discovered in the linux kernel's tty subsystem handling during shutdown. The
> flaw was that a new tty thread could hold a reference to the ldisc lock used during
> the shutdown phase in the original thread and create a deadlock.
> 
> This race occurs on hangup of tty.  It races and hangs on ldsem_down_write on a semaphore 
> that is being aquired by a new reader(CPU 1).  The new reader/writer is sleeping
> in ldsem_down_read() and the hangup is sleeping in ldsem_down_write().
> 
> The deadlock can occur under these conditions.
> 
>    CPU 0                                   |  CPU 1
> 					   |
> _raw_spin_unlock_irq                       | _raw_spin_unlock_irq+0x24/0x26
> down_write_failed                          | down_read_failed+0xe3/0x1b9
> ldsem_down_write <-- here                  | ldsem_down_read  <--- here
> tty_ldisc_lock_pair_timeout                | tty_ldisc_ref_wait
> tty_ldisc_lock_pair_timeout                | tty_write
> tty_ldisc_hangup                           | redirected_tty_write
> __tty_hangup                               | tty_write
> disassociate_ctty                          | o_loop_readv_writev
> do_exit                                    | do_readv_writev
>                                            | SyS_writev
> 
> 
> This section of code was re-written upstream by creating a read/write semaphore to
> specially to handle ldisc, ldsem ( 4898e640caf03fdbaf2122d5a33949bf3e4a5b34 ).  
> 
> This issue was reproduced on a system under load when testing the reproducer for
> CVE-2014-0196, on a system that already has this issue fixed.  No root permissions
> are required to recreate the deadlock.
> 
> I would like to request a CVE for this issue.

For a 2 year old bugfix?

I know you all like to try to track bugs for old and obsolete products,
but really, there's no end of CVEs you could request if you wish to do
this.  Heck, I could start asking for multiple CVEs for every single
stable kernel release I do, which would just be pointless.

Please just mark this as a "oh look, a bug was fixed years ago and we
need to backport it because we have old kernels out in the wild and our
customers don't like to upgrade" type issue.  Don't force CVEs to play
by the odd enterprise rules that you all wish perpetuate.

thanks,

greg k-h

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.