linux-kernel - Re: [PATCH v1 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] [day] [month] [year] [list]

Message-ID: <aS2offcUPOkfkye1@tycho.pizza>
Date: Mon, 1 Dec 2025 07:38:53 -0700
From: Tycho Andersen <tycho@...nel.org>
To: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>
Cc: kees@...nel.org, 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>, Andrei Vagin <avagin@...il.com>,
	Christian Brauner <brauner@...nel.org>,
	Stéphane Graber <stgraber@...raber.org>
Subject: Re: [PATCH v1 4/6] seccomp: handle multiple listeners case

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@...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: Tycho Andersen <tycho@...ho.pizza>
> Cc: Andrei Vagin <avagin@...il.com>
> Cc: Christian Brauner <brauner@...nel.org>
> Cc: Stéphane Graber <stgraber@...raber.org>
> Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@...onical.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@...nel.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