Let's note if listener was a first one installed in the seccomp
filters tree. We will need this information to retain old
quirk behavior (as before seccomp nesting introduced).

Also, rename has_duplicate_listener() to check_duplicate_listener(),
cause now this function is not read-only, but also modifies a state
of a new_child seccomp_filter.

No functional change intended at this point.

Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@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: Aleksa Sarai <cyphar@cyphar.com>
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 | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 89ae81f06743..1a139f9ef39b 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -205,6 +205,7 @@ static inline void seccomp_cache_prepare(struct seccomp_filter *sfilter)
  * @log: true if all actions except for SECCOMP_RET_ALLOW should be logged
  * @wait_killable_recv: Put notifying process in killable state once the
  *			notification is received by the userspace listener.
+ * @first_listener: true if this is the first seccomp listener installed in the tree.
  * @prev: points to a previously installed, or inherited, filter
  * @prog: the BPF program to evaluate
  * @notif: the struct that holds all notification related information
@@ -226,6 +227,7 @@ struct seccomp_filter {
 	refcount_t users;
 	bool log : 1;
 	bool wait_killable_recv : 1;
+	bool first_listener : 1;
 	struct action_cache cache;
 	struct seccomp_filter *prev;
 	struct bpf_prog *prog;
@@ -1939,7 +1941,7 @@ static struct file *init_listener(struct seccomp_filter *filter)
  * Note that @new_child is not hooked up to its parent at this point yet, so
  * we use current->seccomp.filter.
  */
-static bool has_duplicate_listener(struct seccomp_filter *new_child)
+static bool check_duplicate_listener(struct seccomp_filter *new_child)
 {
 	struct seccomp_filter *cur;
 
@@ -1953,6 +1955,8 @@ static bool has_duplicate_listener(struct seccomp_filter *new_child)
 			return true;
 	}
 
+	/* Mark first listener in the tree. */
+	new_child->first_listener = true;
 	return false;
 }
 
@@ -2035,7 +2039,7 @@ static long seccomp_set_mode_filter(unsigned int flags,
 	if (!seccomp_may_assign_mode(seccomp_mode))
 		goto out;
 
-	if (has_duplicate_listener(prepared)) {
+	if (check_duplicate_listener(prepared)) {
 		ret = -EBUSY;
 		goto out;
 	}
-- 
2.43.0

On 2025-12-11, Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com> wrote:
> Let's note if listener was a first one installed in the seccomp
> filters tree. We will need this information to retain old
> quirk behavior (as before seccomp nesting introduced).
> 
> Also, rename has_duplicate_listener() to check_duplicate_listener(),
> cause now this function is not read-only, but also modifies a state
> of a new_child seccomp_filter.
> 
> No functional change intended at this point.

Ah sorry, I didn't notice the date of the mails -- this was sent before
the LPC discussion! I'll wait for the v4 before reviewing further.

-- 
Aleksa Sarai
https://www.cyphar.com/

On Wed, 2026-01-21 at 13:22 +0100, Aleksa Sarai wrote:
> On 2025-12-11, Alexander Mikhalitsyn
> <aleksandr.mikhalitsyn@canonical.com> wrote:
> > Let's note if listener was a first one installed in the seccomp
> > filters tree. We will need this information to retain old
> > quirk behavior (as before seccomp nesting introduced).
> > 
> > Also, rename has_duplicate_listener() to
> > check_duplicate_listener(),
> > cause now this function is not read-only, but also modifies a state
> > of a new_child seccomp_filter.
> > 
> > No functional change intended at this point.
> 
> Ah sorry, I didn't notice the date of the mails -- this was sent
> before
> the LPC discussion! I'll wait for the v4 before reviewing further.

Hi Aleksa,

Yeah, I'm thinking about preparing a separate patches to address
a quirky seccomp behavior we discussed during LPC and then resend this
series.

Kind regards,
Alex

On Wed, Jan 28, 2026 at 08:05:25PM +0100, Alexander Mikhalitsyn wrote:
> Yeah, I'm thinking about preparing a separate patches to address
> a quirky seccomp behavior we discussed during LPC and then resend this
> series.

Yeah, I'd love to see it as a distinct change. :)

-- 
Kees Cook