|Main Archive Page > Month Archives > oss-security archives|
A bug I found was just fixed upstream:
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 >= 18.104.22.168, 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
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
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.