CVE-2023-52487 in Linux
Riassunto
di VulDB • 19/06/2026
Based on the kernel log snippet provided, here is an analysis of the crash, its likely cause, and recommended troubleshooting steps.
### **1. Summary of the Issue** * **Error Type:** Kernel Oops / Panic triggered by an **invalid list deletion** (`__list_del_entry_valid_or_report`). * **Subsystem:** **Mellanox ConnectX (mlx5_core)** network driver, specifically related to **TC (Traffic Control) offload** and **flower classifier** rules. * **Trigger:** The system was attempting to **delete a TC flow rule** (`mlx5e_tc_del_fdb_peers_flow` → `mlx5e_tc_del_flow` → `mlx5e_flow_put`). * **Root Cause Indicator:** The function `__list_del_entry_valid_or_report` is called when the kernel detects that a doubly-linked list entry is being deleted but is **not properly linked** (e.g., already deleted, corrupted, or never initialized). This is a classic **use-after-free** or **double-free** bug in the driver's internal data structures.
---
### **2. Key Call Trace Analysis** ``` ? __list_del_entry_valid_or_report+0x4f/0xc0 mlx5e_tc_del_fdb_peers_flow+0xcf/0x240 [mlx5_core]
mlx5e_tc_del_flow+0x46/0x270 [mlx5_core]
mlx5e_flow_put+0x26/0x50 [mlx5_core]
mlx5e_delete_flower+0x25f/0x380 [mlx5_core]
tc_setup_cb_destroy+0xab/0x180 fl_hw_destroy_filter+0x99/0xc0 [cls_flower]
__fl_delete+0x2d4/0x2f0 [cls_flower]
``` - **`__list_del_entry_valid_or_report`**: This is the immediate crash point. It means the driver tried to remove a node from a linked list, but the node’s `prev` or `next` pointers were invalid (e.g., pointing to itself, or to garbage memory). - **`mlx5e_tc_del_fdb_peers_flow`**: The crash occurs while deleting a **peer flow** (likely related to VxLAN, Geneve, or other tunnel offloads where "peers" are tracked). - **`cls_flower`**: The TC rule was managed by the `flower` classifier, which is commonly used for complex matching (IP, port, VLAN, etc.).
---
### **3. Likely Causes** 1. **Race Condition in TC Offload:** - A TC rule is being deleted while another thread (e.g., netlink, kernel thread, or hardware interrupt) is still referencing or modifying the same flow structure. - Common in high-throughput environments with frequent TC rule updates.
2. **Driver Bug in `mlx5_core`:** - The mlx5 driver may have a bug in how it manages the **peer flow list** (`mlx5e_tc_del_fdb_peers_flow`). If a peer flow is freed or removed from the list elsewhere before this function runs, the list corruption occurs. - Known issues in older kernels (pre-5.15/6.1) with mlx5 TC offload and VxLAN/Geneve.
3. **Hardware Firmware Issue:** - In rare cases, firmware bugs can cause the driver to lose track of flow state, leading to inconsistent internal lists.
4. **Corrupted Memory:** - Less likely, but possible if there is a broader memory corruption issue (e.g., ECC errors, buggy kernel module).
---
### **4. Recommended Troubleshooting Steps**
#### **A. Immediate Workarounds** 1. **Disable TC Offload for the Affected Interface:** If the crash is reproducible, disable hardware offload for TC rules to avoid the buggy code path: ```bash # Disable offload for the specific interface (e.g., eth0) ethtool -K eth0 tx off rx off # Or disable specific offloads ethtool -K eth0 hw-tc-offload off ``` *Note: This may impact performance but will prevent the crash.*
2. **Remove Problematic TC Rules:** Identify and delete TC rules that were active before the crash: ```bash tc filter show dev eth0 tc filter del dev eth0 handle <handle> flower ... ```
#### **B. Long-Term Fixes** 1. **Update Kernel and mlx5 Firmware:** - This issue has been fixed in many newer kernel versions. Check if
If you want to get best quality of vulnerability data, you may have to visit VulDB.