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]
Message-ID: <m1vclw1fx8.fsf@fess.ebiederm.org>
Date:	Thu, 22 Mar 2012 14:31:15 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Lucas De Marchi <lucas.demarchi@...fusion.mobi>
Cc:	Al Viro <viro@...iv.linux.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [3.3-rc7] sys_poll use after free (hibernate)

Lucas De Marchi <lucas.demarchi@...fusion.mobi> writes:

> On Sun, Mar 18, 2012 at 4:27 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>> On Sun, Mar 18, 2012 at 12:02:04PM -0700, Linus Torvalds wrote:
>>> and that load is from
>>>
>>>     poll_wait(filp, &table->poll->wait, wait);
>>>
>>> where the testing of %rsi and %rcx are the "if (p && wait_address)"
>>> check in poll_wait(), and %rsi is "table->poll" if I read it all
>>> correctly.
>>>
>>> And the 6b6b6b6b6b6b6b6b pattern is obviously POISON_FREE, so
>>> apparently 'table' has already been freed.
>>>
>>> I suspect the whole sysctl 'poll' code is seriously broken, since it
>>> seems to depend on those ctl_table pointers being stable over the
>>> whole open/close sequence, but if somebody unregisters the sysctl,
>>> it's all gone. The ctl_table doesn't have any refcounting etc, and I
>>> suspect that your hibernate sequence ends up unregistering some sysctl
>>> (perhaps as part of a module unload?)
>
> How could that happen if the only files that support poll  right now
> on sysctl are kernel/hostname and kernel/domainname?
>
>>
>> Ewww...  The way it was supposed to work (prio to ->poll() madness) was
>> that actual IO gets wrapped into grab_header()/sysctl_head_finish()
>> pair.  proc_sys_poll() doesn't do it, so yes, that post-mortem is
>> very likely to be correct.
>
> Yes, it  seems like I forgot to call grab_header() there, sorry for
> that. I'll prepare a patch and send you later today. I just wonder
> what is happening to reach that code... :-/

It looks like it was a combination of the fuzzer doing silly things
and a removed ctl_table entry being poisoned and having .poll set
to 6b6b6b6b6b6b6b6b so the guard against calling poll when it is
nonsense did not trigger.  So your patch should be sufficient
for now.

Long term we still need a version of poll that is safe to use
with modules.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ