Dave Jones reported that he was able to provoke a machine check on ppc32 with his scrashme program, apparently as a result of missing access_ok checks on the arguments to the sys_debug_setcontext system call. In signal_32.c and signal_64.c there were other similar issues. Some of them are pretty serious. One of them will let an unprivileged user program read any kernel memory on ppc64 systems with Altivec. Both 32-bit and 64-bit kernels are affected and some of the problems go back to the 2.4 days. It appears that some of the people that did the original ppc64 port liked to do ret = put_user(&p->a); ret |= __put_user(&p->b); if (ret) return -EFAULT; which is of course *not* a good idea, although if (put_user(&p->a) || __put_user(&p->b)) return -EFAULT; is OK on ppc64 because of the large gap between TASK_SIZE and KERNELBASE.
Paul Mackerras revised his initial post and mentioned that those of the bogosities found that are in the 32-bit compatibility code for 64-bit kernels aren't actually security holes, since it isn't possible for a 32-bit process to generate a kernel address. That leaves: - a hole in the 64-bit kernel that lets unprivileged processes read (but not write) arbitrary kernel memory on systems that have Altivec. - a hole that lets processes on a 32-bit kernel restore their register set from an arbitrary kernel address (on signal return or with the sys_swapcontext or sys_debug_setcontext system calls). That only reads kernel memory and would be hard to exploit as a method of reading kernel memory since the program counter would be set to some hard-to-predict value. It could be used to crash the system though.
Marcel, the RHEL3 kernel does not contain support for debug_setcontext() or swapcontext() system calls, and the 32-bit-compat support is an entirely different code base from what's in 2.6. Could you please provide a definitive reproducer that shows there really is a vulnerability on RHEL3?
There exists no definitive reproduce. The scrashme from Dave produced only one of these issues and Paul went through the code the look for similar issues. I also realized that the PowerPC code in recent 2.6 kernels looks totally different and thus we might not have a problem at all, but Paul mentioned possible problems had been introduced back in 2.4 days. Since Paul also mentioned that the 32-bit compat issues are not a security problem and we only support 64-bit PowerPC, it comes down to the 64-bit Altivec issue. I am actually lost to decide if and how that is exploitable. If you think we are not affected by this issue then simply close the bug. We can reopen it once we have a real reproducer. I will forward this to vendor-sec once we have more details of the embargo time line and the final upstream fix. This might get us the needed reproducer.
I did another walk through the patch. We don't have debug_setcontext() and swapcontext() and so we don't need to worry about these two hunks for RHEL3. For the pSeries we patched it with Altivec support, but it seems that we don't actually support the problematic part for the 33 vec registers. So this shouldn't affect RHEL3 either. This leaves us with the changes from arch/powerpc/kernel/signal_32.c and you can find almost the same code in ppc64/kernel/signal32.c for RHEL3 in the sys32_sigaction() and sys32_rt_sigaction() action functions. These should be fixed, but they are not a security problem. So after all this issue doesn't affect RHEL3. However I am not a PowerPC expert and I like to see a second opinion before we close this bug.
There's lots of problems of this ilk in arch/ppc64/kernel/sys_ppc32.c -- at least get_flock(), put_flock(), nfs_*_trans(), do_sys32_*ctl(), msghdr_from_user32_to_kern(), before I stopped looking.
Sorry, the ones in sys_ppc32 aren't a security hole, as discussed.
We only have the issues in ppc64/kernel/signal32.c and these are also not exploitable as Paul already mentioned. So in the end non of these security issue affect RHEL3.