CVE-2025-38123

What it actually does

Use-after-free in the t7xx WWAN driver where napi rx polling continues to reference a netdev that has already been released by dellink on user-plane disconnect, resulting in NULL pointer dereference and kernel panic during dev_gro_receive.

Why it matters to the business

Unexpected kernel crashes on systems using the affected WWAN hardware during modem disconnect or network teardown events, leading to loss of connectivity, service disruption, and the need for immediate reboots; high prevalence in Linux kernel deployments increases exposure across servers and embedded devices.

How an attack unfolds

An attacker with local access or control over the user-plane disconnect operation triggers a race between napi rx polling and netdev release; the polling path then dereferences the freed netdev inside dev_gro_receive, crashing the kernel. Related threat actors listed in kernel privilege-escalation campaigns may chain this DoS into further exploitation on unpatched systems.

How to fix it

Update the Linux kernel to the fixed commit cc89f457d9133a558d4e8ef26dc20843c2d12073 or later stable releases containing the napi rx poll fix; apply vendor-supplied patches for affected distributions and rebuild any custom kernels incorporating the mtk_t7xx driver.

How to confirm the fix worked

Confirm the running kernel contains commit cc89f457d9133a558d4e8ef26dc20843c2d12073 or equivalent backport; reproduce the disconnect scenario under load and verify no NULL dereference occurs; inspect dmesg for absence of the dev_gro_receive oops signature.

Typical attack path

1. Obtain local access or trigger user-plane disconnect on the t7xx WWAN interface
2. Force concurrent napi rx polling while dellink releases the netdev
3. Cause the polling logic to call napi_gro_receive on the invalid netdev
4. Trigger NULL pointer dereference in dev_gro_receive leading to kernel panic

How to detect it

Search kernel logs for the signature 'BUG: kernel NULL pointer dereference' combined with 'dev_gro_receive' and 't7xx_ccmni_recv_skb' or 't7xx_dpmaif_napi_rx_poll'; correlate with WWAN disconnect events in system logs and look for preceding user-plane teardown activity.

What your security team should do

• Prioritize kernel updates on all systems exposing the t7xx WWAN driver within the next 30 days given the 481-day publication window
• Monitor for related kernel privilege-escalation activity from the listed threat actors and apply layered hardening
• Test disconnect/reconnect sequences in staging environments before production rollout
• Disable the t7xx driver module if WWAN functionality is not required