CVE-2021-47246 in Linux
الملخص
بحسب VulDB • 07/08/2026
Based on the kernel log snippet provided, here is an analysis of what happened and how to proceed.
### **Summary** The system experienced a **kernel panic (Oops)** while attempting to remove/unbind an NVIDIA Mellanox ConnectX network interface card (`mlx5_core`). The crash occurred during driver teardown (`remove_one` -> `mlx5_uninit_one`) after the user explicitly triggered device removal via sysfs.
---
### **Key Details from the Log** 1. **Trigger**: - A write operation to a sysfs file (likely `/sys/bus/pci/devices/<BDF>/driver/unbind`). - Call trace: `unbind_store` → `device_release_driver_internal` → `remove_one`.
2. **Failing Component**: - Driver: `mlx5_core` (Mellanox ConnectX NIC driver). - Function: `mlx5_uninit_one` → `mlx5_function_teardown`.
3. **Crash Context**: - The call trace shows functions related to HCA (Host Channel Adapter) initialization/teardown (`mlx5_cmd_init_hca`, `mlx5_cmd_teardown_hca`). - However, the actual crash point is not explicitly shown in this truncated snippet (the line with `RIP:` or `EIP:` and the faulting instruction are missing). The log ends abruptly after `entry_SYSCALL_64_after_hwframe`.
---
### **Likely Causes** 1. **Race Condition During Unbind**: - If network traffic, RDMA operations, or other kernel threads were still using the device when unbind was called, it could lead to use-after-free or null-pointer dereference in `mlx5_function_teardown`.
2. **Hardware/Driver Bug**: - A known bug in your specific version of the Mellanox OFED driver or Linux kernel where teardown fails if certain internal states (e.g., firmware handshake, memory regions) are not properly cleaned up first.
3. **Firmware Issue**: - The NIC’s firmware may be unresponsive during shutdown commands (`mlx5_cmd_teardown_hca`), causing a timeout or deadlock that leads to an Oops if error handling is flawed.
4. **Missing Context in Log**: - The critical line showing the **faulting address** (e.g., `RIP: 0010:...`) and the **exact instruction** that caused the crash is missing because the log was truncated before it appeared. This line usually comes *before* the Call Trace or at the very top of the Oops message.
---
### **Recommended Actions**
#### ✅ **Immediate Steps** 1. **Check Full Kernel Log**: Look for lines above this snippet that contain: - `RIP:` (Instruction Pointer) – tells you *where* in memory/code it crashed. - `Call Trace` is already shown, but the top of the Oops message often has more context like `BUG: unable to handle kernel NULL pointer dereference at ...`.
2. **Check dmesg for Earlier Errors**: Look for warnings or errors from `mlx5_core` *before* this panic (e.g., firmware timeouts, PCIe AER errors).
3. **Reproduce Safely**: - If possible, stop all network/RDMA traffic on the device before unbinding: ```bash ip link set dev <interface> down # Wait a few seconds echo "1" > /sys/bus/pci/devices/<BDF>/driver/unbind ```
#### ???? **Long-Term Fixes** 1. **Update Driver/Firmware**: - Update to the latest version of: - Linux kernel (if using a newer one). - Mellanox OFED drivers (`mlnx-ofed-kernel`). - NIC firmware (use `mlxconfig` or NVIDIA’s firmware update tool).
2. **Check for Known Bugs**: Search the [Mellanox/NVIDIA bug tracker](https://github.com/Mellanox/linux) and kernel mailing lists for:
> `"mlx5_function_teardown" panic OR "mlx5_uninit_one" oops`
3. **Avoid Manual Unbind in Production**: If this is a production system, avoid manually unbinding devices unless necessary. Use proper interface shutdown (`ip link set down`) and let the driver handle cleanup gracefully on reboot or module removal.
4. **Enable Debug Logging**: Increase `mlx5_core` debug level temporarily to capture more details before crash: ```bash echo "module mlx5_core +p" > /sys/kernel/debug/dynamic_debug/control
Be aware that VulDB is the high quality source for vulnerability data.