All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Mathias Krause <minipli@googlemail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org,
	Brad Spengler <spender@grsecurity.net>,
	PaX Team <pageexec@freemail.hu>
Subject: Re: [PATCH] posix-timers: fix stack info leak in timer_create()
Date: Sun, 5 Oct 2014 23:06:14 +0200	[thread overview]
Message-ID: <20141005210614.GA28899@redhat.com> (raw)
In-Reply-To: <1412456799-32339-1-git-send-email-minipli@googlemail.com>

On 10/04, Mathias Krause wrote:
>
> If userland creates a timer without specifying a sigevent info, we'll
> create one ourself, using a stack local variable. Particularly will we
> use the timer ID as sival_int. But as sigev_value is a union containing
> a pointer and an int, that assignment will only partially initialize
> sigev_value on systems where the size of a pointer is bigger than the
> size of an int. On such systems we'll copy the uninitialized stack bytes
> from the timer_create() call to userland when the timer actually fires
> and we're going to deliver the signal.

So we have a minor information leak,

> Cc: <stable@vger.kernel.org>	# v2.6.28+

not sure this is -stable material but I won't really argue.

> --- a/kernel/time/posix-timers.c
> +++ b/kernel/time/posix-timers.c
> @@ -636,6 +636,7 @@ SYSCALL_DEFINE3(timer_create, const clockid_t, which_clock,
>  			goto out;
>  		}
>  	} else {
> +		memset(&event.sigev_value, 0, sizeof(event.sigev_value));
>  		event.sigev_notify = SIGEV_SIGNAL;
>  		event.sigev_signo = SIGALRM;
>  		event.sigev_value.sival_int = new_timer->it_id;

How about

	-	event.sigev_value.sival_int = new_timer->it_id;
	+	event.sigev_value = (sigval_t) { .sival_int = new_timer_id };

?

(btw, new_timer->sigq->info.si_tid initialization can use new_timer_id too)

this makes the initialization more explicit and can help gcc to optimize
this assignment although this is minor.

In any case this all looks confusing to me. sys_timer_create() does

	new_timer->sigq->info.si_value = event.sigev_value;
	new_timer->sigq->info.si_tid   = new_timer->it_id;

later, this writes to the differents members (_rt and _timer) in the
same union. But the comment in struct siginfo says that we should use
_timer. And copy_siginfo_to_user() reports si_tid and si_ptr, this
again reads _timer and _rt. This should actually work, _sigval should
have the same offset in both struct's, still it looks confusing imho.
Perhaps we should change

	#define si_value	_sifields._rt._sigval
	#define si_int		_sifields._rt._sigval.sival_int
	#define si_ptr		_sifields._rt._sigval.sival_ptr

to use _timer instead. Nevermind, this is off-topic.

Oleg.


  reply	other threads:[~2014-10-05 21:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-04 21:06 [PATCH] posix-timers: fix stack info leak in timer_create() Mathias Krause
2014-10-05 21:06 ` Oleg Nesterov [this message]
2014-10-05 21:24   ` Thomas Gleixner
2014-10-05 21:54   ` Mathias Krause
2014-10-05 22:28     ` Oleg Nesterov
2014-10-25  8:45 ` [tip:timers/urgent] posix-timers: Fix " tip-bot for Mathias Krause

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=20141005210614.GA28899@redhat.com \
    --to=oleg@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=minipli@googlemail.com \
    --cc=pageexec@freemail.hu \
    --cc=spender@grsecurity.net \
    --cc=tglx@linutronix.de \
    /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.