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).
Published: 2026-08-15
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

Based on the description, it is inferred that the flaw arises when a MACsec receive security context is deleted while the driver still holds a reference to its metadata. The unguarded free allows an attacker to cause the kernel to dereference dangling memory, which can corrupt critical kernel structures or crash the system. If an attacker can trigger this race condition, they could gain kernel‑level execution and full control of the host.

Affected Systems

All Linux installations that load the mlx5e driver and enable MACsec offloading are affected. The vulnerability is present in any kernel version that includes the unpatched mlx5e code path for MACsec receive sessions, regardless of the chipset vendor, and remains until the CVE‑2026‑72072 patch is applied.

Risk and Exploitability

The CVSS score of 7.8 places it at high severity, but the EPSS score of less than 1% indicates a very low current exploitation probability. The vulnerability is not listed in the CISA KEV catalog. Based on the description, it is inferred that exploitation would require an attacker who can influence MACsec traffic to an interface using the mlx5e driver, such as by sending crafted MACsec frames. The likely attack vector therefore requires kernel‑level access to the NIC’s MACsec state, making it a higher‑complexity, targeted threat rather than a broad‑scale attack vector.

Generated by OpenCVE AI on August 18, 2026 at 05:44 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply a kernel update that incorporates the CVE‑2026‑72072 fix.
  • If a kernel upgrade is not immediately possible, disable MACsec offloading on the affected interfaces with ethtool –K <iface> macsec off or by loading the driver with a module option that turns off MACsec support.
  • Continuously monitor kernel logs for Oops, panic, crash messages related to mlx5e or MACsec, and promptly apply any subsequent security updates.

Generated by OpenCVE AI on August 18, 2026 at 05:44 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Tue, 18 Aug 2026 04:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Tue, 18 Aug 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-825
References
Metrics threat_severity

None

threat_severity

Moderate


Mon, 17 Aug 2026 21:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Mon, 17 Aug 2026 19:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Mon, 17 Aug 2026 06:00:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}


Sat, 15 Aug 2026 21:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Sat, 15 Aug 2026 06:00:00 +0000

Type Values Removed Values Added
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).
Title net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-17T05:40:03.099Z

Reserved: 2026-08-09T03:40:39.904Z

Link: CVE-2026-72072

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-15T06:21:16.943

Modified: 2026-08-17T06:18:05.787

Link: CVE-2026-72072

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-08-15T00:00:00Z

Links: CVE-2026-72072 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-18T05:45:03Z

Weaknesses
  • CWE-825

    Expired Pointer Dereference