CVE-2026-98620

What it actually does

Improper error handling in mtk_probe() routes register_netdev() failure to err_deinit_ppe instead of err_unreg_netdev, freeing net devices while still in NETREG_REGISTERED state and triggering BUG_ON(dev->reg_state != NETREG_UNREGISTERED).

Why it matters to the business

Kernel crashes or instability may occur on systems with MediaTek Ethernet hardware during driver initialization errors, potentially disrupting network connectivity and requiring reboots.

How an attack unfolds

An attacker would need to induce a partial failure in netdev registration for MTK_MAX_DEVS devices during probe, which is not remotely controllable in normal operation and leads to a denial-of-service crash rather than code execution.

How to fix it

Apply the upstream kernel fix that routes register_netdev() failures to the err_unreg_netdev label before freeing devices; rebuild and deploy updated kernel images on affected systems.

How to confirm the fix worked

Inspect mtk_probe() error paths in the mtk_eth_soc driver source to confirm register_netdev failures are directed to unregister handling; test probe failure scenarios and verify no BUG_ON occurs.

Typical attack path

1. Cause register_netdev failure for one device while others succeed in mtk_probe()
2. Error path skips mtk_unreg_dev()
3. mtk_free_dev() releases devices in invalid registered state
4. Kernel hits BUG_ON assertion and panics

How to detect it

Search kernel logs and dmesg for BUG_ON messages referencing net device reg_state, mtk_eth_soc probe failures, or unexpected panics during Ethernet driver load.

What your security team should do

• Prioritize kernel updates for systems using mtk_eth_soc driver
• Review boot logs for Ethernet probe errors on affected hardware
• Test driver initialization under failure conditions in staging environments