Linux 3.4+: arbitrary write with CONFIG_X86_X32 (CVE-2014-0038)

[barrkel]

This might be useful context:

http://en.wikipedia.org/wiki/X32_ABI

an application binary interface project for Linux that allows programs to take advantage of the benefits of x86-64 (larger number of CPU registers, better floating-point performance, ... ) while using 32-bit pointers and thus avoiding the overhead of 64-bit pointers

[userbinator]

So in other words, it's a 32-bit address space in 64-bit mode? I thought that wasn't possible with x86-64... in fact the biggest mistake I think with x86-64, after some(admittedly not much) reading of the manuals is that it wasn't like the 16/32-bit where you could independently choose the default operand and address sizes, and use 32-bit addresses or registers in 16-bit mode and vice-versa.

[lelf]

    -       if (get_compat_timespec(&ktspec, timeout))
    +       if (compat_get_timespec(&ktspec, timeout))
                    return -EFAULT;

Sigh

[saintdev]

On the plus side, hardly anybody uses x32 ABI.

[akerl_]

Unfortunately, it looks like Ubuntu just recently enabled it in their kernels:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1274754

[jlgaddis]

While we sometimes get laughed at for not running the latest and greatest, I am (once again) quite glad that I'm running RHEL 5 and 6 and their 2.6.18 and 2.6.32 kernels.

[sspiff]

I'm not sure you noticed, but this doesn't affect any popular distro. It only affects the kernels build with the X32 ABI, which is not used in production by anyone as far as I can tell. So the fact that you're running old kernels didn't prevent anything this time.

[jasonzemos]

Those are patched against the myriad of bugs and vulnerabilities from the last 8 years... haha?

[jjjeffrey]

At the bottom there are two lines that taken together really confuse me:

    <grsecurity> If you're running Linux 3.4 or newer and enabled CONFIG_X86_X32 , you need to disable it or update 
    immediately; upstream vuln CVE-2014-0038

and

    <grsecurity> In case there's confusion, this vuln is not about 32bit userland on 64bit (CONFIG_X86_32), but the new X32 
    ABI.  Ubuntu enables it recently

Does the second line affect the first? EDIT: I ask because it looks like I need to fix my kernel, but I'd rather be lazy if possible.

[elwin]

CONFIG_X86_X32 and CONFIG_X86_32 are different.

The first one, with the second X, enables the new X32 ABI. The second one, without the second X, is the "32bit userland on 64bit".

[harshreality]

x32 is a separate abi, distinct from the normal 64-bit and 32-bit abis.

Most distros don't use it, most don't even offer an x32 install image, but if they enable the kernel option for the x32 abi even without intending to use it, they're vulnerable.

If you're using the x32 abi, either you're using it on purpose, or your distro happens to offer an x32 install image and you downloaded it by accident instead of the normal 32-bit image you probably wanted. In all other cases it should be safe enough to disable the kernel option.

[lambda]

Does "grep CONFIG_X86_X32 /boot/config-`uname -r`" give you any results which aren't commented out? If it does, you're at risk; if not, nothing to worry about (at least, with regards to this vulnerability).

[akerl_]

Has anyone seen talk of this leading to an expedited 3.13.2/3.12.10 release? If I need to manually patch my kernels to fix this, I'll do it, but if upstream is going to release fixed versions shortly, that seems like the preferable solution.

So far though, I haven't seen anything about merging in the patch provided by PaX.

[nknighthb]

Are you actually using x32? I doubt most people are. It didn't even exist in a stable kernel until April 2012.

[ye]

Am I the only one shocked by the lack of comments in the code? It's literally a wall of code.

[barrkel]

How familiar are you with largish C codebases?

At this level, you're dealing with an API at the calling end (you should be fairly intimately familiar with the semantics without much reference to the docs if you're working on the implementation) and the functions being calling are almost readable as English.

Code should strive to be written such that it doesn't need comments unless it's being clever - and it should avoid being clever if possible.

Also, I'm not sure where you saw a "wall of code". I don't see any walls of code, not in the commit diff, nor in the smaller diff in the email. A wall of code, for me, would have to be long (say, 70+ lines - but it depends on the language) and dense (e.g. boolean expressions complex enough to need parentheses to clarify precedence).

[nightpool]

It looks perfectly readable to me, and I'm not even a big C guy. (Though I do have a general familiarity with it, and more with C++). Code shouldn't really need comments in most cases, especially if you're writing for people who are assumed to have a familiarity with the coding style/idioms used (such as boilerplate code for exploiting a memory vulnerability). (Not that I'm saying this is, I don't have enough C experience to say whether it is or not. It just seems reasonable to assume from context)

[asveikau]

Wall of code? The entire function shows up in a short diff. It looks like all it does is wrap other functions with nearly identical names.

It strikes me as kind of uninteresting glue code written for compatibility with a non-native ABI. The kind that gets repetitive if you're not terse.

[crististm]

I'm no longer shocked. You should see the comments in the kernel crypto API. Oh, there are none...