Re: ARC stable backport for 3.14 and earlier

[Luis Henriques]

On Thu, May 07, 2015 at 06:02:03AM +0000, 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...
>

Thank you, I'll use this backport to the 3.16 kernel as well.

Cheers,
--
Luís

> Thx,
> -Vineet
> 
> ------------>
> From 6dee6ad027ec4a26eaf29de6d03f04c9bcf9a79e Mon Sep 17 00:00:00 2001
> From: Vineet Gupta <vgupta@xxxxxxxxxxxx>
> 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 <abrodkin@xxxxxxxxxxxx>
> Cc: <stable@xxxxxxxxxxxxxxx> #3.14, 3.12
> Signed-off-by: Vineet Gupta <vgupta@xxxxxxxxxxxx>
> ---
>  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);
> -- 
> 1.9.1
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/