Re: ARC stable backport for 3.14 and earlier

From: Luis Henriques
Date: Mon May 11 2015 - 07:11:40 EST


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/