CVE-2026-80521: af_unix: Unlink scc_entry in unix_del_edge().

Published Aug 26, 2026
·
Updated

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

afunix: Unlink sccentry in unixdeledge().

Kyle Zeng reported that GC could free a dead SCC partially.

The scenario is as follows:

1) Create two SCCs:

X -. A <-> B ^--'

2) Run the following concurrently:

2-1) send() sk-B to sk-B from sk-X 2-2) close() both A and B

At 2-1), there is a small window where unixaddedges() publishes a new edge (B <-> B) to GC but its skb is not queued by skbqueuetail().

If 2-2) completes before skbqueuetail() and GC is triggered, it judges A <-> B as dead, but B is not freed because GC cannot collect the not-yet-queued skb holding the B <-> B edge.

X -. A <-> B -. This edge is visible ^--' ^..' but skb is not

This itself is not a problem since the next GC run will judge B as dead as well and free it finally.

X -. A <.> B -. ^--' ^--'

However, X's SCC forces the next GC to call unixwalksccfast(), and it iterates over A through B's sccentry.

Let's unlink sccentry before freeing the vertex in unixdeledge().

Affected Software

1 affected component
Linux Linux kernel

Event History

Aug 26, 2026
CVE Published
via MITRE·02:37 PM
Data Sourced
via MITRE·02:37 PM
Description
Data Sourced
via NVD·03:17 PM
Description

Frequently Asked Questions

1

What conditions are required to trigger this issue?

The reported race requires concurrent UNIX-domain socket activity: a send() that creates and publishes a new garbage-collection edge while both sockets in an existing strongly connected component are being closed. Garbage collection must run during the small interval after the edge is published but before its skb is queued.

2

How could an affected system behave?

Garbage collection can partially free a dead strongly connected component, leaving a stale scc_entry reachable during a later GC walk. The provided information does not specify a user-visible symptom, crash behavior, or security impact beyond this unsafe kernel state.

3

How can I determine whether the fix is present?

Check whether the kernel includes either referenced stable commit: e3702470ced94fad74d71e2232f022d2eb752a6d or 594d905195024b228c962627ae5ae7c17bd582a4. The supplied data does not identify affected or fixed kernel version numbers.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203