[<prev] [next>] [day] [month] [year] [list]
Message-ID: <AANLkTi=oSq49eLutF_mq05khnN3cikXyFqgQFr-Jk=-E@mail.gmail.com>
Date: Fri, 24 Sep 2010 16:05:44 -0400
From: Dan Rosenberg <dan.j.rosenberg@...il.com>
To: oss-security@...ts.openwall.com
Subject: Interesting kernel bug
A bug I found was just fixed upstream:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=767b68e96993e29e3480d7ecdd9c4b84667c5762
Disregard the commit statement's mention of a reliable trigger, since
none exists - a result of a combination of miscommunication and
careless reporting on my part.
The bug was introduced in May 2010, and affects >= 2.6.34.1, so no
distros would appear to be affected. In 32-bit compatibility mode,
when invoking the readv() or writev() syscalls, if the provided user
pointer and length result in an access_ok() check failing, then an
uninitialized pointer on the stack will be kfree()'d. This is likely
to be an exploitable condition (for example, via pre-initializing the
stack with other carefully chosen syscalls, allowing control of the
pointer).
It came up during discussion that on x86-64, the access_ok() will
never fail, because there's no way for a user running in 32-bit mode
to supply an address that's outside of userspace address range.
However, it's possible that this may be triggerable on other
architectures that I know less about. S390 was mentioned at one
point.
Anyone who knows more about miscellaneous architectures and their
address space segmentations? Perhaps it affects someone after all.
As of now, I don't think this could be considered a security issue
since it appears to be completely not exploitable, but maybe someone
more knowledgeable could shed more light on the issue.
-Dan
Powered by blists - more mailing lists
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.
