On Mon, Feb 27, 2012 at 10:14 AM, Oleg Nesterov [off-list ref] wrote:

On 02/27, Kees Cook wrote:

quoted

On Mon, Feb 27, 2012 at 9:11 AM, Oleg Nesterov [off-list ref] wrote:

quoted

On 02/24, Will Drewry wrote:

quoted

 static u32 seccomp_run_filters(int syscall)
 {
      struct seccomp_filter *f;
-     u32 ret = SECCOMP_RET_KILL;
      static const struct bpf_load_fn fns = {
              bpf_load,
              sizeof(struct seccomp_data),
      };
+     u32 ret = SECCOMP_RET_ALLOW;
      const void *sc_ptr = (const void *)(uintptr_t)syscall;

+     /* Ensure unexpected behavior doesn't result in failing open. */
+     if (unlikely(current->seccomp.filter == NULL))
+             ret = SECCOMP_RET_KILL;

Is "seccomp.filter == NULL" really possible?

It should not be, but I'm much more comfortable with this failing
closed. I think it's important to be as defensive as possible with
this code given its intended use.

Can't resists... Sorry, I know I am troll but personally I think
in this case the most defensive code is BUG_ON(->filter == NULL)
or at least WARN_ON().

Linus will probably object because he objected (correctly) to a very
similar problem in my old vsyscall emulation series.  A userspace
security feature shouldn't have a failure mode in which it confuses
the kernel and results in an oops, unless the situation is really
unrecoverable.  So WARN_ON plus do_exit would be okay but BUG_ON would
not.

--Andy