Re: [PATCH v2 4/6] seccomp: handle multiple listeners case

[Aleksandr Mikhalitsyn]

On Thu, Dec 4, 2025 at 4:18 PM Tycho Andersen <tycho@xxxxxxxxxx> wrote:
>
> On Wed, Dec 03, 2025 at 04:29:49PM +0100, Aleksandr Mikhalitsyn wrote:
> > On Tue, Dec 2, 2025 at 12:52 PM Alexander Mikhalitsyn
> > <aleksandr.mikhalitsyn@xxxxxxxxxxxxx> wrote:
> > >
> > > If we have more than one listener in the tree and lower listener
> > > wants us to continue syscall (SECCOMP_USER_NOTIF_FLAG_CONTINUE)
> > > we must consult with upper listeners first, otherwise it is a
> > > clear seccomp restrictions bypass scenario.
> > >
> > > Cc: linux-kernel@xxxxxxxxxxxxxxx
> > > Cc: bpf@xxxxxxxxxxxxxxx
> > > Cc: Kees Cook <kees@xxxxxxxxxx>
> > > Cc: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
> > > Cc: Will Drewry <wad@xxxxxxxxxxxx>
> > > Cc: Jonathan Corbet <corbet@xxxxxxx>
> > > Cc: Shuah Khan <shuah@xxxxxxxxxx>
> > > Cc: Aleksa Sarai <cyphar@xxxxxxxxxx>
> > > Cc: Tycho Andersen <tycho@tycho.pizza>
> > > Cc: Andrei Vagin <avagin@xxxxxxxxx>
> > > Cc: Christian Brauner <brauner@xxxxxxxxxx>
> > > Cc: Stéphane Graber <stgraber@xxxxxxxxxxxx>
> > > Reviewed-by: Tycho Andersen (AMD) <tycho@xxxxxxxxxx>
> > > Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@xxxxxxxxxxxxx>
> > > ---
> > >  kernel/seccomp.c | 33 +++++++++++++++++++++++++++++++--
> > >  1 file changed, 31 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> > > index ded3f6a6430b..262390451ff1 100644
> > > --- a/kernel/seccomp.c
> > > +++ b/kernel/seccomp.c
> > > @@ -448,8 +448,21 @@ static u32 seccomp_run_filters(const struct seccomp_data *sd,
> > >
> > >                 if (ACTION_ONLY(cur_ret) < ACTION_ONLY(ret)) {
> > >                         ret = cur_ret;
> > > +                       /*
> > > +                        * No matter what we had before in matches->filters[],
> > > +                        * we need to overwrite it, because current action is more
> > > +                        * restrictive than any previous one.
> > > +                        */
> > >                         matches->n = 1;
> > >                         matches->filters[0] = f;
> > > +               } else if ((ACTION_ONLY(cur_ret) == ACTION_ONLY(ret)) &&
> > > +                           ACTION_ONLY(cur_ret) == SECCOMP_RET_USER_NOTIF) {
> >
> > My bad. We also have to check f->notif in there like that:
>

Hi Tycho,

sorry for the delay with a reply.

> For my own education: why is that? Shouldn't
> seccomp_do_user_notification() be smart enough to catch this case (and
> indeed, there is a TOCTOU if you do it here?)?

seccomp_do_user_notification() is smart enough to handle the case when
a listener file descriptor was closed,
but a tricky part here is that SECCOMP_RET_USER_NOTIF can be (legally)
returned by the seccomp filter
program even when there was no listener at all.

Then, as nothing prevents you from loading a program like:
    BPF_STMT(BPF_RET|BPF_K, SECCOMP_RET_USER_NOTIF)
with
     seccomp(SECCOMP_SET_MODE_FILTER, 0, &prog) // << no
SECCOMP_FILTER_FLAG_NEW_LISTENER flag

we can easily do OOB write in matches->filters[] array, because our
limitation with 8 elements only works for those who
set the SECCOMP_FILTER_FLAG_NEW_LISTENER flag.

Actually, I decided to get rid of this array in the next version of patchset.

Hope to virtually meet you at LPC soon! ;)

Kind regards,
Alex

>
> Thanks,
>
> Tycho