From: Oleg Nesterov <oleg@redhat.com>
To: "Amanieu d'Antras" <amanieu@gmail.com>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH] signal: Make the si_code check in rt_[tg]sigqueueinfo stricter
Date: Tue, 13 Oct 2015 16:54:39 +0200 [thread overview]
Message-ID: <20151013145439.GA19175@redhat.com> (raw)
In-Reply-To: <CA+y5pbRq8Fbt8HUuDEJGOi4i4fa2RLfF1Rt-O7GHYpOhL6tD=Q@mail.gmail.com>
On 10/12, Amanieu d'Antras wrote:
>
> On Mon, Oct 12, 2015 at 4:54 PM, Oleg Nesterov <oleg@redhat.com> wrote:
> > Yes, copy_siginfo_to_user() does __put_user((short)from->si_code).
> > But SI_FROMUSER/SI_FROMKERNEL are internal kernel checks, we mostly
> > use them in copy_siginfo_to_user().
> >
> > And note that if ->si_code < 0 we simply do __copy_to_user(), so
> > userspace can't see something which looks like "from kernel", in
> > this case we do not truncate ->si_code.
>
> Ah my bad, I seem to have missed that case. So copy_siginfo_to_user
> seems to be safe, but it is still an issue for copy_siginfo_to_user32
> which doesn't have this check.
>
> Maybe this should be fixed in the compat code instead?
I agree, this doesn't look right... But I'm afraid it is too late to
change this, this logic predates the git history.
And unless I missed something copy_siginfo_to_user32() assumes that
"from" was filled by copy_siginfo_from_user32(), but this is not true
if the sender is 64bit task. And this all doesn't match the behaviour
with 32bit kernel.
Personally, I think we should leave this ancient code alone. But I
agree that something like below looks right... I dunno.
And I have no idea why copy_siginfo_to_user32() abuses '>> 16', it
seems that "si_code & __SI_MASK" could work just fine.
Oleg.
--- x/arch/x86/kernel/signal_compat.c
+++ x/arch/x86/kernel/signal_compat.c
@@ -17,13 +17,14 @@
3 ints plus the relevant union member. */
put_user_ex(from->si_signo, &to->si_signo);
put_user_ex(from->si_errno, &to->si_errno);
- put_user_ex((short)from->si_code, &to->si_code);
if (from->si_code < 0) {
+ put_user_ex(from->si_code, &to->si_code);
put_user_ex(from->si_pid, &to->si_pid);
put_user_ex(from->si_uid, &to->si_uid);
put_user_ex(ptr_to_compat(from->si_ptr), &to->si_ptr);
} else {
+ put_user_ex((short)from->si_code, &to->si_code);
/*
* First 32bits of unions are always present:
* si_pid === si_band === si_tid === si_addr(LS half)
next prev parent reply other threads:[~2015-10-13 14:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-12 15:33 [PATCH] signal: Make the si_code check in rt_[tg]sigqueueinfo stricter Amanieu d'Antras
2015-10-12 15:54 ` Oleg Nesterov
2015-10-12 16:37 ` Amanieu d'Antras
2015-10-13 14:54 ` Oleg Nesterov [this message]
2015-10-13 15:40 ` Amanieu d'Antras
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=20151013145439.GA19175@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=amanieu@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
/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.