CVE-2026-23394 — af_unix: Give up GC if MSG_PEEK intervened.

Affected: Linux

In the Linux kernel, the following vulnerability has been resolved:

af_unix: Give up GC if MSG_PEEK intervened.

Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro.

This is the exact same issue previously fixed by commit cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK").

After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue.

The problem is that MSG_PEEK bumps a file refcount without interacting with GC.

Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B.

The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B.

GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2

close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true

Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds.

However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous e…

Most recent entries from all

CVE-2026-23394 — af_unix: Give up GC if MSG_PEEK intervened.