Cloudanix VulnDB

CVE-2026-98796

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in certain network hardware drivers can cause devices to crash or fail to start networking if an interface is activated too early during boot.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition during MTK Ethernet driver probe allows a netdev to be brought up before the shared dummy netdev and NAPI structures exist, resulting in NULL pointer dereference in __xdp_rxq_info_reg or napi_enable on NETSYS v1/v2 SoCs.

Why it matters to the business

Device initialization can fail or crash on affected MediaTek-based routers and embedded systems, causing network downtime during boot or interface configuration; low prevalence but impacts hardware that depends on this driver.

How an attack unfolds

An attacker with local access or control over interface bring-up timing (such as via netifd or scripted network configuration) triggers the window between register_netdev and dummy_dev allocation, causing the kernel to dereference uninitialized structures and panic or return errors.

How to fix it

Update to a Linux kernel containing the fix that moves dummy netdev allocation and shared NAPI registration before the register_netdev loop; rebuild and deploy the corrected driver for affected MediaTek SoCs.

How to confirm the fix worked

Confirm the dummy_dev allocation occurs prior to any register_netdev call in mtk_probe by reviewing source or testing interface bring-up immediately after module load without panics or -ENODEV errors.

Typical attack path

  1. Gain ability to influence or observe early boot/interface registration on target system
  2. Trigger netdev open (ifconfig up, netifd, or equivalent) during the narrow probe window before dummy netdev exists
  3. Observe kernel warning or -ENODEV failure in mtk_open path
  4. Optionally combine with frame-engine reset worker to widen impact on error unwind

How to detect it

Review kernel logs for warnings referencing net/core/xdp.c or NULL napi dev during mtk_open; inspect probe error paths that cancel pending_work or unwind through mtk_unreg_dev.

What your security team should do

  • Prioritize kernel updates on all MediaTek Ethernet devices within standard patch windows given low EPSS and no known exploitation
  • Monitor boot logs for 'Missing net_device from driver' warnings or mtk_open failures on affected hardware
  • Test driver probe paths in lab environments that simulate rapid interface activation

The record

In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: allocate dummy netdev sooner The RX rings and the shared NAPI are carried by an internal "dummy" netdev (eth->dummy_dev). mtk_probe() creates that dummy device, and adds the shared tx/rx NAPI to it, only after the MAC netdevs have been registered. That order has been there since the MT7623 support was added and leaves a window in which the netdevs are visible to the network core before the shared NAPI and the dummy device exist. If anything brings the first netdev up during that window (e.g. netifd opening the WAN link the instant the interface is registered), the first-open path runs without them. On NETSYS v2 and later SoCs mtk_rx_alloc() -> __xdp_rxq_info_reg() then dereferences eth->dummy_dev == NULL: WARNING: CPU: ... Missing net_device from driver in net/core/xdp.c and mtk_open() fails with -ENODEV. On NETSYS v1 SoCs (MT7621/MT7622/MT7623/MT7629) there is no page pool, so the same open instead calls napi_enable() on a napi_struct that netif_napi_add() has not initialised yet and dereferences a NULL napi->dev. Allocate the dummy netdev and add the shared tx/rx NAPI to it before the register_netdev() loop. Both the dummy-allocation failure and a register_netdev() failure now unwind through mtk_unreg_dev(), which unregisters the net_device notifiers and the netdevs registered so far, stopping a concurrently-opened netdev (ndo_stop) and its NAPI before the dummy carrier is freed. A netdev that opened during the window can also have queued the frame-engine reset worker (via the tx watchdog or phylink), so the probe error path now cancels eth->pending_work before freeing the shared state, as mtk_cleanup() already does on remove.

Affected packages

Ecosystem Package Introduced Fixed