CVE-2026-98807 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix slab-out-of-bounds when handling team device events
The mlx5_handle_changeupper_event() and mlx5_handle_changeinfodata_event() functions check for LAG masters (which includes both bonding and team devices) but only call bonding-specific APIs. When processing team device events, calling bond_slave_get_rcu() and bond_is_slave_inactive() on team_port structures causes KASAN to detect an out-of-bounds memory access since team_port 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 mlx5_handle_changeinfodata_event(), 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)
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The identified vulnerability resides within the mlx5 network driver in the Linux kernel, specifically affecting how Layer Aggregation Group events are processed for team devices versus bonding devices. The core technical flaw lies in the functions mlx5_handle_changeupper_event and mlx5_handle_changeinfodata_event, which were designed to handle changes in upper layer devices that form part of a LAG configuration. These functions incorrectly assumed that all such device structures shared the same memory layout as bond slave structures. Consequently, when processing events related to team ports, the driver invoked bonding-specific APIs, namely bond_slave_get_rcu and bond_is_slave_inactive. Because the team_port structure is significantly smaller than the bond slave structure, these calls resulted in a slab-out-of-bounds memory access. This type of out-of-bounds read allows the kernel to interpret memory contents beyond the allocated object boundaries, which can lead to unpredictable behavior, data corruption, or potential information disclosure depending on what resides in the adjacent memory regions.
From a security perspective, this vulnerability is classified under CWE-125, Out-of-bounds Read, as it involves accessing memory locations that are outside of the intended buffer boundary. The operational impact includes kernel instability and potential crashes triggered by KASAN detecting these illegal accesses during runtime testing with Mellanox ConnectX-5 hardware on Linux 7.2.0-rc6. While immediate exploitation for arbitrary code execution is not explicitly detailed, out-of-bounds reads can sometimes be leveraged to leak sensitive kernel memory contents or cause denial of service through system panics. The vulnerability highlights a lack of strict type checking and interface abstraction in the driver event handling logic, where generic LAG handling was conflated with specific bonding implementation details without adequate validation of the underlying device structure types.
The remediation strategy involves refactoring the affected functions to explicitly distinguish between bonding devices and team devices before invoking any bond-specific APIs. By wrapping calls to bond_slave_get_rcu and bond_is_slave_inactive within a conditional check that verifies if the upper layer device is indeed a bonding interface, the driver ensures that these unsafe operations are only performed on structures of sufficient size and expected layout. For mlx5_handle_changeinfodata_event, an explicit bond check was retained because the mlx5 driver does not manage state information for team ports anyway, making further processing unnecessary or potentially harmful if misapplied to team devices. This patch restores correct behavior by ensuring that bonding-specific logic is isolated from general LAG event handling unless the specific context of a bonding device is confirmed.
To mitigate this issue in production environments, it is critical to apply the kernel update containing this fix immediately for systems utilizing Mellanox ConnectX adapters with either team or bonding network configurations. Administrators should verify that their Linux kernels are updated to versions where this patch has been integrated. Additionally, organizations employing static analysis tools and runtime memory safety checkers like KASAN in development pipelines can better detect such structural mismatches early in the software lifecycle. Adhering to strict coding standards that enforce type-safe handling of kernel structures and validating device types before casting or accessing structure members is essential for preventing similar vulnerabilities in network drivers and other low-level system components.