On Thursday 07 May 2015 11:32 AM, Vineet Gupta wrote:
> Hi Greg,
> 
> Upstream commit e4140819dadc3624accac8294881bca8a3cba4ed, "ARC: signal 
> handling
> robustify" was marked for stable inclusion. It made it into 3.18 but not 
> earlier
> likely due to interim changes preventing a clean merge.
> 
> Could you please queue up the fixed up patch below for 3.14 and earlier 
> friends...
> 
> Thx,
> -Vineet

Hi Greg,

Ping !

Thx,
-Vineet

> 
> ------------>
> From 6dee6ad027ec4a26eaf29de6d03f04c9bcf9a79e Mon Sep 17 00:00:00 2001
> From: Vineet Gupta <vgu...@synopsys.com>
> Date: Thu, 26 Mar 2015 11:14:41 +0530
> Subject: [PATCH] ARC: signal handling robustify
> 
> A malicious signal handler / restorer can DOS the system by fudging the
> user regs saved on stack, causing weird things such as sigreturn returning
> to user mode PC but cpu state still being kernel mode....
> 
> Ensure that in sigreturn path status32 always has U bit; any other bogosity
> (gargbage PC etc) will be taken care of by normal user mode exceptions 
> mechanisms.
> 
> Reproducer signal handler:
> 
>     void handle_sig(int signo, siginfo_t *info, void *context)
>     {
>       ucontext_t *uc = context;
>       struct user_regs_struct *regs = &(uc->uc_mcontext.regs);
> 
>       regs->scratch.status32 = 0;
>     }
> 
> Before the fix, kernel would go off to weeds like below:
> 
>     --------->8-----------
>     [ARCLinux]$ ./signal-test
>     Path: /signal-test
>     CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65
>     task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000
> 
>     [ECR   ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698
>     [EFA   ]: 0x00000010
>     [BLINK ]: 0x2007c1ee
>     [ERET  ]: 0x10698
>     [STAT32]: 0x00000000 :                                   <--------
>     BTA: 0x00010680    SP: 0x5ffe7e48  FP: 0x00000000
>     LPS: 0x20003c6c   LPE: 0x20003c70 LPC: 0x00000000
>     ...
>     --------->8-----------
> 
> Reported-by: Alexey Brodkin <abrod...@synopsys.com>
> Cc: <sta...@vger.kernel.org> #3.14, 3.12
> Signed-off-by: Vineet Gupta <vgu...@synopsys.com>
> ---
>  arch/arc/kernel/signal.c | 20 ++++++++++++++++----
>  1 file changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arc/kernel/signal.c b/arch/arc/kernel/signal.c
> index d68b410595c8..a0c63fc48457 100644
> --- a/arch/arc/kernel/signal.c
> +++ b/arch/arc/kernel/signal.c
> @@ -131,6 +131,15 @@ SYSCALL_DEFINE0(rt_sigreturn)
>       /* Don't restart from sigreturn */
>       syscall_wont_restart(regs);
> 
> +     /*
> +      * Ensure that sigreturn always returns to user mode (in case the
> +      * regs saved on user stack got fudged between save and sigreturn)
> +      * Otherwise it is easy to panic the kernel with a custom
> +      * signal handler and/or restorer which clobberes the status32/ret
> +      * to return to a bogus location in kernel mode.
> +      */
> +     regs->status32 |= STATUS_U_MASK;
> +
>       return regs->r0;
> 
>  badframe:
> @@ -234,8 +243,11 @@ setup_rt_frame(int signo, struct k_sigaction *ka, 
> siginfo_t
> *info,
> 
>       /*
>        * handler returns using sigreturn stub provided already by userpsace
> +      * If not, nuke the process right away
>        */
> -     BUG_ON(!(ka->sa.sa_flags & SA_RESTORER));
> +     if(!(ka->sa.sa_flags & SA_RESTORER))
> +             return 1;
> +
>       regs->blink = (unsigned long)ka->sa.sa_restorer;
> 
>       /* User Stack for signal handler will be above the frame just carved */
> @@ -302,12 +314,12 @@ handle_signal(unsigned long sig, struct k_sigaction *ka,
> siginfo_t *info,
>             struct pt_regs *regs)
>  {
>       sigset_t *oldset = sigmask_to_save();
> -     int ret;
> +     int failed;
> 
>       /* Set up the stack frame */
> -     ret = setup_rt_frame(sig, ka, info, oldset, regs);
> +     failed = setup_rt_frame(sig, ka, info, oldset, regs);
> 
> -     if (ret)
> +     if (failed)
>               force_sigsegv(sig, current);
>       else
>               signal_delivered(sig, info, ka, regs, 0);
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to