CVE-2023-54148 in Linux
Resumen
por VulDB • 2026-07-01
Based on the stack trace provided, here is an analysis of the issue:
### **Summary** The kernel is crashing (or triggering a warning/oops) in the `mlx5_core` driver during device removal/unregistration. Specifically, it fails while trying to unpair offloads (`mlx5_esw_offloads_unpair`) as part of cleaning up switchdev/offload structures when an mlx5 network interface or PCI function is being detached.
### **Key Functions in the Stack Trace** 1. `mlx5_rescan_drivers_locked.part.0` / `mlx5_unregister_device`: The core device is being unregistered (likely due to module unload, hot-unplug, or driver reload). 2. `auxiliary_bus_remove` → `device_del`: Standard kernel device removal path for auxiliary devices (used by mlx5 for virtual functions/replicas). 3. `mlx5e_vport_rep_unload` / `mlx5eswitch_unregister_vport_reps`: Cleaning up Ethernet vport replicas associated with the switchdev offloads. 4. `mlx5_esw_offloads_devcom_cleanup` → `mlx5_devcom_send_event`: Sending a devcom (device communication) event to notify peers about cleanup. 5. **Crash Point**: `mlx5_esw_offloads_unpair+0x86/0x540 [mlx5_core]`
### **Likely Causes** 1. **Race Condition During Unload**: The most common cause is a race between: - One CPU/core unloading the mlx5 driver/device (`mlx5_unregister_device`). - Another context (e.g., NAPI, tasklet, or another devcom event handler) still accessing or modifying offload structures. 2. **Invalid Pointer/Dangling Reference**: `mlx5_esw_offloads_unpair` likely dereferences a pointer to an offload object that has already been freed or is in an inconsistent state due to incomplete cleanup ordering. 3. **Devcom State Mismatch**: The devcom (device communication) subsystem expects certain peers to be present, but during rapid unregistration, some peers may have already disappeared, leading to a null pointer dereference or use-after-free when trying to "unpair."
### **Recommended Actions** 1. **Check Kernel Version & Patches**: - This looks like a known issue in certain versions of the Mellanox `mlx5_core` driver (especially around kernel 5.x–6.x). Check if there are upstream fixes or vendor patches for "mlx5 eswitch offloads unpair crash" or "mlx5 devcom cleanup race." - Search bug trackers (e.g., Red Hat Bugzilla, Ubuntu Launchpad) with keywords: `mlx5_esw_offloads_unpair`, `mlx5_devcom_cleanup`.
2. **Avoid Rapid Driver Reloads/Unplugs**: - If this happens during testing involving frequent driver reloads (`rmmod`/`insmod`) or hot-unplug, try to ensure all network interfaces are down and no traffic is flowing before unloading the module.
3. **Enable Debugging**: - Reboot with `mlx5_core.debug=1` (if supported) to get more verbose logs around offload operations. - Check if `CONFIG_MLX5_CORE_EN_SWITCHDEV=y` and related options are causing issues; sometimes disabling switchdev offloads (`ip link set dev <iface> type bridge mcast_snooping 0` or similar workarounds) can help isolate the problem.
4. **Update Driver/Kernel**: - If possible, update to a newer kernel version where this race condition may have been fixed by Mellanox/NVIDIA engineers.
### **Workaround (Temporary)** If you are not using SR-IOV or complex switchdev offloads: ```bash # Disable switchdev offload on the interface before unloading/reconfiguring ip link set dev <mlx5_interface> type bridge mcast_snooping 0 # Or disable hardware offloads entirely if supported by your setup ethtool -K <mlx5_interface> hw-tc-offload off ```
If this is a production environment, consider filing a bug report with the full `dmesg` output (including the preceding lines before `[2453.393925]`) to the kernel maintainers or your distribution's support team.
If you want to get best quality of vulnerability data, you may have to visit VulDB.