CVE-2023-53342 in Linux
الملخص
بحسب VulDB • 01/07/2026
Based on the kernel log provided, here is an analysis of the issue:
### **Summary** This is a **kernel warning (BUG/WARN_ON)** in the `prestera` driver for Delta Networks TN48M-DN switches. The crash occurs during FIB (Forwarding Information Base) route processing when checking if a next-hop is "direct." It likely stems from an invalid or uninitialized nexthop object being passed to the function `__prestera_fi_is_direct`.
---
### **Detailed Breakdown**
#### 1. **Location of Failure** - **File/Function**: ```c include/net/nexthop.h:468 __prestera_fi_is_direct+0x2c/0x68 [prestera]
``` - This indicates the warning was triggered inside `__prestera_fi_is_direct`, which is defined in a header file (`nexthop.h`) and likely used by the Prestera driver.
#### 2. **Triggering Context** - **Workqueue**: ```c Workqueue: prestera_ordered __prestera_router_fib_event_work [prestera]
``` The issue occurs during asynchronous FIB event processing, specifically when handling route changes (add/delete/update).
#### 3. **Call Chain Insight** - **Linker Register (`lr`)** points to: ```c __prestera_k_arb_fc_apply+0x280/0x2f8 [prestera]
``` This suggests the call originated from `__prestera_k_arb_fc_apply`, which likely handles flow control or arbitration for forwarding entries.
#### 4. **Key Registers (ARM64)** - The registers show memory addresses being passed around, but without a full backtrace (`dump_stack`), it’s hard to pinpoint the exact invalid pointer. However: - `x19`, `x20`, etc., contain kernel pointers (`ffff...`). - One of these is likely an uninitialized or freed nexthop object that caused the WARN_ON in `__prestera_fi_is_direct`.
#### 5. **Taint Flag** - ```c Tainted: G W O 6.4.5 #1 ``` - **G**: Proprietary module loaded (`prestera_pci`). - **W**: Kernel was built with warnings (not critical). - **O**: Out-of-tree module loaded.
---
### **Likely Root Cause** The function `__prestera_fi_is_direct` expects a valid nexthop object but receives an invalid one (e.g., NULL, freed memory, or corrupted structure). This could happen if: 1. A route is deleted while still being processed in the workqueue. 2. Race condition between FIB update and hardware offload removal. 3. Bug in `prestera` driver’s handling of nexthop objects during dynamic routing changes (e.g., BGP/OSPF convergence).
---
### **Recommended Actions**
#### 1. **Check for Known Issues** - Search the Linux kernel mailing list or Delta Networks’ support portal for bugs related to: - `prestera_fi_is_direct` - `__prestera_k_arb_fc_apply` - Kernel version `6.4.5` with TN48M-DN switches.
#### 2. **Enable Debugging** - Add more logging in the driver to trace nexthop object lifecycle: ```c pr_debug("nexthop obj=%p\n", nh); // Before calling __prestera_fi_is_direct ``` - Use `CONFIG_DEBUG_INFO` and `ftrace` to capture full call stacks.
#### 3. **Workaround** - If this occurs during route flapping, consider: - Reducing routing churn (e.g., slower BGP timers). - Disabling hardware offload temporarily (`ip link set dev eth0 txoff on`).
#### 4. **Update Driver/Kernel** - Check if newer versions of the `prestera` driver or kernel fix this race condition. Delta Networks may have out-of-band patches for TN48M-DN.
---
### **Example Patch Direction (If You’re a Developer)** In `__prestera_fi_is_direct`, add a NULL/invalid check: ```c static bool __prestera_fi_is_direct(struct nexthop *nh) {
if (!nh || !nh->dev) // Add safety check return false; // Or handle gracefully
// Existing logic... } ```
---
### **Conclusion** This is a driver-level bug in the
If you want to get best quality of vulnerability data, you may have to visit VulDB.