A nasty local kernel vulnerability

{"My Kernel", 57, VOIDP(<addr of perpare_kernel_cred>), VOIDP(<addr of commit_creds>)}

I haven't read through the entire exploit so the 57 may need to be changed to something else but it might not need to be since it stays the same across kernel versions.

Also to get the addresses of prepare_kernel_cred and commit_creds just grep those symbols in your System.map under boot. Example: grep prepare_kernel_cred /boot/System.map.mykernel

Assuming the code in shellcode.c is the only shellcode being used (which once again I haven't read it all) it appears to change the creds structure of the running process. It does this by calling the function pointer they have to perpare_kernel_cred (kernel/cred.c) with NULL which will use the init cred which has a UID and GID of 0. It then uses the commit_creds function pointer it has with the new root creds structure to set the creds of the process to root.

I'm not about to run the exploit on my work machine so I'm not sure if the line I gave above will work 100% but its a start. This is what PaXTeam was getting at with his response to the other guy claiming you're safe if the exploit didn't print out a certain message. The exploitable bug may still be in your kernel. The issue is that the two magic numbers for function addresses weren't right. BTW you have the potential of kernel oopsing your box if you run the exploit with bad addresses and you happen to hit pages you shouldn't be touching.

This is the difference between an exploitable bug and a weaponized exploit. The bug is still there and just because this implementation/POC didn't work on your machine doesn't mean you're not vulnerable. PaXTeam and Brad may be harsh with their words but this is a very important point to get. Just because this example didn't work on your box doesn't mean you're not vulnerable. This could have just as easily have been written to scan kallsyms or a system.map based on information from uname to pull those addresses and work.