From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E60E931A571; Mon, 1 Dec 2025 14:38:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764599937; cv=none; b=NC8iKJXf1rR3gMtmtdcpdZdB8pym5wiiV0D9n2vz3z7SPwEEz6f+d3/hhhaX9eSAuUf/HvXYjm1c+7caqHq9DIp982znT2pnZp9rjnpxXDyGE2xWyr/4aCtHEQDdBvq9gGA1JSYlhpiuv+tlGlbyb2YFIq7jYF1yMMSChhuHycI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764599937; c=relaxed/simple; bh=yW+sOXih+CLGwUctcH2iHTN+9YC5Pg+tYmbUnjut2mk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=u9Vk3p86fihSwFlIKQAKNA65UnmfoikUv+hhhu9vKJsUtc+7XNWW6WJLeWmxQvwAGLs/4FPB135LDizxqRMB8rxasXXx4VMlVqcbL61Mo8yZJudu9tdW8kELNR88GRGvZeRM+z1Vj1lMw+c7nHEpnc/bE4zMBqOhXnsdep42qt8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WfC5dtn+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WfC5dtn+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2759FC16AAE; Mon, 1 Dec 2025 14:38:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764599936; bh=yW+sOXih+CLGwUctcH2iHTN+9YC5Pg+tYmbUnjut2mk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WfC5dtn+4JmURdF52RQ08zTX1C301e9FxJUJ9i86OKurVVHa3fcj/3cTxYXIza0Pq AXqNjv3f3yUAr98DQdG6gTsL7BNutITR/SZAZ0M+/hAn7ZxLgRqxYdty4VxJf70aaU Q3N1pr2nLn3z31I1VpqpDSMtJmQoNGCDPhK2bEjRChVxndsqvlwIidoFqZtwv5U27E gthUUH5gxq/MZt28iHAMds7H2af2K8e9VidQzA0Rs8xwiLAMyj4RBW+Dt3Yd/9Rfci 3bfBw/vi/L0++dOxqKnhAPU/5Tce2OkM3oNcEFs4zzSZXwN6rtYMXCqNIF1sj3m21s xBv2tsLQjVGTw== Date: Mon, 1 Dec 2025 07:38:53 -0700 From: Tycho Andersen To: Alexander Mikhalitsyn Cc: kees@kernel.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, Andy Lutomirski , Will Drewry , Jonathan Corbet , Shuah Khan , Andrei Vagin , Christian Brauner , =?iso-8859-1?Q?St=E9phane?= Graber Subject: Re: [PATCH v1 4/6] seccomp: handle multiple listeners case Message-ID: References: <20251201122406.105045-1-aleksandr.mikhalitsyn@canonical.com> <20251201122406.105045-5-aleksandr.mikhalitsyn@canonical.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20251201122406.105045-5-aleksandr.mikhalitsyn@canonical.com> 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 > Cc: Andy Lutomirski > Cc: Will Drewry > Cc: Jonathan Corbet > Cc: Shuah Khan > Cc: Tycho Andersen > Cc: Andrei Vagin > Cc: Christian Brauner > Cc: Stéphane Graber > Signed-off-by: Alexander Mikhalitsyn > --- > 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) 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