Re: [PATCH 1/2] af_unix: Do not wait for garbage collector in sendmsg()

On Thu, Jul 2, 2026 at 10:53 PM Nam Cao [off-list ref] wrote:

sashiko-bot@kernel.org writes:

quoted

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Garbage collector is no longer scheduled when creating new inflight FDs, leading to permanent cycle accumulation and -ETOOMANYREFS failures in isolated environments.
--

commit 506189bd29f8ad56f5d9e51f3e0216203ebad5ec
Author: Nam Cao [off-list ref]

af_unix: Do not wait for garbage collector in sendmsg()

This patch removes the garbage collector scheduling and waiting from the
sendmsg() path for AF_UNIX sockets. It aims to prevent priority inversion
by relying on RLIMIT_NOFILE limits and asynchronous garbage collection.

quoted

diff --git a/net/unix/garbage.c b/net/unix/garbage.c
index 0783555e25266..f180c59b3da9d 100644
--- a/net/unix/garbage.c
+++ b/net/unix/garbage.c

@@ -300,8 +300,6 @@ int unix_prepare_fpl(struct scm_fp_list *fpl)
     if (!fpl->edges)
             goto err;

-    unix_schedule_gc(fpl->user);
-

[Severity: High]
Does this removal prevent the garbage collector from running when a process
creates isolated socket cycles?

If a process continuously creates socket cycles (e.g., passing FDs to each
other) and closes its local FDs, the sockets reference each other in their
receive queues, so their file reference counts will not reach zero.

Because the refcounts do not drop to zero, unix_release_sock() is never
triggered. By removing unix_schedule_gc() from unix_prepare_fpl() here,
unix_release_sock() is left as the only trigger for garbage collection.

This could allow the inflight count to accumulate indefinitely until it
hits RLIMIT_NOFILE, causing subsequent sendmsg() calls to fail with
-ETOOMANYREFS and permanently leaking the network namespace unless an
unrelated AF_UNIX socket is closed system-wide.

Sashiko found a valid issue here.

This is same with my point, and

But this is a pre-existing issue. It
is not introduced in this patch.

your patch makes it much easier to abuse.
UNIX_INFLIGHT_SANE_USER is usually much smaller than
RLIMIT_NOFILE.

unix_schedule_gc() in sendmsg() is to self-regulate malicious users,
otherwise GC relies on unrelated AF_UNIX socket's close() and could
be triggered too late since GC is system-wide.

Previously every sendmsg() had to wait for GC, and now it's only when
there is a circular reference AND user has too many inflight sockets.

Please fix the root cause; the former condition on your system.
--
pw-bot: cr