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 >= 220.127.116.11, 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.