lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 28 Mar 2008 13:51:38 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Arjan van de Ven <arjan@...ux.intel.com>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	NetDev <netdev@...r.kernel.org>, Dmitry Torokhov <dtor@...l.ru>
Subject: Re: Oops/Warning report for the week of March 28th 2008



On Fri, 28 Mar 2008, Linus Torvalds wrote:
> 
> Is there something obvious that I'm missing? I'd really like to see the 
> whole posting that the oops came from. Do you save the originals or even 
> just message ID's from the ones you pick from emails?

Hmm. Definitely not from the kernel mailing list. I'm intrigued, where did 
that oops #5814 come from (picked a recent one at random)?

The thing is recent, and oopses on "mutex_lock(dev->mutex)" in 
input_release_device. In particular, the path *seems* to be this one:

  evdev_release ->
    evdev_ungrab ->
      input_release_device ->
        mutex_lock ->
          mutex_lock_nested ->
            __mutex_lock_common ->
              list_add_tail(&waiter.list, &lock->wait_list)

where "lock->wait_list.prev" seems to be 0x6b6b6b6b6b6b6b6b, which is the 
use-after-free poison pattern.

(In fact, I think the access that actually oopses is when the 
debug version of __list_add() does

	if (unlikely(prev->next != next)) {

because that "prev" pointer is crap).

So it seems that when input_release_device() does:

	struct input_dev *dev = handle->dev;

	mutex_lock(&dev->mutex);

the "dev" it uses has already been released. And this only shows up as a 
problem when you have slab debugging turned on (like the Fedora kernels 
do, thank you all Fedora guys).

The odd thing is that I don't think any of this code has really changed 
recently. 

			Linus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ