[PULL] seccomp update (next)

[PULL] seccomp update (next)

[Kees Cook]

Hi,

Please pull these seccomp changes for next. These have been tested by
myself and Andy, and close a long-standing issue with seccomp where tracers
could change the syscall out from under seccomp.

Thanks!

-Kees

The following changes since commit 40d273782ff16fe1a7445cc05c66a447dfea3433:

  security: tomoyo: simplify the gc kthread creation (2016-06-06 20:23:55 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next

for you to fetch changes up to 26703c636c1f3272b39bd0f6d04d2e970984f1b6:

  um/ptrace: run seccomp after ptrace (2016-06-14 10:54:47 -0700)

----------------------------------------------------------------
Fix seccomp vs ptrace ordering to plug syscall filter bypass issue.

----------------------------------------------------------------
Andy Lutomirski (2):
      seccomp: Add a seccomp_data parameter secure_computing()
      x86/entry: Get rid of two-phase syscall entry work

Kees Cook (12):
      seccomp: add tests for ptrace hole
      seccomp: remove 2-phase API
      seccomp: recheck the syscall after RET_TRACE
      x86/ptrace: run seccomp after ptrace
      arm/ptrace: run seccomp after ptrace
      arm64/ptrace: run seccomp after ptrace
      MIPS/ptrace: run seccomp after ptrace
      parisc/ptrace: run seccomp after ptrace
      s390/ptrace: run seccomp after ptrace
      powerpc/ptrace: run seccomp after ptrace
      tile/ptrace: run seccomp after ptrace
      um/ptrace: run seccomp after ptrace

 arch/arm/kernel/ptrace.c                      |  13 +-
 arch/arm64/kernel/ptrace.c                    |   8 +-
 arch/mips/kernel/ptrace.c                     |   9 +-
 arch/parisc/kernel/ptrace.c                   |   9 +-
 arch/powerpc/kernel/ptrace.c                  |  46 +++----
 arch/s390/kernel/ptrace.c                     |  21 ++-
 arch/tile/kernel/ptrace.c                     |  11 +-
 arch/um/kernel/skas/syscall.c                 |   9 +-
 arch/x86/entry/common.c                       | 106 +++-------------
 arch/x86/entry/vsyscall/vsyscall_64.c         |   2 +-
 arch/x86/include/asm/ptrace.h                 |   6 -
 include/linux/seccomp.h                       |  14 +-
 kernel/seccomp.c                              | 144 ++++++++-------------
 tools/testing/selftests/seccomp/seccomp_bpf.c | 176 ++++++++++++++++++++++++--
 14 files changed, 309 insertions(+), 265 deletions(-)

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PULL] seccomp update (next)

[James Morris]

On Tue, 14 Jun 2016, Kees Cook wrote:

> Hi,
> 
> Please pull these seccomp changes for next. These have been tested by
> myself and Andy, and close a long-standing issue with seccomp where tracers
> could change the syscall out from under seccomp.

Pulled to security -next.


-- 
James Morris
<jmorris@namei.org>

Re: [PULL] seccomp update (next)

[Andy Lutomirski]

On Fri, Jun 17, 2016 at 12:15 AM, James Morris <jmorris@namei.org> wrote:
> On Tue, 14 Jun 2016, Kees Cook wrote:
>
>> Hi,
>>
>> Please pull these seccomp changes for next. These have been tested by
>> myself and Andy, and close a long-standing issue with seccomp where tracers
>> could change the syscall out from under seccomp.
>
> Pulled to security -next.

As a heads up: I think this doesn't quite close the hole on x86.  Consider:

64-bit task arranges to be traced by a 32-bit task (or presumably a
64-bit task that calls ptrace via int80).

Tracer does PTRACE_SYSCALL.

Tracee does a normal syscall.

Tracer writes tracee's orig_ax, thus invoking this thing in
arch/x86/kernel/ptrace.c:

        if (syscall_get_nr(child, regs) >= 0)
            child->thread.status |= TS_COMPAT;

Tracer resumes and gets confused.

I think the right fix is to just delete:

        if (syscall_get_nr(child, regs) >= 0)
            child->thread.status |= TS_COMPAT;

from ptrace.c.   The comment above it is garbage, too.

--Andy

Re: [PULL] seccomp update (next)

[Kees Cook]

On Fri, Jun 17, 2016 at 11:55 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Fri, Jun 17, 2016 at 12:15 AM, James Morris <jmorris@namei.org> wrote:
>> On Tue, 14 Jun 2016, Kees Cook wrote:
>>
>>> Hi,
>>>
>>> Please pull these seccomp changes for next. These have been tested by
>>> myself and Andy, and close a long-standing issue with seccomp where tracers
>>> could change the syscall out from under seccomp.
>>
>> Pulled to security -next.
>
> As a heads up: I think this doesn't quite close the hole on x86.  Consider:
>
> 64-bit task arranges to be traced by a 32-bit task (or presumably a
> 64-bit task that calls ptrace via int80).
>
> Tracer does PTRACE_SYSCALL.
>
> Tracee does a normal syscall.
>
> Tracer writes tracee's orig_ax, thus invoking this thing in
> arch/x86/kernel/ptrace.c:
>
>         if (syscall_get_nr(child, regs) >= 0)
>             child->thread.status |= TS_COMPAT;
>
> Tracer resumes and gets confused.
>
> I think the right fix is to just delete:
>
>         if (syscall_get_nr(child, regs) >= 0)
>             child->thread.status |= TS_COMPAT;
>
> from ptrace.c.   The comment above it is garbage, too.

I'm perfectly happy to see it removed. I can't make sense of the comment. :)

That said, the only confusion I see is pretty minor. The arch is saved
before the tracer could force TS_COMPAT, so nothing confused is handed
to seccomp (the first time). And the syscall will continue to be
looked up on sys_call_table not ia32_sys_call_table.

The only thing I see is if the tracer has also added a
SECCOMP_RET_TRACE filter, after which the recheck will reload all the
seccomp info, including the arch. And at this point, a sensible filter
will reject a non-matching architecture.

Maybe I'm missing something more?

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PULL] seccomp update (next)

[Andy Lutomirski]

On Jun 18, 2016 12:02 AM, "Kees Cook" <keescook@chromium.org> wrote:
>
> On Fri, Jun 17, 2016 at 11:55 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> > On Fri, Jun 17, 2016 at 12:15 AM, James Morris <jmorris@namei.org> wrote:
> >> On Tue, 14 Jun 2016, Kees Cook wrote:
> >>
> >>> Hi,
> >>>
> >>> Please pull these seccomp changes for next. These have been tested by
> >>> myself and Andy, and close a long-standing issue with seccomp where tracers
> >>> could change the syscall out from under seccomp.
> >>
> >> Pulled to security -next.
> >
> > As a heads up: I think this doesn't quite close the hole on x86.  Consider:
> >
> > 64-bit task arranges to be traced by a 32-bit task (or presumably a
> > 64-bit task that calls ptrace via int80).
> >
> > Tracer does PTRACE_SYSCALL.
> >
> > Tracee does a normal syscall.
> >
> > Tracer writes tracee's orig_ax, thus invoking this thing in
> > arch/x86/kernel/ptrace.c:
> >
> >         if (syscall_get_nr(child, regs) >= 0)
> >             child->thread.status |= TS_COMPAT;
> >
> > Tracer resumes and gets confused.
> >
> > I think the right fix is to just delete:
> >
> >         if (syscall_get_nr(child, regs) >= 0)
> >             child->thread.status |= TS_COMPAT;
> >
> > from ptrace.c.   The comment above it is garbage, too.
>
> I'm perfectly happy to see it removed. I can't make sense of the comment. :)
>
> That said, the only confusion I see is pretty minor. The arch is saved
> before the tracer could force TS_COMPAT, so nothing confused is handed
> to seccomp (the first time). And the syscall will continue to be
> looked up on sys_call_table not ia32_sys_call_table.

Hmm, right, but...

>
> The only thing I see is if the tracer has also added a
> SECCOMP_RET_TRACE filter, after which the recheck will reload all the
> seccomp info, including the arch. And at this point, a sensible filter
> will reject a non-matching architecture.
>

Yes for some filters, but others might have different logic for
different arches, at which point there's a minor bypass.

> Maybe I'm missing something more?
>

You can also use this to do a 64-bit syscall with in_compat_syscall()
returning true, which could cause issues for audit and maybe some
ioctl handlers irrespective of this patch series.  I'll see about
getting it fixed in x86/urgent.

Re: [PULL] seccomp update (next)

[Andy Lutomirski]

On Sat, Jun 18, 2016 at 3:21 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Jun 18, 2016 12:02 AM, "Kees Cook" <keescook@chromium.org> wrote:
>>
>> On Fri, Jun 17, 2016 at 11:55 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> > On Fri, Jun 17, 2016 at 12:15 AM, James Morris <jmorris@namei.org> wrote:
>> >> On Tue, 14 Jun 2016, Kees Cook wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> Please pull these seccomp changes for next. These have been tested by
>> >>> myself and Andy, and close a long-standing issue with seccomp where tracers
>> >>> could change the syscall out from under seccomp.
>> >>
>> >> Pulled to security -next.
>> >
>> > As a heads up: I think this doesn't quite close the hole on x86.  Consider:
>> >
>> > 64-bit task arranges to be traced by a 32-bit task (or presumably a
>> > 64-bit task that calls ptrace via int80).
>> >
>> > Tracer does PTRACE_SYSCALL.
>> >
>> > Tracee does a normal syscall.
>> >
>> > Tracer writes tracee's orig_ax, thus invoking this thing in
>> > arch/x86/kernel/ptrace.c:
>> >
>> >         if (syscall_get_nr(child, regs) >= 0)
>> >             child->thread.status |= TS_COMPAT;
>> >
>> > Tracer resumes and gets confused.
>> >
>> > I think the right fix is to just delete:
>> >
>> >         if (syscall_get_nr(child, regs) >= 0)
>> >             child->thread.status |= TS_COMPAT;
>> >
>> > from ptrace.c.   The comment above it is garbage, too.
>>
>> I'm perfectly happy to see it removed. I can't make sense of the comment. :)
>>
>> That said, the only confusion I see is pretty minor. The arch is saved
>> before the tracer could force TS_COMPAT, so nothing confused is handed
>> to seccomp (the first time). And the syscall will continue to be
>> looked up on sys_call_table not ia32_sys_call_table.
>
> Hmm, right, but...
>
>>
>> The only thing I see is if the tracer has also added a
>> SECCOMP_RET_TRACE filter, after which the recheck will reload all the
>> seccomp info, including the arch. And at this point, a sensible filter
>> will reject a non-matching architecture.
>>
>
> Yes for some filters, but others might have different logic for
> different arches, at which point there's a minor bypass.
>
>> Maybe I'm missing something more?
>>
>
> You can also use this to do a 64-bit syscall with in_compat_syscall()
> returning true, which could cause issues for audit and maybe some
> ioctl handlers irrespective of this patch series.  I'll see about
> getting it fixed in x86/urgent.

Hi Kees and James-

On further consideration:

(a) that TS_COMPAT thing is highly, highly buggy -- much buggier and
more confusing than I thought, and not in the way I thought.

(b) it doesn't interfere with seccomp at all, so fixing it is not at
all a prerequisite for these changes.


-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PULL] seccomp update (next)

[James Morris]

On Thu, 7 Jul 2016, Kees Cook wrote:

> Hi,
> 
> Please pull these seccomp changes for next.

Pulled, thanks.

-- 
James Morris
<jmorris@namei.org>

[PULL] seccomp update (next)

[Kees Cook]

Hi,

Please pull these seccomp changes for next.

Thanks!

-Kees

The following changes since commit d011a4d861ce583466a8ae72a0c8e7f51c8cba4e:

  Merge branch 'stable-4.8' of git://git.infradead.org/users/pcmoore/selinux into next (2016-07-07 10:15:34 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next

for you to fetch changes up to f6041c1d8a0825e41219a0443d365318d238d7b3:

  samples/seccomp: Add standalone config option (2016-07-07 10:58:03 -0700)

----------------------------------------------------------------
Seccomp samples building fix

----------------------------------------------------------------
Olof Johansson (1):
      samples/seccomp: Add standalone config option

 samples/Kconfig          | 7 +++++++
 samples/seccomp/Makefile | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

-- 
Kees Cook
Chrome OS & Brillo Security

[PULL] seccomp update (next)

[Kees Cook]

Hi,

Please pull these seccomp changes for next.

Thanks!

-Kees

The following changes since commit aa98b942cbf305cf2abe5dc3aff11f579c7d7fdc:

  Merge branch 'smack-for-4.5' of https://github.com/cschaufler/smack-next into next (2015-12-26 16:11:13 +1100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next

for you to fetch changes up to d96c17fcc58f8a486fea74d6f96a4a9407109d97:

  seccomp: always propagate NO_NEW_PRIVS on tsync (2016-01-05 15:35:41 -0800)

----------------------------------------------------------------
Fix NNP when already under root-created filter

----------------------------------------------------------------
Jann Horn (1):
      seccomp: always propagate NO_NEW_PRIVS on tsync

 kernel/seccomp.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PULL] seccomp update (next)

[James Morris]

On Wed, 15 Jul 2015, Kees Cook wrote:

> Hi,
> 
> Please pull these seccomp changes for next.
> 
> Thanks!
> 
> -Kees
> 
> The following changes since commit b3bddffd35a0b77eee89760eb94cafa18dc431f5:
> 
>   Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity into next (2015-06-18 23:28:40 +1000)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next
> 
> for you to fetch changes up to 221272f97ca528048a577a3ff23d7774286ca5fd:
> 

Pulled.


-- 
James Morris
<jmorris@namei.org>

[PULL] seccomp update (next)

[Kees Cook]

Hi,

Please pull these seccomp changes for next.

Thanks!

-Kees

The following changes since commit b3bddffd35a0b77eee89760eb94cafa18dc431f5:

  Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity into next (2015-06-18 23:28:40 +1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next

for you to fetch changes up to 221272f97ca528048a577a3ff23d7774286ca5fd:

  seccomp: swap hard-coded zeros to defined name (2015-07-15 11:52:54 -0700)

----------------------------------------------------------------
Various updates and cleanups for seccomp

----------------------------------------------------------------
Kees Cook (1):
      seccomp: swap hard-coded zeros to defined name

Pranith Kumar (1):
      seccomp: Replace smp_read_barrier_depends() with lockless_dereference()

Tycho Andersen (1):
      seccomp: add ptrace options for suspend/resume

 include/linux/ptrace.h      |  1 +
 include/linux/seccomp.h     |  2 +-
 include/uapi/linux/ptrace.h |  6 ++++--
 kernel/ptrace.c             | 13 +++++++++++++
 kernel/seccomp.c            | 17 ++++++++++++-----
 5 files changed, 31 insertions(+), 8 deletions(-)

-- 
Kees Cook
Chrome OS Security

Re: [PULL] seccomp update (next)

[James Morris]

On Mon, 1 Dec 2014, Kees Cook wrote:

> On Mon, Dec 1, 2014 at 2:56 PM, James Morris <jmorris@namei.org> wrote:
> > On Mon, 1 Dec 2014, Kees Cook wrote:
> >
> >> On Thu, Nov 27, 2014 at 3:37 PM, James Morris <jmorris@namei.org> wrote:
> >> > On Wed, 26 Nov 2014, Kees Cook wrote:
> >> >
> >> >> > That would be because your tree is based on v3.17 and Kees' is based on
> >> >> > v3.18-rc6 ...
> >> >>
> >> >> James, I can base on whatever you like. I can do v3.17, or even
> >> >> against your security-next. It seems everyone uses something
> >> >> different. :)
> >> >
> >> > It's best to track my next branch as your upstream.
> >>
> >> It'll trigger collisions with what's the x86 -next from luto's
> >> changes. Should I just let Stephen sort that out?
> >
> > Yep.
> 
> Hm, it depends on 54ef6df3f3f1353d99c80c437259d317b2cd1cbd, so basing
> against security-next would make the tree unbuildable. Perhaps I
> should just wait for -rc1 to land first?

Yep, that will work.


-- 
James Morris
<jmorris@namei.org>

Re: [PULL] seccomp update (next)

[Kees Cook]

On Mon, Dec 1, 2014 at 2:56 PM, James Morris <jmorris@namei.org> wrote:
> On Mon, 1 Dec 2014, Kees Cook wrote:
>
>> On Thu, Nov 27, 2014 at 3:37 PM, James Morris <jmorris@namei.org> wrote:
>> > On Wed, 26 Nov 2014, Kees Cook wrote:
>> >
>> >> > That would be because your tree is based on v3.17 and Kees' is based on
>> >> > v3.18-rc6 ...
>> >>
>> >> James, I can base on whatever you like. I can do v3.17, or even
>> >> against your security-next. It seems everyone uses something
>> >> different. :)
>> >
>> > It's best to track my next branch as your upstream.
>>
>> It'll trigger collisions with what's the x86 -next from luto's
>> changes. Should I just let Stephen sort that out?
>
> Yep.

Hm, it depends on 54ef6df3f3f1353d99c80c437259d317b2cd1cbd, so basing
against security-next would make the tree unbuildable. Perhaps I
should just wait for -rc1 to land first?

-Kees

-- 
Kees Cook
Chrome OS Security

Re: [PULL] seccomp update (next)

[James Morris]

On Mon, 1 Dec 2014, Kees Cook wrote:

> On Thu, Nov 27, 2014 at 3:37 PM, James Morris <jmorris@namei.org> wrote:
> > On Wed, 26 Nov 2014, Kees Cook wrote:
> >
> >> > That would be because your tree is based on v3.17 and Kees' is based on
> >> > v3.18-rc6 ...
> >>
> >> James, I can base on whatever you like. I can do v3.17, or even
> >> against your security-next. It seems everyone uses something
> >> different. :)
> >
> > It's best to track my next branch as your upstream.
> 
> It'll trigger collisions with what's the x86 -next from luto's
> changes. Should I just let Stephen sort that out?

Yep.

-- 
James Morris
<jmorris@namei.org>

Re: [PULL] seccomp update (next)

[Kees Cook]

On Thu, Nov 27, 2014 at 3:37 PM, James Morris <jmorris@namei.org> wrote:
> On Wed, 26 Nov 2014, Kees Cook wrote:
>
>> > That would be because your tree is based on v3.17 and Kees' is based on
>> > v3.18-rc6 ...
>>
>> James, I can base on whatever you like. I can do v3.17, or even
>> against your security-next. It seems everyone uses something
>> different. :)
>
> It's best to track my next branch as your upstream.

It'll trigger collisions with what's the x86 -next from luto's
changes. Should I just let Stephen sort that out?

-Kees

-- 
Kees Cook
Chrome OS Security

Re: [PULL] seccomp update (next)

[James Morris]

On Wed, 26 Nov 2014, Kees Cook wrote:

> > That would be because your tree is based on v3.17 and Kees' is based on
> > v3.18-rc6 ...
> 
> James, I can base on whatever you like. I can do v3.17, or even
> against your security-next. It seems everyone uses something
> different. :)

It's best to track my next branch as your upstream.


-- 
James Morris
<jmorris@namei.org>

Re: [PULL] seccomp update (next)

[Kees Cook]

On Wed, Nov 26, 2014 at 1:46 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi James,
>
> On Thu, 27 Nov 2014 00:23:06 +1100 (AEDT) James Morris <jmorris@namei.org> wrote:
>>
>> On Tue, 25 Nov 2014, Kees Cook wrote:
>>
>> > Please pull these seccomp changes for next.
>> >
>> > Thanks!
>> >
>> > -Kees
>> >
>> > The following changes since commit 5d01410fe4d92081f349b013a2e7a95429e4f2c9:
>> >
>> >   Linux 3.18-rc6 (2014-11-23 15:25:20 -0800)
>> >
>> > are available in the git repository at:
>> >
>> >   git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next
>> >
>> > for you to fetch changes up to cb24de187b9a0717246f05afc0f2be070e075d80:
>> >
>> >   seccomp: Replace smp_read_barrier_depends() with lockless_dereference() (2014-11-25 11:40:24 -0800)
>> >
>> > ----------------------------------------------------------------
>> > Improves SMP dereferencing with new macro.
>> >
>> > ----------------------------------------------------------------
>> > Pranith Kumar (1):
>> >       seccomp: Replace smp_read_barrier_depends() with lockless_dereference()
>> >
>> >  kernel/seccomp.c | 7 +++----
>> >  1 file changed, 3 insertions(+), 4 deletions(-)
>> >
>>
>> This is what I get when pulling to my next branch:
>>
>> 9128 files changed, 468773 insertions(+), 340317 deletions(-)
>
> That would be because your tree is based on v3.17 and Kees' is based on
> v3.18-rc6 ...

James, I can base on whatever you like. I can do v3.17, or even
against your security-next. It seems everyone uses something
different. :)

Thanks!

-Kees

-- 
Kees Cook
Chrome OS Security

Re: [PULL] seccomp update (next)

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]

Hi James,

On Thu, 27 Nov 2014 00:23:06 +1100 (AEDT) James Morris <jmorris@namei.org> wrote:
>
> On Tue, 25 Nov 2014, Kees Cook wrote:
> 
> > Please pull these seccomp changes for next.
> > 
> > Thanks!
> > 
> > -Kees
> > 
> > The following changes since commit 5d01410fe4d92081f349b013a2e7a95429e4f2c9:
> > 
> >   Linux 3.18-rc6 (2014-11-23 15:25:20 -0800)
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next
> > 
> > for you to fetch changes up to cb24de187b9a0717246f05afc0f2be070e075d80:
> > 
> >   seccomp: Replace smp_read_barrier_depends() with lockless_dereference() (2014-11-25 11:40:24 -0800)
> > 
> > ----------------------------------------------------------------
> > Improves SMP dereferencing with new macro.
> > 
> > ----------------------------------------------------------------
> > Pranith Kumar (1):
> >       seccomp: Replace smp_read_barrier_depends() with lockless_dereference()
> > 
> >  kernel/seccomp.c | 7 +++----
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> > 
> 
> This is what I get when pulling to my next branch:
> 
> 9128 files changed, 468773 insertions(+), 340317 deletions(-)

That would be because your tree is based on v3.17 and Kees' is based on
v3.18-rc6 ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PULL] seccomp update (next)

[James Morris]

On Tue, 25 Nov 2014, Kees Cook wrote:

> Hi,
> 
> Please pull these seccomp changes for next.
> 
> Thanks!
> 
> -Kees
> 
> The following changes since commit 5d01410fe4d92081f349b013a2e7a95429e4f2c9:
> 
>   Linux 3.18-rc6 (2014-11-23 15:25:20 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next
> 
> for you to fetch changes up to cb24de187b9a0717246f05afc0f2be070e075d80:
> 
>   seccomp: Replace smp_read_barrier_depends() with lockless_dereference() (2014-11-25 11:40:24 -0800)
> 
> ----------------------------------------------------------------
> Improves SMP dereferencing with new macro.
> 
> ----------------------------------------------------------------
> Pranith Kumar (1):
>       seccomp: Replace smp_read_barrier_depends() with lockless_dereference()
> 
>  kernel/seccomp.c | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 

This is what I get when pulling to my next branch:

9128 files changed, 468773 insertions(+), 340317 deletions(-)


-- 
James Morris
<jmorris@namei.org>

[PULL] seccomp update (next)

[Kees Cook]

Hi,

Please pull these seccomp changes for next.

Thanks!

-Kees

The following changes since commit 5d01410fe4d92081f349b013a2e7a95429e4f2c9:

  Linux 3.18-rc6 (2014-11-23 15:25:20 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/seccomp-next

for you to fetch changes up to cb24de187b9a0717246f05afc0f2be070e075d80:

  seccomp: Replace smp_read_barrier_depends() with lockless_dereference() (2014-11-25 11:40:24 -0800)

----------------------------------------------------------------
Improves SMP dereferencing with new macro.

----------------------------------------------------------------
Pranith Kumar (1):
      seccomp: Replace smp_read_barrier_depends() with lockless_dereference()

 kernel/seccomp.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

-- 
Kees Cook
Chrome OS Security