Bug 2524478 (CVE-2026-80521)

Summary: CVE-2026-80521 kernel: af_unix: Unlink scc_entry in unix_del_edge()
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: akito5623, rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel's `af_unix` component. A race condition during concurrent `send()` and `close()` operations can lead to the garbage collector (GC) partially freeing a Strongly Connected Component (SCC). This inconsistent state may cause subsequent GC operations to iterate over a partially freed entry, potentially leading to system instability or a denial of service.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-08-26 14:58:28 UTC
In the Linux kernel, the following vulnerability has been resolved:

af_unix: Unlink scc_entry in unix_del_edge().

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 unix_add_edges()
publishes a new edge (B <-> B) to GC but its skb is not queued
by skb_queue_tail().

If 2-2) completes before skb_queue_tail() 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 unix_walk_scc_fast(),
and it iterates over A through B's scc_entry.

Let's unlink scc_entry before freeing the vertex in unix_del_edge().

Comment 3 Akiyoshi Kurita 2026-09-23 03:55:03 UTC
Public exploit code related to this issue appears to be available:

Exploit:
https://github.com/Markakd/Container_escape

Demonstration video:
https://x.com/Markak_/status/2102478278594543807

However, the demonstration video does not clearly identify whether it is specifically demonstrating CVE-2026-80521, CVE-2026-52910, or a combination of both issues.

Upstream patch / CVE announcement:
https://lore.kernel.org/linux-cve-announce/2026082601-CVE-2026-80521-2b35@gregkh/T/#u

Could Red Hat please verify whether the published exploit affects RHEL kernels and whether this exploit is specifically applicable to CVE-2026-80521?

If a demonstration video specifically showing exploitation of CVE-2026-80521 is available, I would also be interested in reviewing it.