Bad code path in DoSyscall

Bad code path in DoSyscall

[John Whitney]

There seems to be a bad code path in the assembly routine DoSyscall()
(arch/ppc/kernel/entry.S).  In the case of an invalid syscall being made (in
my case, from user space), DoSyscall is called and eventually branches to
label 66.  Note that before the branch, r12 is set to zero.

_GLOBAL(DoSyscall)
    stw r0,THREAD+LAST_SYSCALL(r2)
    stw r3,ORIG_GPR3(r1)
    li  r12,0
    stw r12,RESULT(r1)
    lwz r11,_CCR(r1)    /* Clear SO bit in CR */
    rlwinm  r11,r11,0,4,2
    stw r11,_CCR(r1)
#ifdef SHOW_SYSCALLS
    bl  do_show_syscall
#endif /* SHOW_SYSCALLS */
    cmpli   0,r0,NR_syscalls
    bge-    66f

Code at label 66 sets ENOSYS, and branches to label 22.

66: li  r3,ENOSYS
    b   22b

Code after label 22 presumes that r12 is set to the current thread, and
tries to access off of it:

22: lwz r10,_CCR(r1)    /* Set SO bit in CR */
    oris    r10,r10,0x1000
    stw r10,_CCR(r1)

    /* disable interrupts so current_thread_info()->flags can't change */
30: LOAD_MSR_KERNEL(r10,MSR_KERNEL) /* doesn't include MSR_EE */
    SYNC
    MTMSRD(r10)
    lwz r9,TI_FLAGS(r12)

Which immediately causes a bad page fault kernel oops.  I haven't come up
with a patch yet, but will try to when I get the time unless someone with
more knowledge in this area wants to do it.  Just wanted to let the list
know about the problem.

John Whitney
TimeSys corporation


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Bad code path in DoSyscall

[Matt Porter]

On Mon, Nov 10, 2003 at 10:56:08AM -0500, John Whitney wrote:
>
> There seems to be a bad code path in the assembly routine DoSyscall()
> (arch/ppc/kernel/entry.S).  In the case of an invalid syscall being made (in
> my case, from user space), DoSyscall is called and eventually branches to
> label 66.  Note that before the branch, r12 is set to zero.

<snip>

>     /* disable interrupts so current_thread_info()->flags can't change */
> 30: LOAD_MSR_KERNEL(r10,MSR_KERNEL) /* doesn't include MSR_EE */
>     SYNC
>     MTMSRD(r10)
>     lwz r9,TI_FLAGS(r12)
>
> Which immediately causes a bad page fault kernel oops.  I haven't come up
> with a patch yet, but will try to when I get the time unless someone with
> more knowledge in this area wants to do it.  Just wanted to let the list
> know about the problem.

Thanks, here's a patch to grab the thread info when you go down the
no syscall path. This should cure the problem.

It's against linuxppc-2.5.  I think that's what you meant since this
bug isn't in 2.4.

-Matt

===== arch/ppc/kernel/entry.S 1.40 vs edited =====
--- 1.40/arch/ppc/kernel/entry.S        Sat Sep 27 03:58:48 2003
+++ edited/arch/ppc/kernel/entry.S      Mon Nov 10 09:36:55 2003
@@ -234,6 +234,7 @@
        RFI

 66:    li      r3,ENOSYS
+       rlwinm  r12,r1,0,0,18   /* current_thread_info() */
        b       22b

        .globl  ret_from_fork

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Bad code path in DoSyscall

[Paul Mackerras]

John Whitney writes:

> There seems to be a bad code path in the assembly routine DoSyscall()
> (arch/ppc/kernel/entry.S).

You're right, good catch.  The patch below should fix it.

Paul.

diff -urN linux-2.5/arch/ppc/kernel/entry.S pmac-2.5/arch/ppc/kernel/entry.S
--- linux-2.5/arch/ppc/kernel/entry.S	2003-09-27 19:46:43.000000000 +1000
+++ pmac-2.5/arch/ppc/kernel/entry.S	2003-11-11 09:29:34.000000000 +1100
@@ -233,8 +233,8 @@
 	SYNC
 	RFI

-66:	li	r3,ENOSYS
-	b	22b
+66:	li	r3,-ENOSYS
+	b	ret_from_syscall

 	.globl	ret_from_fork
 ret_from_fork:

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/