Bug 2524478 (CVE-2026-80521) - CVE-2026-80521 kernel: af_unix: Unlink scc_entry in unix_del_edge()
Summary: CVE-2026-80521 kernel: af_unix: Unlink scc_entry in unix_del_edge()
Keywords:
Status: NEW
Alias: CVE-2026-80521
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-08-26 14:58 UTC by OSIDB Bzimport
Modified: 2026-11-11 11:32 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2026:77634 0 None None None 2026-10-07 15:42:30 UTC
Red Hat Product Errata RHSA-2026:81406 0 None None None 2026-10-12 18:51:15 UTC
Red Hat Product Errata RHSA-2026:98608 0 None None None 2026-11-11 11:32:06 UTC

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.

Comment 6 Jon Orris 2026-10-07 15:42:29 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 10.0 Extended Update Support

Via RHSA-2026:77634 https://access.redhat.com/errata/RHSA-2026:77634

Comment 7 Jon Orris 2026-10-12 18:51:14 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 10

Via RHSA-2026:81406 https://access.redhat.com/errata/RHSA-2026:81406

Comment 8 errata-xmlrpc 2026-11-11 11:32:05 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 10

Via RHSA-2026:98608 https://access.redhat.com/errata/RHSA-2026:98608


Note You need to log in before you can comment on or make changes to this bug.