From: Luis Henriques <luis.henriques@canonical.com>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: stable <stable@vger.kernel.org>,
linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>,
751417@bugs.debian.org, team@security.debian.org,
Plamen Alexandrov <plamen@aomeda.com>,
Markos Chandras <markos.chandras@imgtec.com>
Subject: Re: Bug#751417: linux-image-3.2.0-4-5kc-malta: no SIGKILL after prctl(PR_SET_SECCOMP, 1, ...) on MIPS
Date: Mon, 23 Jun 2014 10:19:22 +0100 [thread overview]
Message-ID: <20140623091922.GC4214@hercules> (raw)
In-Reply-To: <1402604501.31756.50.camel@deadeye.wl.decadent.org.uk>
On Thu, Jun 12, 2014 at 09:21:41PM +0100, Ben Hutchings wrote:
> On Thu, 2014-06-12 at 20:36 +0100, Ben Hutchings wrote:
> > Control: tag -1 security upstream patch moreinfo
> > Control: severity -1 grave
> > Control: found -1 3.14.5-1
>
> Aurelien Jarno pointed out this appears to be fixed upstream in 3.15:
>
> commit 137f7df8cead00688524c82360930845396b8a21
> Author: Markos Chandras <markos.chandras@imgtec.com>
> Date: Wed Jan 22 14:40:00 2014 +0000
>
> MIPS: asm: thread_info: Add _TIF_SECCOMP flag
>
> It looks like this can be cherry-picked cleanly onto stable branches for
> 3.13 and 3.14. For 3.11 and 3.12, it will need trivial adjustment.
>
> For branches older than 3.11, this needs to be cherry-picked first:
>
> commit e7f3b48af7be9f8007a224663a5b91340626fed5
> Author: Ralf Baechle <ralf@linux-mips.org>
> Date: Wed May 29 01:02:18 2013 +0200
>
> MIPS: Cleanup flags in syscall flags handlers.
>
> Ben.
>
Thank you, I'm queuing this for the 3.11 kernel.
Cheers,
--
Luís
> > On Thu, 2014-06-12 at 16:19 +0000, Plamen Alexandrov wrote:
> > > Package: src:linux
> > > Version: 3.2.51-1
> > > Severity: normal
> > >
> > > Under MIPS the system call prctl(PR_SET_SECCOMP, 1, ...) does not behave as expected.
> > > According to the manual page, after calling it with 1 as a second argument, any consecutive system calls other than read(), write(), _exit() and sigreturn() should result in the delivery of SIGKILL. However, under MIPS any consecutive system call behaves as if prctl(PR_SET_SECCOMP, 1, ...) was never called.
> > >
> > > Here is a simple example that can be used to reproduce the bug:
> > >
> > > plamen@debian-mips:/tmp$ id
> > > uid=1000(plamen) gid=1000(user) groups=1000(user)
> > > plamen@debian-mips:/tmp$ cat prctl.c
> > > #include <unistd.h>
> > > #include <sys/prctl.h>
> > > #include <stdio.h>
> > >
> > > int main(void)
> > > {
> > > if (prctl(PR_SET_SECCOMP, 1, 0, 0, 0) != 0)
> > > return 0;
> > > uid_t uid = getuid();
> > > printf("%u\n", (unsigned)uid);
> > > return 0;
> > > }
> > > plamen@debian-mips:/tmp$ gcc prctl.c -o prctl
> > > plamen@debian-mips:/tmp$ ./prctl
> > > 1000
> > >
> > > There is no change if I replace
> > > if (prctl(PR_SET_SECCOMP, 1, 0, 0, 0) != 0)
> > > with
> > > if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT, 0, 0, 0) != 0)
> > > and I add #include <linux/seccomp.h>
> >
> > Indeed, I see no check for seccomp on the MIPS syscall 'fast path'. The
> > seccomp check appears to be done on the 'slow path' which is used only
> > if tracing or audit is also enabled for the task. If I run the above
> > program under strace, it is killed as expected.
> >
> > Could you test whether the attached patches fix this? (Instructions for
> > rebuilding the Debian kernel package with patches can be found at
> > <http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official>. These patches apply to 'wheezy'.)
> >
> > Ben.
> >
>
> --
> Ben Hutchings
> The program is absolutely right; therefore, the computer must be wrong.
prev parent reply other threads:[~2014-06-23 9:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20140612161903.32229.20589.reportbug@debian-mips."">
[not found] ` <1402601767.31756.38.camel@deadeye.wl.decadent.org.uk>
2014-06-12 20:21 ` Bug#751417: linux-image-3.2.0-4-5kc-malta: no SIGKILL after prctl(PR_SET_SECCOMP, 1, ...) on MIPS Ben Hutchings
2014-06-12 21:03 ` Greg KH
2014-06-12 21:05 ` Greg KH
2014-06-12 21:10 ` Ben Hutchings
2014-06-12 21:59 ` Greg KH
2014-06-15 20:01 ` Ben Hutchings
2014-06-23 9:19 ` Luis Henriques [this message]
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=20140623091922.GC4214@hercules \
--to=luis.henriques@canonical.com \
--cc=751417@bugs.debian.org \
--cc=ben@decadent.org.uk \
--cc=linux-mips@linux-mips.org \
--cc=markos.chandras@imgtec.com \
--cc=plamen@aomeda.com \
--cc=ralf@linux-mips.org \
--cc=stable@vger.kernel.org \
--cc=team@security.debian.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox