CVE-2025-68360 in Linux
Zusammenfassung
von VulDB • 29.06.2026
This crash occurs in the MediaTek WED (Wireless Ethernet Dispatch) offload subsystem, specifically within `mt76_wed_offload_disable`. The call trace indicates that a flow offload callback (`nf_flow_rule_route_ipv6`) triggered a removal of a flow entry (`mtk_flow_offload_cmd` -> `mtk_wed_flow_remove`).
The root cause is typically one of two issues in the MediaTek WED driver implementation: 1. **Race Condition/Use-After-Free:** The callback assumes a specific WED instance (referenced by global or static data) but the actual hardware context might have been detached, reset, or belongs to a different interface/WiFi chip that is no longer valid in the current execution path. 2. **Incorrect Reference Passing:** The `mtk_wed_flow_remove` function receives a generic pointer (often derived from netdev or flow rule), but it needs to resolve this back to the specific `struct mtk_wed *wed` instance associated with that hardware block before calling into MT76-specific offload functions.
### Solution Strategy
The fix involves ensuring that when handling WED callbacks, we correctly identify and use the **specific WED device structure** (`mtk_wed`) corresponding to the flow being removed/added, rather than relying on a potentially stale or incorrect global reference.
In many MediaTek SoCs (like MT7622, MT7981), there can be multiple WiFi interfaces sharing the same WED hardware block, or separate blocks for different chips. The `mtk_wed_flow_remove` function must correctly map the flow's netdev/interface to its owning `mtk_wed` instance.
Here is how you should approach fixing this in the kernel source (typically located in `drivers/net/ethernet/mediatek/mtk_wed.c` or similar):
#### 1. Identify the WED Instance Correctly Ensure that when a flow offload callback is invoked, it passes the correct `struct mtk_wed *wed` pointer to the internal helper functions. If you are using `tc_block_cb`, ensure the private data passed contains the right context.
In `mtk_flow_offload_cmd`: ```c // Before fix (hypothetical problematic code): // It might be calling mt76_wed_offload_disable with a generic or wrong wed pointer.
// After fix: Ensure 'wed' is correctly resolved from the flow's netdev or context. struct mtk_wed *wed = ...; // Resolve this properly, e.g., via netdev_priv or container_of ```
#### 2. Add Null/Validity Checks in `mtk_wed_flow_remove` Before calling into MT76-specific offload functions, verify that the WED structure is still valid and attached.
**File:** `drivers/net/ethernet/mediatek/mtk_wed.c` (or relevant file)
```c static void mtk_wed_flow_remove(struct net_device *dev, struct flow_offload *flow) {
// 1. Get the correct WED instance associated with this device/interface struct mtk_wed *wed = ...; /* Ensure this is resolved correctly */ if (!wed || !mtk_wed_is_active(wed)) {
pr_debug("WED not active or invalid for flow removal\n"); return; }
// 2. Check if the specific offload feature is enabled and supported by this WED instance if (test_bit(MTK_WED_OFFLOAD_ENABLED, &wed->flags)) {
struct mt76_dev *mt76 = wed_to_mt76(wed); /* Helper to get MT76 device */ // 3. Safely call the offload disable function // Ensure mt76_wed_offload_disable handles NULL or invalid state gracefully if (mt76) {
mutex_lock(&mt76->mutex); mt76_wed_offload_disable(mt76, flow); /* Pass specific context */ mutex_unlock(&mt76->mutex); } } } ```
#### 3. Fix `mt76_wed_offload_disable` to Handle Context Properly The crash happens inside `mt76_wed_offload_disable`. Ensure it doesn't dereference invalid pointers if the WED hardware is in an inconsistent state.
**File:** `drivers/net/wireless/mediatek/mt76/mcu.c` or similar MT76 driver file
```c void mt76_wed_offload_disable(struct mt76_dev *mdev, struct flow_offload *flow) {
// Ensure mdev->wed is valid before accessing it if (!mdev || !mdev->wed) {
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.