CVE-2026-23394

/// Technical description

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 <------.

\

`--

/// Remediation

Check the references section for vendor advisories, patches, and mitigation guidance. If immediate patching is not possible, review the CVSS vector to understand the attack surface and apply compensating controls such as network segmentation or access restrictions.

/// References