1. Patchew
  2. linux
  3. [PATCH v1 0/6] seccomp: support nested listeners
  4. View patch

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

Alexander Mikhalitsyn posted 6 patches 2 months, 1 week ago
There is a newer version of this series
[PATCH v1 4/6] seccomp: handle multiple listeners case
Posted by Alexander Mikhalitsyn 2 months, 1 week ago 
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@vger.kernel.org
Cc: bpf@vger.kernel.org
Cc: Kees Cook <kees@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Will Drewry <wad@chromium.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Tycho Andersen <tycho@tycho.pizza>
Cc: Andrei Vagin <avagin@gmail.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Stéphane Graber <stgraber@stgraber.org>
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
---
 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.
+			 */
+			if (seccomp_do_user_notification(match, &sd))
+				goto skip;
+		}
 
 		return 0;
 
-- 
2.43.0
Re: [PATCH v1 4/6] seccomp: handle multiple listeners case
Posted by Tycho Andersen 2 months, 1 week ago 
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@vger.kernel.org
> Cc: bpf@vger.kernel.org
> Cc: Kees Cook <kees@kernel.org>
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: Will Drewry <wad@chromium.org>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Shuah Khan <shuah@kernel.org>
> Cc: Tycho Andersen <tycho@tycho.pizza>
> Cc: Andrei Vagin <avagin@gmail.com>
> Cc: Christian Brauner <brauner@kernel.org>
> Cc: Stéphane Graber <stgraber@stgraber.org>
> Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
> ---
>  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.

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:

Reviewed-by: Tycho Andersen (AMD) <tycho@kernel.org>

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.

Tycho
Re: [PATCH v1 4/6] seccomp: handle multiple listeners case
Posted by Aleksandr Mikhalitsyn 2 months, 1 week ago 
On Mon, Dec 1, 2025 at 3:39 PM Tycho Andersen <tycho@kernel.org> 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@vger.kernel.org
> > Cc: bpf@vger.kernel.org
> > Cc: Kees Cook <kees@kernel.org>
> > Cc: Andy Lutomirski <luto@amacapital.net>
> > Cc: Will Drewry <wad@chromium.org>
> > Cc: Jonathan Corbet <corbet@lwn.net>
> > Cc: Shuah Khan <shuah@kernel.org>
> > Cc: Tycho Andersen <tycho@tycho.pizza>
> > Cc: Andrei Vagin <avagin@gmail.com>
> > Cc: Christian Brauner <brauner@kernel.org>
> > Cc: Stéphane Graber <stgraber@stgraber.org>
> > Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
> > ---
> >  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@kernel.org>

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

Patchew 2.1-devel-b67e4c2

© 2016 - 2026 Red Hat, Inc.