[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    [oss-security] Interesting kernel bug
From:       Dan Rosenberg <dan.j.rosenberg () gmail ! com>
Date:       2010-09-24 20:05:44
Message-ID: AANLkTi=oSq49eLutF_mq05khnN3cikXyFqgQFr-Jk=-E () mail ! gmail ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]