Re: [PATCH v1 4/6] seccomp: handle multiple listeners case
From: Aleksandr Mikhalitsyn
Date: Tue Dec 02 2025 - 07:02:02 EST
On Mon, Dec 1, 2025 at 3:39 PM Tycho Andersen <tycho@xxxxxxxxxx> wrote:
>
> On Mon, Dec 01, 2025 at 01:24:01PM +0100, Alexander Mikhalitsyn 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: Tycho Andersen <tycho@tycho.pizza>
> > Cc: Andrei Vagin <avagin@xxxxxxxxx>
> > Cc: Christian Brauner <brauner@xxxxxxxxxx>
> > Cc: Stéphane Graber <stgraber@xxxxxxxxxxxx>
> > Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@xxxxxxxxxxxxx>
> > ---
> > kernel/seccomp.c | 16 ++++++++++++++--
> > 1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> > index ded3f6a6430b..ad733f849e0f 100644
> > --- a/kernel/seccomp.c
> > +++ b/kernel/seccomp.c
> > @@ -450,6 +450,9 @@ static u32 seccomp_run_filters(const struct seccomp_data *sd,
> > ret = cur_ret;
> > matches->n = 1;
> > matches->filters[0] = f;
> > + } else if ((ACTION_ONLY(cur_ret) == ACTION_ONLY(ret)) &&
> > + ACTION_ONLY(cur_ret) == SECCOMP_RET_USER_NOTIF) {
> > + matches->filters[matches->n++] = f;
> > }
> > }
> > return ret;
> > @@ -1362,8 +1365,17 @@ static int __seccomp_filter(int this_syscall, const bool recheck_after_trace)
> > return 0;
> >
> > case SECCOMP_RET_USER_NOTIF:
> > - if (seccomp_do_user_notification(match, &sd))
> > - goto skip;
> > + for (unsigned char i = 0; i < matches.n; i++) {
> > + match = matches.filters[i];
> > + /*
> > + * If userspace wants us to skip this syscall, do so.
> > + * But if userspace wants to continue syscall, we
> > + * must consult with the upper-level filters listeners
> > + * and act accordingly.
>
Hi Tycho,
> This looks reasonable to me, pending whatever the outcome is of your
> discussion of plumber's (I won't be there), feel free to add:
off:
I will be there only virtually too, btw.
Hope we can make it on FOSDEM 2026 ;)
>
> Reviewed-by: Tycho Andersen (AMD) <tycho@xxxxxxxxxx>
Added in -v2. Thanks ;)
>
> I did have to think a bit about why matches.filters would be
> guaranteed to have a user notification for this filter, but it's
> because of your == check above in seccomp_run_filters(). Maybe worth
> noting that here.
i agree absolutely, I've added some more explanatory comments to ensure that
we are all on the same page and further code readers too.
>
Kind regards,
Alex
> Tycho