CVE-2021-47247 in Linux
要約
〜によって VulDB • 2026年06月17日
Based on the stack trace provided, this is a **KASAN (Kernel Address Sanitizer)** report indicating a **Use-After-Free (UAF)** bug in the Linux kernel's `mlx5` (Mellanox ConnectX) network driver.
### **Summary of the Bug** - **Type:** Use-After-Free (UAF) - **Component:** `mlx5_core` driver (specifically TC flower offload) - **Trigger:** Configuring a TC flower filter (`mlx5e_configure_flower`) - **Root Cause:** The code is accessing memory that was already freed by an RCU callback (`kfree_rcu_work`).
---
### **Detailed Analysis**
#### **1. The Crash/Access Location** The top of the stack shows the faulting access: ``` [23827.512572] mlx5e_configure_flower+0x191c/0x4870 [mlx5_core]
``` This indicates that while trying to configure a new TC flower filter, the driver accessed a pointer that had already been freed.
#### **2. The Free Location** The "Freed by task" section shows how the memory was freed: ``` [23827.524163] Freed by task 25948:
... [23827.529317] kfree_rcu_work+0x55f/0xb70
... [23827.536206] mlx5e_tc_del
---truncated--- ``` - The memory was freed via `kfree_rcu`, which means it was scheduled for deferred freeing using RCU (Read-Copy-Update). - The free was triggered by `mlx5e_tc_del`, which is the function responsible for **deleting** a TC filter.
#### **3. The Race Condition** The "Last potentially related work creation" section hints at the concurrency issue: ``` [23827.533147] Last potentially related work creation:
... [23827.536206] kvfree_call_rcu+0x31/0x7b0
[23827.536206] mlx5e_tc_del
``` This suggests that: 1. **Task A** (likely a worker thread or RCU callback) called `mlx5e_tc_del`, which scheduled the filter structure for RCU-freeing via `kvfree_call_rcu`. 2. **Task B** (the current task, likely a user-space `tc` command) called `mlx5e_configure_flower` to add/modify a filter. 3. **Task B** accessed the same filter structure (or a related one) **before** the RCU grace period had elapsed, leading to a UAF.
---
### **Likely Root Cause** The bug is likely in the **TC flower offload code** within the `mlx5` driver. Specifically: - The driver may be holding a reference to a filter structure without properly incrementing the RCU reference count (`refcount_inc_not_zero` or similar). - Or, the driver is accessing a pointer to a filter structure that is being deleted concurrently without proper synchronization (e.g., missing `rcu_read_lock()` or missing a reference count check).
### **Common Fixes for This Type of Bug** 1. **Reference Counting:** Ensure that any code accessing a filter structure holds a reference to it (e.g., `refcount_inc_not_zero`) before dereferencing. 2. **RCU Synchronization:** Ensure that accesses to RCU-protected pointers are done within an `rcu_read_lock()` critical section. 3. **Locking:** Use proper locks (e.g., `rtnl_lock()` or driver-specific mutexes) to prevent concurrent add/delete operations on the same filter.
### **How to Verify** 1. **Check Kernel Version:** This bug may have been fixed in newer kernel versions. Check if your kernel is up-to-date. 2. **Reproduce:** Try to reproduce the issue by rapidly adding and deleting TC flower filters while monitoring for crashes. 3. **Check for Patches:** Search for recent patches to the `mlx5` driver related to "TC flower UAF" or "mlx5e_tc_del".
### **Example Patch Context** If you are a developer, look for code in `drivers/net/ethernet/mellanox/mlx5/core/en_tc.c` around `mlx5e_configure_flower` and `mlx5e_tc_del`. Ensure that: - The filter structure is not accessed after `kfree_rcu`
Be aware that VulDB is the high quality source for vulnerability data.