Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 8 Dec 2010 07:51:18 +0300
From: Solar Designer <>
Subject: Re: kernel: Dangerous interaction between clear_child_tid, set_fs(), and kernel oopses

Nelson, Dan, Steve -

It's been a few days, so I'll over-quote a little bit.  Please see below:

On Thu, Dec 02, 2010 at 12:21:14AM -0500, Nelson Elhage wrote:
> I've discovered an interesting interaction in the Linux kernel between the
> clear_child_tid feature of clone(2), and the set_fs() function used internally
> in the kernel to temporarily disable access_ok() checking of userspace pointers.
> Under some (not totally uncommon) circumstances, it is possible for a user to
> leverage this interaction to turn a kernel oops or BUG() into a write of an
> integer 0 to a user-controlled address in kernel memory.
> I'm not sure if this merits a CVE or not; It is (as far as I can tell) only a
> problem in the presence of another security bug, but it potentially makes a
> large class of bugs significantly more dangerous (DoS -> privesc).
> Reference:

To me, things like this are more important than individual NULL pointer
dereference bugs or the like.  So if those get CVEs, this one definitely
should as well.

Nelson - why are you proposing adding set_fs(USER_DS); not to the very
beginning of do_exit(), but below a few calls/checks?  I don't think
there's any performance improvement from that, and it feels
"theoretically safer" to return to the sane/safe state as soon as
possible.  I am currently looking at do_exit() in OpenVZ's RHEL5-based
2.6.18-194.26.1.el5.028stab079.1 - it does a bit more work before
reaching the place you patch.  So I am tempted to introduce
set_fs(USER_DS); as the very first statement in do_exit() instead.

Did you check whether 2.4 kernels are affected as well?



Powered by blists - more mailing lists

Your e-mail address:

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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ