Skip to main content
VulnerabilityPublished Updated

CVE-2026-72072: Linux kernel · Use After Free

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 7.8 High · fixed in ed3cc4218070d6b98bf5fb456dccae424fd38c4f : patch Linux kernel soon.

Data as of 26 Oct 2026, 17:16 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.1% chance of exploitation in 30 days – higher than 6% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in ed3cc4218070d6b98bf5fb456dccae424fd38c4f, de74d8fd10291763d97b218f09adcc7513c975e4, b1a4d0c568bbb52c7c04f4fce3c097dae89ed6cb +3
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 15 Aug 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ b7c9400cbc48c3713190b3bce4e0c87e924e4104, < ed3cc4218070d6b98bf5fb456dccae424fd38c4f
Fixed in
  • ed3cc4218070d6b98bf5fb456dccae424fd38c4f
LinuxLinuxAffected
  • ≥ b7c9400cbc48c3713190b3bce4e0c87e924e4104, < de74d8fd10291763d97b218f09adcc7513c975e4
Fixed in
  • de74d8fd10291763d97b218f09adcc7513c975e4
LinuxLinuxAffected
  • ≥ b7c9400cbc48c3713190b3bce4e0c87e924e4104, < b1a4d0c568bbb52c7c04f4fce3c097dae89ed6cb
Fixed in
  • b1a4d0c568bbb52c7c04f4fce3c097dae89ed6cb
LinuxLinuxAffected
  • ≥ b7c9400cbc48c3713190b3bce4e0c87e924e4104, < 088873af13590ebde10de2ade847f57a05ec61c6
Fixed in
  • 088873af13590ebde10de2ade847f57a05ec61c6
LinuxLinuxAffected
  • ≥ b7c9400cbc48c3713190b3bce4e0c87e924e4104, < 218cc15a4c907659ad4b0e68c535c61594311205
Fixed in
  • 218cc15a4c907659ad4b0e68c535c61594311205
LinuxLinuxAffected
  • ≥ b7c9400cbc48c3713190b3bce4e0c87e924e4104, < 4a5073b7b30243658f58b2d2d35a823da7fd34d9
Fixed in
  • 4a5073b7b30243658f58b2d2d35a823da7fd34d9

Description

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete When an offloaded MACsec RX SC is deleted, macsec_del_rxsc_ctx() freed the per-SC metadata_dst with metadata_dst_free(), which kfree()s the object unconditionally and ignores the dst reference count. The RX datapath in mlx5e_macsec_offload_handle_rx_skb() looks up the SC under rcu_read_lock() via xa_load(), takes a reference with dst_hold() and attaches the dst to the skb with skb_dst_set(). A reader that already obtained the rx_sc pointer can race with the delete path and operate on freed memory. Fix the owner side by dropping the reference with dst_release() instead of freeing unconditionally, and convert the RX datapath to dst_hold_safe() so a reader racing the SC delete cannot attach a dst whose last reference was just dropped; only attach it when a reference was actually taken. mlx5e_macsec_add_rxsc() also published sc_xarray_element via xa_alloc() before rx_sc->md_dst was allocated and initialised, so a datapath reader that looked the SC up by fs_id could observe rx_sc with md_dst still NULL or, on weakly-ordered architectures, a non-NULL md_dst pointer whose contents were not yet visible. NULL-check the xa_load() result and md_dst on the datapath, and reorder add_rxsc() so the xa_alloc() publish happens only after md_dst is fully initialised; the xarray RCU publish then pairs with the rcu_read_lock()/xa_load() in the datapath. Note: macsec_del_rxsc_ctx() also kfree()s rx_sc->sc_xarray_element without an RCU grace period while the same datapath reads it under rcu_read_lock(); that is a separate pre-existing issue left to a follow-up patch. Found by 0sec automated security-research tooling (https://0sec.ai).

References

Community reviews

Loading reviews…