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);
which is of course *not* a good idea, although
if (put_user(&p->a) || __put_user(&p->b))
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
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