[0x0]

Can you back that up? The exploit states x86_64, and even if there is only an x86 exploit published, it's likely the same vulnerability is present on an x86_64 kernel (in general).

Lack of exploit code doesn't imply a lack of vulnerability :)

[ddalex_ro]

I mean, the fix consists in making sure that attr.config has all the 64 bits cleared - on the 64 bit machines, int is 64bit, so u64 == int, and all the bits are correctly handled. on 32 bit machines, int is 32bit, and the top 32 bit of attr.config is not cleared.

I may be wrong though, as I didn't scan through all the affected code.

[sd_]

It's not that hard to port it to 32 bits, just hang on week or two. I'm just too lazy.

IGjDf1e4eQxWyBFArYM8HgvCuns6p+GbfHoE3SPxYV59kXnA12BWdMr6D5eAAFgtBSX+/Yi+vLxMmEiszkwHLCA=

[rommelvr]

Hahaha. Love that you signed your message with your 'jewgold' address. Nice 0day.

[dfc]

Me too. I love latent antisemitism.

[ambiate]

The goto and labels stick out like coal in a pile of gold.

[sd_]

Duly noted. Will attempt to obfuscate using longjmp next time.

[edwintorok]

No, int is the same size on 32-bit and 64-bit Linux: sizeof(int) == 4 sizeof(long) == 4 (32-bit), 8 (64-bit) sizeof(long long) == 8

[ddalex_ro]

I learn something every day, thank you !

[jbaiter]

I just ran the exploit on a 64bit machine and it worked as expected, I got root privileges.

[ah-]

I just tried it on a 64bit machine and it works.

[papsosouid]

http://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_mo...