CVE-2026-98807: net/mlx5: Fix slab-out-of-bounds when handling team device events
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix slab-out-of-bounds when handling team device events
The mlx5handlechangeupperevent() and mlx5handlechangeinfodataevent() functions check for LAG masters (which includes both bonding and team devices) but only call bonding-specific APIs. When processing team device events, calling bondslavegetrcu() and bondisslaveinactive() on teamport structures causes KASAN to detect an out-of-bounds memory access since teamport is smaller than bond slave.
Fix this by wrapping the bond-specific API calls with a check for bonding devices. This allows the function to still process LAG events for both bonding and teams but only calls bond-specific functions when dealing with actual bonding devices.
For mlx5handlechangeinfodataevent(), keep the explicit bond check as mlx5 doesn't handle state information for team ports anyway.
Tested with Mellanox ConnectX-5 on Linux 7.2.0-rc6: - Bonding: PASS (no regressions) - Team device: PASS (no KASAN errors)
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel mlx5 network driver with a team device configuration are exposed when mlx5 processes relevant network device events. The reported testing involved a Mellanox ConnectX-5 adapter.
What triggers the out-of-bounds access?
The issue is triggered when mlx5 handles team device events and invokes bonding-specific APIs on team_port structures. Those structures are smaller than bond-slave structures, causing an out-of-bounds access detected by KASAN.
Are bonding configurations affected in the same way?
The vulnerable code recognizes both bonding and team devices as LAG masters, but the invalid API calls occur when team-port structures are treated as bond slaves. Testing of the fix reported no bonding regressions.
What mitigation is available before applying a fixed kernel?
Avoid using team device configurations with the mlx5 driver where possible. The issue is tied to processing team device events; the provided information does not identify another workaround.