CVE-2026-72072 in Linux
Summary
by MITRE • 08/15/2026
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).
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists in the Linux kernel's mlx5e MACsec implementation where a use-after-free condition can occur during the deletion of offloaded RX security associations. The flaw specifically manifests when macsec_del_rxsc_ctx() function calls metadata_dst_free() to release per-SC metadata_dst objects, which unconditionally frees memory without checking reference counts. This creates a race condition between the deletion path and active data processing threads that maintain references to the freed memory structure.
The core technical issue stems from improper reference counting management in the MACsec subsystem where dst_release() should be used instead of direct kfree() operations on metadata_dst objects. The RX datapath in mlx5e_macsec_offload_handle_rx_skb() performs lookups under rcu_read_lock() using xa_load() and takes references with dst_hold(), but fails to ensure that the referenced object remains valid throughout the operation. When a reader obtains an rx_sc pointer and then a deletion occurs, the system operates on memory that has already been freed, leading to potential kernel crashes or memory corruption.
The operational impact of this vulnerability is significant as it can cause system instability through kernel panics or unpredictable behavior when MACsec offloaded traffic processing encounters concurrent delete operations. Attackers could potentially exploit this race condition to trigger denial-of-service conditions or escalate privileges by manipulating the timing of packet processing and security context deletion. The vulnerability affects systems using Mellanox mlx5e network drivers with MACsec offloading capabilities, particularly in high-throughput networking environments where concurrent packet processing and security context management occur.
The fix addresses multiple related issues through proper reference counting and ordering constraints. First, it changes the cleanup mechanism to use dst_release() instead of unconditional kfree(), ensuring that memory is only freed when all references are properly released. Second, it modifies the RX datapath to use dst_hold_safe() which prevents attaching dst objects whose last reference has just been dropped. Third, the function ordering in mlx5e_macsec_add_rxsc() is corrected so that xa_alloc() publishing occurs only after md_dst is fully initialized, preventing readers from observing partially constructed objects. This approach follows established patterns for concurrent data structure access and memory management.
This vulnerability aligns with CWE-416 Use After Free, which describes the condition where a program continues to use a pointer after the memory it points to has been freed. The issue also relates to CWE-362 Concurrency Issues, specifically race conditions that occur when multiple threads access shared data structures without proper synchronization. From an ATT&CK perspective, this represents a potential privilege escalation vector through kernel memory corruption, categorized under T1068 Exploitation for Privilege Escalation and T1547.001 Registry Run Keys / Startup Folder. The fix demonstrates proper application of RCU (Read-Copy-Update) patterns and memory ordering principles that are fundamental to safe concurrent programming in kernel space.
The vulnerability was discovered through automated security research tooling, highlighting the importance of systematic testing for race conditions in complex kernel subsystems. The separate pre-existing issue mentioned about rx_sc->sc_xarray_element cleanup without RCU grace period indicates that this fix addresses only part of a larger set of related concurrency problems that may require additional patches to fully resolve. Proper handling of memory ordering and reference counting in network driver subsystems is crucial for maintaining system stability when dealing with concurrent packet processing and security context management operations that are common in enterprise networking environments.