[PATCH v3 3/7] seccomp: keep track of seccomp filters with closed listeners

Alexander Mikhalitsyn posted 7 patches 2 months ago
[PATCH v3 3/7] seccomp: keep track of seccomp filters with closed listeners
Posted by Alexander Mikhalitsyn 2 months ago
Let's distinguish seccomp filters with closed listener
vs seccomp filters which never had listener.

We can easily do this by using the same ->notif pointer
field with help of IS_ERR_OR_NULL().

No functional change intended.

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 | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 236c96276405..89ae81f06743 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -1182,7 +1182,7 @@ static int seccomp_do_user_notification(struct seccomp_filter *match,
 
 	mutex_lock(&match->notify_lock);
 	err = -ENOSYS;
-	if (!match->notif)
+	if (IS_ERR_OR_NULL(match->notif))
 		goto out;
 
 	n.task = current;
@@ -1252,7 +1252,7 @@ static int seccomp_do_user_notification(struct seccomp_filter *match,
 	 * *reattach* to a notifier right now. If one is added, we'll need to
 	 * keep track of the notif itself and make sure they match here.
 	 */
-	if (match->notif)
+	if (!IS_ERR_OR_NULL(match->notif))
 		list_del(&n.list);
 out:
 	mutex_unlock(&match->notify_lock);
@@ -1460,8 +1460,14 @@ static long seccomp_set_mode_strict(void)
 #ifdef CONFIG_SECCOMP_FILTER
 static void seccomp_notify_free(struct seccomp_filter *filter)
 {
-	kfree(filter->notif);
-	filter->notif = NULL;
+	if (!IS_ERR_OR_NULL(filter->notif))
+		kfree(filter->notif);
+
+	/*
+	 * We want to know if a filter never had a notify fd,
+	 * or it is just been closed at some point.
+	 */
+	filter->notif = ERR_PTR(-ENOTCONN);
 }
 
 static void seccomp_notify_detach(struct seccomp_filter *filter)
@@ -1943,7 +1949,7 @@ static bool has_duplicate_listener(struct seccomp_filter *new_child)
 	if (!new_child->notif)
 		return false;
 	for (cur = current->seccomp.filter; cur; cur = cur->prev) {
-		if (cur->notif)
+		if (!IS_ERR_OR_NULL(cur->notif))
 			return true;
 	}
 
-- 
2.43.0

Re: [PATCH v3 3/7] seccomp: keep track of seccomp filters with closed listeners
Posted by Aleksa Sarai 2 weeks, 5 days ago
On 2025-12-11, Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com> wrote:
> Let's distinguish seccomp filters with closed listener
> vs seccomp filters which never had listener.
> 
> We can easily do this by using the same ->notif pointer
> field with help of IS_ERR_OR_NULL().
> 
> No functional change intended.

The discussion we had at LPC made me think this would result in a
(justifiable) functional change to fix this bug, but you're quite right
that this only matters once you enable nested listeners.

In either case, feel free to take my

Reviewed-by: Aleksa Sarai <cyphar@cyphar.com>

Thanks!

-- 
Aleksa Sarai
https://www.cyphar.com/
Re: [PATCH v3 3/7] seccomp: keep track of seccomp filters with closed listeners
Posted by Alexander Mikhalitsyn 1 week, 5 days ago
On Wed, 2026-01-21 at 13:20 +0100, Aleksa Sarai wrote:
> On 2025-12-11, Alexander Mikhalitsyn
> <aleksandr.mikhalitsyn@canonical.com> wrote:
> > Let's distinguish seccomp filters with closed listener
> > vs seccomp filters which never had listener.
> > 
> > We can easily do this by using the same ->notif pointer
> > field with help of IS_ERR_OR_NULL().
> > 
> > No functional change intended.
> 
> The discussion we had at LPC made me think this would result in a
> (justifiable) functional change to fix this bug, but you're quite
> right
> that this only matters once you enable nested listeners.
> 
> In either case, feel free to take my
> 
> Reviewed-by: Aleksa Sarai <cyphar@cyphar.com>

Thanks, Aleksa ;)

Kind regards,
Alex

> 
> Thanks!