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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEivzxf0a8EDzVJ+j7FLuarKHrCRPUtS9Z+tQ4se9E+xHvE0Fg@mail.gmail.com>
Date: Wed, 3 Dec 2025 16:29:49 +0100
From: Aleksandr Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>
To: kees@...nel.org
Cc: linux-kernel@...r.kernel.org, bpf@...r.kernel.org, 
	Andy Lutomirski <luto@...capital.net>, Will Drewry <wad@...omium.org>, Jonathan Corbet <corbet@....net>, 
	Shuah Khan <shuah@...nel.org>, Aleksa Sarai <cyphar@...har.com>, Tycho Andersen <tycho@...ho.pizza>, 
	Andrei Vagin <avagin@...il.com>, Christian Brauner <brauner@...nel.org>, 
	Stéphane Graber <stgraber@...raber.org>, 
	Tycho Andersen <tycho@...nel.org>
Subject: Re: [PATCH v2 4/6] seccomp: handle multiple listeners case

On Tue, Dec 2, 2025 at 12:52 PM Alexander Mikhalitsyn
<aleksandr.mikhalitsyn@...onical.com> 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@...r.kernel.org
> Cc: bpf@...r.kernel.org
> Cc: Kees Cook <kees@...nel.org>
> Cc: Andy Lutomirski <luto@...capital.net>
> Cc: Will Drewry <wad@...omium.org>
> Cc: Jonathan Corbet <corbet@....net>
> Cc: Shuah Khan <shuah@...nel.org>
> Cc: Aleksa Sarai <cyphar@...har.com>
> Cc: Tycho Andersen <tycho@...ho.pizza>
> Cc: Andrei Vagin <avagin@...il.com>
> Cc: Christian Brauner <brauner@...nel.org>
> Cc: Stéphane Graber <stgraber@...raber.org>
> Reviewed-by: Tycho Andersen (AMD) <tycho@...nel.org>
> Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>
> ---
>  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:

                } else if ((ACTION_ONLY(cur_ret) == ACTION_ONLY(ret)) &&
-                           ACTION_ONLY(cur_ret) == SECCOMP_RET_USER_NOTIF) {
+                          (ACTION_ONLY(cur_ret) == SECCOMP_RET_USER_NOTIF) &&
+                          f->notif) {
                        /*

After Kees's comment I have some idea about how to potentially get rid
of matches->filters static
array. I'll try to rework this.

> +                       /*
> +                        * For multiple SECCOMP_RET_USER_NOTIF results, we need to
> +                        * track all filters that resulted in the same action, because
> +                        * we might need to notify a few of them to get a final decision.
> +                        */
> +                       matches->filters[matches->n++] = f;
>                 }
>         }
>         return ret;
> @@ -1362,8 +1375,24 @@ 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.
> +                        *
> +                        * Note, that if there are multiple filters returned
> +                        * SECCOMP_RET_USER_NOTIF, and final result is
> +                        * SECCOMP_RET_USER_NOTIF too, then seccomp_run_filters()
> +                        * has populated matches.filters[] array with all of them
> +                        * in order from the lowest-level (closest to a
> +                        * current->seccomp.filter) to the highest-level.
> +                        */
> +                       if (seccomp_do_user_notification(match, &sd))
> +                               goto skip;
> +               }
>
>                 return 0;
>
> --
> 2.43.0
>