CVE-2023-54262 in Linux
Sumário
de VulDB • 01/06/2026
Based on the kernel log snippet provided, this is a **KASAN (Kernel Address Sanitizer)** report indicating a **Use-After-Free (UAF)** or **Double-Free** bug within the Mellanox `mlx5_core` driver.
### ???? Analysis of the Bug
1. **Type of Error**: * The log shows two distinct allocation/free stacks for the same memory object. * **"Allocated by task 13476"**: Memory was allocated via `mlx5_packet_reformat_alloc` → `mlx5e_tc_tun_create_header_ipv4` → `mlx5e_attach_encap`. This is part of setting up an encapsulation rule (likely VXLAN/Geneve) for a flow. * **"Freed by task 8833"**: The same memory was freed by another task. Although the free stack is truncated, the presence of both allocation and free traces in a KASAN report typically means the memory was freed while still in use, or freed twice.
2. **Key Functions Involved**: * `mlx5_packet_reformat_alloc`: Allocates resources for packet reformatting (encapsulation). * `mlx5e_tc_tun_create_header_ipv4`: Creates an IPv4 tunnel header rule. * `mlx5e_attach_encap`: Attaches the encapsulation context to the flow. * `mlx5e_tc_add_fdb_flow` / `mlx5e_configure_flower`: The standard path for adding tc flower filters.
3. **Root Cause Hypothesis**: * **Race Condition**: Task 8833 likely freed the reformat object (e.g., during rule deletion or cleanup) while Task 13476 was still trying to use it (e.g., during rule addition or modification). * **Missing Reference Counting**: The `mlx5_packet_reformat` object might not have been properly reference-counted or protected by a lock when being accessed across different tasks. * **Error Path Bug**: If `mlx5e_attach_encap` fails partially, the cleanup code might free the reformat object, but another thread might still hold a pointer to it.
### ????️ Recommended Actions
#### 1. **Immediate Mitigation** - **Restart the service/network**: If this is causing a crash or instability, restarting the network manager or the container orchestration system (e.g., Kubernetes CNI) may temporarily clear the state. - **Check for Recent Changes**: Did you recently update the kernel, `mlx5_core` module, or the CNI plugin (e.g., Calico, Cilium)?
#### 2. **Debugging Steps** - **Enable Full KASAN Logs**: Ensure `kasan=on` and `slab_error=on` are in the kernel boot parameters to get full stack traces for both alloc and free. - **Check for Concurrent Rule Modifications**: Look for logs around the same time (`Feb 21 09:02:00`) showing `tc filter` deletions or modifications. The bug likely occurs when a rule is being added while another is being deleted. - **Inspect `mlx5_packet_reformat` Lifecycle**: - In the kernel source, check `drivers/net/ethernet/mellanox/mlx5/core/en_tc.c`. - Look at how `mlx5_packet_reformat` objects are reference-counted. - Verify if `mlx5e_detach_encap` is called before the object is freed.
#### 3. **Kernel/Driver Update** - This is a known class of bugs in older `mlx5_core` drivers. Check if your kernel version is affected by known CVEs or bug fixes related to: - `mlx5e_tc_tun_create_header` - `mlx5_packet_reformat` - **Update to a newer kernel** or apply the latest `mlx5_core` patches from your distribution.
#### 4. **Workaround (If applicable)** - Avoid rapid addition/deletion of complex tunneling rules (VXLAN/Geneve) with `tc flower` filters. - If using Kubernetes, consider reducing the frequency of network policy updates.
### ???? Summary This is a **kernel-level memory corruption bug** in the Mellanox NIC driver. It is not a user-space application error. The fix requires a **kernel or driver update**. If you are on a production system, consider upgrading the kernel to a version that includes fixes for `mlx5` tunneling race conditions.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.