All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>, Aleksa Sarai <asarai@suse.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	linux-s390@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org
Subject: Re: siginfo memory leak?
Date: Mon, 23 May 2016 14:43:19 +0200	[thread overview]
Message-ID: <20160523144319.7579e75f@mschwide> (raw)
In-Reply-To: <20160523111630.GN2278@dhcp22.suse.cz>

On Mon, 23 May 2016 13:16:30 +0200
Michal Hocko <mhocko@kernel.org> wrote:

> Hi,
> Aleksa has reported that strace tells a bogus si_errno while debugging
> something on s390:
> [pid 20799] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_errno=2510266, si_addr=0x100000000000000}

That is a bug.
 
> A quick look into do_sigsegv shows that siginfo is not completely
> initialized and it indeed might leak the previous stack content
> which will later gets to userspace. So unless I am missing something
> we need something like the trivial patch below. I have tried to look
> around and it seems that this is not the only place...

Indeed, for s390 four bytes of the kernel stack gets leaked to user space.
That needs fixing.

> x86 do_error_trap doesn't do any initialization at all! It is hard to
> tell other places. I have checked some and most of them do some
> (partial) initialization.
> 
> So my primary question is whether we want to fix all those potential
> places one by one or come up with something more systematic (e.g. a
> macro to declare on stack siginfo). Btw. I am not even sure partial
> initializations are correct and memset should be used unconditioanlly
> (e.g. fill_sigtrap_info does do that).
> ---
> diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
> index 791a4146052c..41913fac14e4 100644
> --- a/arch/s390/mm/fault.c
> +++ b/arch/s390/mm/fault.c
> @@ -248,6 +248,7 @@ static noinline void do_sigsegv(struct pt_regs *regs, int si_code)
>  	si.si_signo = SIGSEGV;
>  	si.si_code = si_code;
>  	si.si_addr = (void __user *)(regs->int_parm_long & __FAIL_ADDR_MASK);
> +	si.si_errno = 0;
>  	force_sig_info(SIGSEGV, &si, current);
>  }
> 

The other for place where s390 calls force_sig_info are correct.
Only do_sigsegv misses the clear of si_errno.

> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index ade185a46b1d..f8b66ddbb47d 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -286,6 +286,7 @@ static void do_error_trap(struct pt_regs *regs, long error_code, char *str,
> 
>  	if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, signr) !=
>  			NOTIFY_STOP) {
> +		memset(&info, 0, sizeof(info));
>  		conditional_sti(regs);
>  		do_trap(trapnr, signr, str, regs, error_code,
>  			fill_trap_info(regs, signr, trapnr, &info));
> 

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

  reply	other threads:[~2016-05-23 12:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-23 11:16 siginfo memory leak? Michal Hocko
2016-05-23 12:43 ` Martin Schwidefsky [this message]
2016-05-23 13:05   ` Michal Hocko
2016-05-23 13:29     ` Martin Schwidefsky
2016-05-23 13:34       ` Michal Hocko
2016-05-23 13:43 ` [PATCH] s390: fix info leak in do_sigsegv Michal Hocko
2016-05-23 13:43   ` Michal Hocko
2016-05-23 14:47   ` Martin Schwidefsky
2016-05-23 13:54 ` [PATCH] x86: fix potential memleak in do_error_trap Michal Hocko
2016-05-23 13:54   ` Michal Hocko
2016-05-23 15:33   ` Oleg Nesterov
2016-05-23 17:47     ` Michal Hocko
2016-05-23 15:42 ` siginfo memory leak? Oleg Nesterov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160523144319.7579e75f@mschwide \
    --to=schwidefsky@de.ibm.com \
    --cc=asarai@suse.de \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mhocko@kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.