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: Mon, 12 Oct 2015 17:54:44 +0200 [thread overview]
Message-ID: <20151012155444.GA26302@redhat.com> (raw)
In-Reply-To: <1444664034-22446-1-git-send-email-amanieu@gmail.com>
On 10/12, Amanieu d'Antras wrote:
>
> rt_sigqueueinfo and rt_tgsigqueueinfo check the value of si_code to
> prevent a process from spoofing a kernel-generated signal or one
> generated by kill/tgkill.
>
> Unfortunately this check failed to take into account the fact that
> the si_code value seen by a user process is only the low 16 bits of
> the value in the kernel. It was still possible to spoof any si_code
> by ORing 0xffff into the top 16 bits.
Confused...
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -2989,7 +2989,7 @@ static int do_rt_sigqueueinfo(pid_t pid, int sig, siginfo_t *info)
> /* Not even root can pretend to send signals from the kernel.
> * Nor can they impersonate a kill()/tgkill(), which adds source info.
> */
> - if ((info->si_code >= 0 || info->si_code == SI_TKILL) &&
> + if (((short)info->si_code >= 0 || (short)info->si_code == SI_TKILL) &&
> (task_pid_vnr(current) != pid))
> return -EPERM;
>
> @@ -3037,7 +3037,7 @@ static int do_rt_tgsigqueueinfo(pid_t tgid, pid_t pid, int sig, siginfo_t *info)
> /* Not even root can pretend to send signals from the kernel.
> * Nor can they impersonate a kill()/tgkill(), which adds source info.
> */
> - if ((info->si_code >= 0 || info->si_code == SI_TKILL) &&
> + if (((short)info->si_code >= 0 || (short)info->si_code == SI_TKILL) &&
> (task_pid_vnr(current) != pid))
> return -EPERM;
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.
So I do not think this patch is right.
Oleg.
next prev parent reply other threads:[~2015-10-12 15: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 [this message]
2015-10-12 16:37 ` Amanieu d'Antras
2015-10-13 14:54 ` Oleg Nesterov
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=20151012155444.GA26302@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.