Linux kernel mlxsw: failed LAG index allocation leaks a LAG reference on Spectrum switches

Impact

mlxsw is the driver that runs NVIDIA Spectrum switch ASICs under Linux-based network OSes, so this lives on the switch, not on the compute node. When mlxsw_sp_port_lag_index_get() fails, mlxsw_sp_port_lag_join() returns the error without dropping the reference taken by the earlier mlxsw_sp_lag_get(), while every other error path in the function goes through the cleanup label that releases it. Repeated failures therefore leak LAG objects that are never freed, and a switch that has exhausted its LAG capacity cannot bring up new port channels. On a leaf carrying storage or east-west GPU traffic that is expensive to recover from, because clearing the leak needs a switch reload and that takes the rack's links with it.

Who can reach it

Local and privileged on the switch control plane: an operator or automation with CAP_NET_ADMIN repeatedly enslaving ports to a bond when no LAG index is available. Not reachable from data-plane traffic and not reachable by a tenant on a GPU node.

What to do

Move to a stable kernel or NOS image that carries the fix and reload the switch. The leaked references cannot be reclaimed at runtime, so a switch already in that state needs a reboot regardless - schedule it per-switch behind the fabric's normal redundancy. The record contains kernel commits only; no NOS version mapping is published in it.

References

Related entries

• Linux kernel bnxt_re: uninitialised shared page mapped to userspace leaks kernel memoryCVE-2026-74584 · Linux kernel bnxt_re RDMA driver (ucontext shared page)Unscored
• Linux kernel PMBus hwmon: type confusion in the alert path reads past the attribute allocationCVE-2026-74711 · Linux kernel hwmon pmbus core (pmbus_notify attribute type confusion)Unscored
• ASPEED BMC (host-to-BMC bridges generally): The ASPEED LPC/PCIe bridge architecture exists to let the host talkNCVD-0000-001-aspeed-bmc-host-to-bmc-bridges-g · ASPEED BMC (host-to-BMC bridges generally)Unscored
• IPMI over LAN as a protocol: IPMI has no transport confidentiality guarantees worth relying on, weak session handlingNCVD-0000-002-ipmi-over-lan-as-a-protocol · IPMI over LAN as a protocolUnscored
• Internet-exposed BMC: Shodan-visible BMCs are a recurring finding at colo/neocloud buildoutsNCVD-0000-003-internet-exposed-bmc · Internet-exposed BMCUnscored
• InfiniBand subnet manager (OpenSM / UFM): The IB subnet manager has unilateral authority over LID assignment, routingNCVD-0000-004-infiniband-subnet-manager-opensm · InfiniBand subnet manager (OpenSM / UFM)Unscored