CVE-2026-72344 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: TC, skip peer flow cleanup when LAG seq is unavailable
mlx5_lag_get_dev_seq() will return error when the peer isn't in the LAG or when no device is marked as master. Result bad memory access and kernel crash[1].
Hence, skip the peer when lookup fails.
Note: In case there are peer flows, they are cleaned before LAG cleared the master mark.
[1]
RIP: 0010:mlx5e_tc_del_fdb_peers_flow+0x3d/0x350 [mlx5_core]
Call Trace: <TASK> mlx5e_tc_clean_fdb_peer_flows+0xc1/0x130 [mlx5_core]
mlx5_esw_offloads_unpair+0x3a/0x400 [mlx5_core]
mlx5_esw_offloads_devcom_event+0xee/0x360 [mlx5_core]
mlx5_devcom_send_event+0x7a/0x140 [mlx5_core]
mlx5_esw_offloads_devcom_cleanup+0x2f/0x90 [mlx5_core]
mlx5e_tc_esw_cleanup+0x28/0xf0 [mlx5_core]
mlx5e_rep_tc_cleanup+0x19/0x30 [mlx5_core]
mlx5e_cleanup_uplink_rep_tx+0x36/0x40 [mlx5_core]
mlx5e_cleanup_rep_tx+0x55/0x60 [mlx5_core]
mlx5e_detach_netdev+0x96/0xf0 [mlx5_core]
mlx5e_netdev_change_profile+0x5b/0x120 [mlx5_core]
mlx5e_netdev_attach_nic_profile+0x1b/0x30 [mlx5_core]
mlx5e_vport_rep_unload+0xdd/0x110 [mlx5_core]
__esw_offloads_unload_rep+0x81/0xb0 [mlx5_core]
mlx5_eswitch_unregister_vport_reps+0x1d7/0x220 [mlx5_core]
mlx5e_rep_remove+0x22/0x30 [mlx5_core]
device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xe8/0x1b0 device_del+0x159/0x3c0 mlx5_rescan_drivers_locked+0xbc/0x2d0 [mlx5_core]
mlx5_unregister_device+0x54/0x80 [mlx5_core]
mlx5_uninit_one+0x73/0x130 [mlx5_core]
remove_one+0x78/0xe0 [mlx5_core]
pci_device_remove+0x39/0xa0
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists within the linux kernel's mlx5e network driver component, specifically affecting the traffic control functionality when managing link aggregation groups. The issue stems from improper error handling in the mlx5_lag_get_dev_seq() function which is responsible for retrieving device sequence information within a LAG configuration. When this function encounters scenarios where the peer device is not part of the LAG or when no device is marked as master, it returns an error code instead of gracefully handling the absence of valid sequence information. This failure condition leads to subsequent bad memory access patterns and ultimately results in kernel crashes during network flow cleanup operations.
The technical flaw manifests through a classic null pointer dereference scenario where the system attempts to process peer flows without proper validation of the underlying LAG sequence availability. The call trace demonstrates this vulnerability occurring within the mlx5e_tc_del_fdb_peers_flow function which is part of the traffic control cleanup path for the mlx5 core driver. When peer flow cleanup is initiated, the system fails to properly check whether the required LAG sequence information is available before attempting memory operations, creating a direct pathway for kernel panics and system instability.
The operational impact of this vulnerability extends beyond simple system crashes to potentially disrupt network connectivity and service availability in data center environments utilizing mellanox mlx5 network adapters. The vulnerability affects systems where link aggregation is configured and peer flows are being managed, particularly during device removal or driver unloading sequences. This creates a denial-of-service condition that can impact networking operations across the entire system, especially in high-availability environments where continuous network operation is critical.
The mitigation strategy involves implementing proper error checking and graceful degradation when LAG sequence information is unavailable, as indicated by the fix approach of skipping peer cleanup when lookups fail. This aligns with established security practices for kernel-level memory safety and proper error handling. The solution follows common patterns for preventing null pointer dereferences and uninitialized memory access that are consistent with both common weakness enumeration standards and attack technique frameworks. Organizations should ensure their mlx5 network driver installations are updated to versions containing this specific fix, as the vulnerability represents a clear path to kernel-level exploitation through improper resource management and memory access patterns.
This vulnerability type relates to CWE-476 which covers NULL pointer dereference conditions, and also maps to ATT&CK technique T1490 for endpoint denial of service. The flaw demonstrates how improper error handling in network driver components can create exploitable conditions that compromise system stability and availability, making it a critical security concern for enterprise infrastructure relying on mlx5 network hardware.