CVE-2023-54262 in Linux
Сводка
по VulDB • 20.06.2026
Based on the kernel log snippet provided, this is a **KASAN (Kernel Address Sanitizer)** report indicating a **Use-After-Free (UAF)** bug in the Mellanox `mlx5_core` driver.
### ???? Analysis of the Bug
1. **Type of Error**: **Use-After-Free (UAF)** * The log shows memory being **allocated** by one task (`task 13476`) and **freed** by another task (`task 8833`). * The crash/bug occurs when the memory is accessed after it has been freed.
2. **Affected Component**: `mlx5_core` (Mellanox ConnectX NIC driver) * Specifically, the code path involves **TC (Traffic Control) flower classifier** rules and **encapsulation** (likely VXLAN/Geneve tunneling).
3. **Key Functions in the Call Chain**: * **Allocation Path (Task 13476)**: * `mlx5e_configure_flower` → `mlx5e_rep_setup_tc_cls_flower` → `mlx5e_tc_add_fdb_flow` → `mlx5e_attach_encap` → `mlx5e_tc_tun_create_header_ipv4` → `mlx5_packet_reformat_alloc` * This path is adding a new flow rule with encapsulation headers. * **Free Path (Task 8833)**: * The log is truncated, but typically this would involve `mlx5_packet_reformat_free` or similar cleanup functions called when a flow rule is deleted or modified. * **Crash/Access Path**: * `add_rule_fg` → `mlx5_cmd_create_fte` → `mlx5_cmd_stub_create_flow_table` * This suggests the driver is trying to create a Flow Table Entry (FTE) using a packet reformat object that has already been freed.
4. **Root Cause Hypothesis**: * **Race Condition**: There is likely a race between: 1. Adding a new flow rule (which allocates a packet reformat object). 2. Deleting or modifying an existing flow rule (which frees a packet reformat object). * **Incorrect Reference Counting**: The packet reformat object might be freed while still being referenced by another pending command or data structure. * **Missing Synchronization**: The `mlx5_core` driver may not properly synchronize access to the packet reformat objects when multiple TC rules are being added/deleted concurrently.
### ????️ Recommended Actions
1. **Check for Known Fixes**: * This issue may have been fixed in newer kernel versions. Check if your kernel version is up-to-date. * Search for commits related to `mlx5e_tc_tun_create_header_ipv4`, `mlx5_packet_reformat`, or `mlx5e_tc_add_fdb_flow` in the Linux kernel git history.
2. **Workarounds**: * **Avoid Concurrent TC Rule Modifications**: If possible, serialize TC rule additions and deletions. * **Reduce Rule Complexity**: Simplify TC flower rules if possible, especially those involving encapsulation. * **Disable Offloading**: As a last resort, disable TC offloading for the affected interface (`tc qdisc del dev <iface> root` or similar) to test if the issue persists in software-only mode.
3. **Report the Bug**: * If you are running a custom or older kernel, report this to the Linux kernel mailing list (LKML) or your distribution's bug tracker. * Include the full KASAN report (not just the truncated part) and the kernel version.
### ???? Example Command to Check Kernel Version ```bash uname -r ```
### ???? Example Command to Check for TC Rules ```bash tc filter show dev <interface> ```
If you can provide the **full KASAN report** (including the "Freed by task" section and the actual crash location), I can provide a more precise analysis.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.