Look up another CVE · open CVE-2026-72344 in the interactive tracker
CVE-2026-72344
net/mlx5e: TC, skip peer flow cleanup when LAG seq is unavailable
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-72344 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 | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| 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
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
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_tc.c
- What this is
- MELLANOX ETHERNET DRIVER (mlx5e)MAINTAINERS section matched on drivers/net/ethernet/mellanox/mlx5/core/en_* · netdev@vger.kernel.org · Maintained
- Kernel module
- mlx5_core
Check it on the machine
grep -wE 'CONFIG_ETHERNET|CONFIG_MLX5_CLS_ACT|CONFIG_MLX5_CORE|CONFIG_NET_VENDOR_MELLANOX' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w mlx5_corePrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian does not build this code in 3 releases. It does build it in 1 release, so the answer depends on which release the machine runs.
- bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- trixie, forky, sidn
- M
- a module where it is built at all; some flavours do not build it
- n
- not enabled on any flavour - this release does not build the code
- Build switches
- CONFIG_ETHERNET, CONFIG_MLX5_CLS_ACT, CONFIG_MLX5_CORE, CONFIG_NET_VENDOR_MELLANOX
- Reads as
- all on means the file is compiled; any one off means it is not.
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 kbuild Makefiles Debian linux-config packages
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 5.4% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- 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 |
|---|---|---|
| 7.1 | 7.1.5 | 5a95aa0198af |
| 7.1 | 7.2 | 7bed4af0ced8 |
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 bug is in mlx5e TC eswitch peer-flow teardown (mlx5e_tc_clean_fdb_peer_flows/mlx5e_tc_del_fdb_peers_flow), reached via local TC netlink, netdev/LAG reconfiguration, or driver unload—not from processing remote network packets.
- AC:LAttack complexity, low
- On mlx5 LAG/merged-eswitch systems, a caller with CAP_NET_ADMIN can install TC flower rules that create peer flows, then trigger LAG unpair/teardown so mlx5_lag_get_dev_seq() fails and the unchecked negative index is used reliably.
- PR:LPrivileges required, low
- Exploitation requires CAP_NET_ADMIN to install/delete mlx5e TC cls_flower offload rules and manipulate LAG/bond state; CAP_NET_ADMIN is obtainable in user/network namespaces and is not init-namespace root.
- UI:NUser interaction, none
- No victim interaction is required; the crash occurs during kernel-initiated peer-flow cleanup when LAG sequence lookup fails during eswitch unpair or mlx5e netdev/driver teardown.
- S:UScope, unchanged
- Impact is kernel memory corruption and crash on the host running mlx5; it does not cross a VM/hypervisor, IOMMU, or other security boundary into a separate authority.
- C:HConfidentiality impact, high
- mlx5_lag_get_dev_seq() errors (e.g., -ENOENT) are used unchecked as peer_flows[]/flow->peer[] indices, causing out-of-bounds list operations that read and corrupt adjacent kernel memory beyond the flow structures.
- I:HIntegrity impact, high
- The faulting list_del(&flow->peer[peer_index]) and peer_flows[i] walks with a negative index perform out-of-bounds linked-list writes, corrupting kernel heap/metadata and enabling further memory control primitives.
- A:HAvailability impact, high
- The fix commit documents a reproducible kernel crash (oops at mlx5e_tc_del_fdb_peers_flow) from this bad memory access during mlx5 eswitch/TC cleanup, causing complete loss of system availability.