CVE-2023-53342 in Linux
Résumé
par VulDB • 01/06/2026
Based on the kernel log provided, here is an analysis of the issue, its root cause, and potential solutions.
### 1. Summary of the Issue * **Error Type:** Kernel Warning (`WARNING: CPU: 3 PID: 53`) triggered by a `WARN_ON` or similar check in the `prestera` driver. * **Location:** `include/net/nexthop.h:468` in function `__prestera_fi_is_direct`. * **Context:** The warning occurred during a FIB (Forwarding Information Base) event processing workqueue (`__prestera_router_fib_event_work`). * **Driver:** `prestera` (Prestera ASIC driver, commonly used in Delta Networks TN48M-DN switches). * **Kernel Version:** 6.4.5. * **Taint:** `W` (Warning), `O` (Out-of-tree module).
### 2. Root Cause Analysis The crash/warning originates from `__prestera_fi_is_direct`, which is called from `__prestera_k_arb_fc_apply`. This function is part of the Prestera driver's handling of **nexthop objects** and **FIB entries**.
#### Key Clues: 1. **`__prestera_fi_is_direct`**: This function checks if a FIB entry (FIB Info) is a "direct" route (i.e., points directly to a neighbor/next-hop without recursion). The warning at `nexthop.h:468` likely asserts that a certain condition about the nexthop structure is true (e.g., that the nexthop group is valid, or that the nexthop is not null, or that it is indeed a direct route). 2. **`__prestera_k_arb_fc_apply`**: This function applies forwarding control (FC) rules, likely related to ACLs, policing, or traffic classification, to the FIB entry. 3. **`kworker/u8:3`**: The workqueue indicates this is an asynchronous event triggered by a FIB change (e.g., route addition, deletion, or modification).
#### Likely Scenario: The driver is trying to apply forwarding control rules to a FIB entry, but the FIB entry's nexthop structure is in an **invalid or inconsistent state**. Specifically: * The nexthop might be **null** or **partially initialized**. * The nexthop might be a **group** (multipath) but the driver expects a **direct** route. * There might be a **race condition** where the FIB entry is being modified/deleted while the workqueue is processing it.
The `WARN_ON` at `nexthop.h:468` is likely checking something like: ```c WARN_ON(!nh || nh->type != NEXTHOP_TYPE_DIRECT) ``` or similar, indicating that the driver assumed a direct nexthop but found something else (or nothing).
### 3. Potential Causes 1. **Bug in Prestera Driver:** The driver may not handle all types of nexthops correctly (e.g., multipath, blackhole, or unresolved nexthops). 2. **Race Condition:** A route is being deleted or modified while the driver is still processing a previous FIB event. 3. **Hardware State Mismatch:** The ASIC state is out of sync with the kernel's FIB table. 4. **Kernel Bug:** Less likely, but possible if the `nexthop` core API changed in a way the driver doesn't handle.
### 4. Recommended Actions
#### A. Immediate Mitigation 1. **Check for Recent Changes:** Did this start after a kernel update, driver update, or configuration change (e.g., adding/deleting routes, BGP sessions)? 2. **Monitor Logs:** Look for preceding errors or warnings that might indicate route flapping or hardware errors. 3. **Restart Network Services:** If possible, restart networking or the switch management interface to reset the FIB state.
#### B. Long-Term Fixes 1. **Update Driver/Kernel:** * Check if there is a newer version of the `prestera` driver or kernel that fixes this issue. This looks like a known class of bugs in switch drivers where nexthop handling is complex. * Delta Networks may have a specific patch for the TN48M-DN.
2. **Report the Bug:** * If you are using a mainline kernel, report this to the Linux kernel mailing list (netdev) or the maintainer of the `prestera` driver. * Include the full `dmesg` output, `ip route show`,
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.