Look up another CVE · open CVE-2026-72072 in the interactive tracker
CVE-2026-72072
net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-72072 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixed | 6.1.180-1 | Update the kernel and reboot. Fixed in 6.1.180-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.100-1 | Update the kernel and reboot. Fixed in 6.12.100-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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).
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec.c
- What this is
- MELLANOX ETHERNET INNOVA DRIVERSMAINTAINERS section matched on drivers/net/ethernet/mellanox/mlx5/core/en_accel/* · netdev@vger.kernel.org · Maintained
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid?
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS
Signals
- Published
- 2026-08-15 (2 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 6.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.1 | 6.1.178 | b1a4d0c568bb |
| 6.1 | 6.6.145 | 218cc15a4c90 |
| 6.1 | 6.12.97 | 4a5073b7b302 |
| 6.1 | 6.18.40 | ed3cc4218070 |
| 6.1 | 7.1.5 | 088873af1359 |
| 6.1 | 7.2 | de74d8fd1029 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The UAF is reached by racing MACSEC_CMD_DEL_RXSC/ADD_RXSC netlink configuration (GENL_ADMIN_PERM) against mlx5e MACsec RX processing; the privileged genlink/rtnl control path is required to trigger the bug, not remote packets alone.
- AC:LAttack complexity, low
- An attacker with CAP_NET_ADMIN can drive both sides by looping RX SC add/delete while flooding MACsec-offloaded RX traffic on the mlx5e netdev, reliably winning the RCU race between xa_load/dst_hold and metadata_dst_free.
- PR:LPrivileges required, low
- MACsec offload mutations require GENL_ADMIN_PERM (CAP_NET_ADMIN); on Mellanox ConnectX/BlueField systems this is reachable by cloud tenants with SR-IOV VFs, containers, or user/network namespaces without init-namespace root.
- UI:NUser interaction, none
- No victim user action is needed; automated concurrent netlink MACsec operations and incoming MACsec-offloaded frames on an active mlx5e interface suffice once MACsec offload is configured.
- S:UScope, unchanged
- Impact is kernel heap use-after-free and memory corruption within the host kernel on the mlx5 NIC; it enables local privilege escalation but does not by itself cross VM, IOMMU, or hypervisor security boundaries.
- C:HConfidentiality impact, high
- The race calls dst_hold() and skb_dst_set() on a freed metadata_dst, a classic slab UAF that can disclose kernel memory through subsequent dst_entry and MACsec skb metadata handling.
- I:HIntegrity impact, high
- Freed metadata_dst objects can be reallocated via heap spraying while the RX datapath still references them, enabling refcount corruption and arbitrary kernel memory writes or control-flow hijack beyond a mere crash.
- A:HAvailability impact, high
- Concurrent use of freed md_dst during mlx5e MACsec RX processing can cause immediate kernel oops, BUG, or panic on datacenter/cloud hosts using mlx5 hardware MACsec offload, fully denying system availability.