CVE-2026-98014: net/mlx5: E-Switch, prevent mc_list repopulation during vport disable
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: E-Switch, prevent mclist repopulation during vport disable
In mlx5eswvportdisable(), move eswapplyvportrxmode() ahead of eswvportchangehandlelocked() so vport->allmultirule is NULL before the change handler observes it.
During FW-fatal recovery the disable runs while dev->state == INTERNALERROR. The promisc query inside eswupdatevportrxmode() fails and returns early, leaving vport->allmultirule intact, so eswupdatevportmcpromisc() runs and adds MLX5ACTIONADD entries to vport->mclist whose flow rules are then installed in the FDB by eswaddmcaddr(). eswdestroylegacytable() tears down the FDB with those refs still held, corrupting the sub-tree and leaving dangling flowrule pointers in vport->mclist.
Two-stage failure on echo 1 > /sys/bus/pci/devices/<bdf>/reset:
refcountt: underflow; use-after-free. treeputnode+0xef/0x110 [mlx5core] cleantree+0x44/0xd0 [mlx5core] (x5) mlx5fscorecleanup+0x57/0x1c0 [mlx5core] mlx5unload+0x65/0xd0 [mlx5core] ... mlx5healthtryrecover
BUG: unable to handle page fault for address: 0000000003000055 downwrite+0x1c/0x60 mlx5delflowrules+0x33/0x1f0 [mlx5core] eswdelmcaddr+0x7b/0x170 [mlx5core] eswapplyvportaddrlist+0x56/0xf0 [mlx5core] eswvportchangehandlelocked+0x28b/0x310 [mlx5core] mlx5eswvportenable+0x270/0x4a0 [mlx5core] ... mlx5load ... mlx5healthtryrecover
eswapplyvportrxmode(false, false) clears vport->allmultirule via its local state machine even when the FW del fails. With the rule NULL the !ISERRORNULL(allmultirule) gate in the change handler closes, no rules are installed during disable, and the reload starts with a clean mclist.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this failure path?
The affected path involves the Linux kernel mlx5 E-Switch vport-disable handling. It is specifically described during firmware-fatal recovery, when the device state is INTERNAL_ERROR and the E-Switch FDB is being torn down.
What event can trigger the reported failure?
The report describes a two-stage failure after issuing a PCI device reset through the device's sysfs reset attribute. During recovery, a failed promiscuous-mode query can leave multicast flow-rule references in place while the FDB is destroyed.
How can administrators recognize that the system has hit this issue?
Reported indicators include a refcount underflow and use-after-free involving mlx5_core cleanup paths, followed by a page fault. The affected paths include tree_put_node, clean_tree, mlx5_fs_core_cleanup, mlx5_unload, and mlx5_health_try_recover.