CVE-2026-72072

Received Received - Intake

Use-After-Free in Linux Kernel MLX5e MACsec Driver

Publication date: 2026-08-15

Last updated on: 2026-08-17

Assigner: kernel.org

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).

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-08-15

Last Modified

2026-08-17

Generated

2026-09-04

AI Q&A

2026-08-15

EPSS Evaluated

2026-09-03

NVD

CVE-2026-72072

EUVD

EUVD-2026-59030

Affected Vendors & Products

Vendor	Product	Version / Range
linux	linux_kernel	*

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-UNKNOWN

Attack-Flow Graph

Executive Summary

This vulnerability is a use-after-free issue in the Linux kernel's MACsec RX SC (Receive Secure Channel) handling. When an offloaded MACsec RX SC is deleted, the metadata_dst object is freed without checking reference counts, allowing a race condition where a reader might access freed memory. The fix involves properly releasing references instead of freeing unconditionally and using safer reference handling in the datapath.

Detection Guidance

This vulnerability is specific to the Linux kernel's mlx5e MACsec offload feature. Detection requires checking kernel logs for MACsec-related errors or crashes, particularly during RX SC deletion. Commands like dmesg | grep -i macsec or journalctl -k | grep -i macsec may reveal issues. Ensure your kernel version is updated to a patched release.

Impact Analysis

This vulnerability could lead to memory corruption, crashes, or potential privilege escalation if exploited. Systems using the Linux kernel with MACsec offloading enabled are at risk, especially if an attacker can trigger RX SC deletion while the datapath is active.

Compliance Impact

This vulnerability does not directly affect compliance with standards like GDPR or HIPAA as it is a Linux kernel memory management issue in the MACsec offload feature. Compliance impacts would depend on system configuration and usage rather than the vulnerability itself.

Mitigation Strategies

Update your Linux kernel to the latest stable version that includes the fix for CVE-2026-72072. Disable MACsec offload if not required by setting the kernel parameter mlx5_core.macsec=0. Monitor kernel logs for MACsec-related errors after applying updates.

Hi! I’m here to help you understand CVE-2026-72072. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70