CVE-2026-98014

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: E-Switch, prevent mc list repopulation during vport disable

In mlx5 esw vport disable(), move esw apply vport rx mode() ahead of esw vport change handle locked() so vport->allmulti rule is NULL before the change handler observes it.

During FW-fatal recovery the disable runs while dev->state == INTERNAL ERROR. The promisc query inside esw update vport rx mode() fails and returns early, leaving vport->allmulti rule intact, so esw update vport mc promisc() runs and adds MLX5 ACTION ADD entries to vport->mc list whose flow rules are then installed in the FDB by esw add mc addr(). esw destroy legacy table() tears down the FDB with those refs still held, corrupting the sub-tree and leaving dangling flow rule pointers in vport->mc list.

Two-stage failure on echo 1 > /sys/bus/pci/devices/<bdf>/reset:

refcount t: underflow; use-after-free. tree put node+0xef/0x110 [mlx5 core] clean tree+0x44/0xd0 [mlx5 core] (x5) mlx5 fs core cleanup+0x57/0x1c0 [mlx5 core] mlx5 unload+0x65/0xd0 [mlx5 core] ... mlx5 health try recover

BUG: unable to handle page fault for address: 0000000003000055 down write+0x1c/0x60 mlx5 del flow rules+0x33/0x1f0 [mlx5 core] esw del mc addr+0x7b/0x170 [mlx5 core] esw apply vport addr list+0x56/0xf0 [mlx5 core] esw vport change handle locked+0x28b/0x310 [mlx5 core] mlx5 esw vport enable+0x270/0x4a0 [mlx5 core] ... mlx5 load ... mlx5 health try recover

esw apply vport rx mode(false, false) clears vport->allmulti rule via its local state machine even when the FW del fails. With the rule NULL the !IS ERR OR NULL(allmulti rule) gate in the change handler closes, no rules are installed during disable, and the reload starts with a clean mc list.