CVE-2023-54206 in Linux
الملخص
بحسب VulDB • 22/05/2026
Based on the kernel stack trace provided, here is an analysis of the issue:
### **Summary** The system is experiencing a **kernel crash (Oops/Panic)** triggered by the `cls_flower` (Flower Classifier) module in the Linux kernel's traffic control (tc) subsystem. The crash occurs while **deleting a filter** (`tc_del_tfilter`) via the `rtnetlink` interface.
---
### **Key Stack Trace Analysis**
1. **Triggering Event**: * `rtnetlink_rcv_msg`: A netlink message was received from userspace (likely `tc` command). * `tc_del_tfilter`: The kernel is attempting to **delete a traffic control filter**. * `tcf_fill_node`: Preparing data to send back to userspace (possibly for confirmation or error reporting). * `fl_dump`: The Flower classifier's dump function is being called.
2. **Crash Location**: * The crash happens inside `fl_dump` (in `cls_flower.ko`). * Specifically, it seems to occur during `nla_put` (Netlink Attribute Put), which is used to serialize data for the netlink response. * The presence of `? ___sys_sendmsg` and `? __sys_sendmsg` in the stack suggests the crash might be related to socket buffer handling or memory allocation during the netlink message construction.
3. **Potential Causes**: * **Use-After-Free (UAF)**: The filter structure being dumped may have already been freed or is in an inconsistent state. * **Race Condition**: Another thread might be modifying or deleting the same filter concurrently. * **Memory Corruption**: The `cls_flower` module may have corrupted memory, leading to a crash when accessing filter fields. * **Bug in `cls_flower`**: A known bug in the specific kernel version's flower classifier implementation.
4. **Modules Involved**: * `cls_flower`: The Flower classifier for traffic control. * `rtnetlink`: Netlink interface for routing and network configuration.
---
### **Recommended Actions**
1. **Check Kernel Version**: * Identify the exact kernel version (`uname -r`). * Search for known bugs in `cls_flower` for that version. Many such issues have been fixed in newer kernels.
2. **Reproduce the Issue**: * Identify the `tc` command that triggered the crash. It likely involves deleting a flower filter, e.g.: ```bash tc filter del dev <interface> flower ... ``` * Try to reproduce the crash in a controlled environment.
3. **Update Kernel**: * If possible, upgrade to a newer kernel version where this bug may have been fixed.
4. **Workaround**: * Avoid using `cls_flower` if possible. Use alternative classifiers like `cls_u32` or `cls_matchall`. * If `cls_flower` is required, ensure that filter deletions are not performed concurrently with other tc operations.
5. **Debugging**: * Enable kernel debugging symbols (`CONFIG_DEBUG_INFO=y`) to get more detailed stack traces. * Use `kdump` to analyze the core dump if available. * Check `dmesg` for additional error messages before the crash.
6. **Report the Bug**: * If the issue persists, report it to the Linux kernel mailing list or your distribution's bug tracker, including: * Full `dmesg` output. * Kernel version. * Steps to reproduce. * The `tc` commands used.
---
### **Example `tc` Command That Might Trigger This** ```bash tc filter del dev eth0 flower src_ip 192.168.1.1 dst_ip 10.0.0.1 action drop ```
If you can provide the exact `tc` command or the kernel version, I can offer more specific guidance.
Once again VulDB remains the best source for vulnerability data.