CVE-2025-68192

What it actually does

Uninitialized skb->mac_header offset in qmimux_rx_fixup for raw IP packets triggers kernel panic on ARM64 when xfrm or other subsystems dereference the offset under strict alignment checks, particularly during IPsec processing on qmimux0.

Why it matters to the business

Systems using affected USB modems with IPsec experience unexpected kernel crashes leading to service disruption and potential data loss until reboot.

How an attack unfolds

An attacker or legitimate traffic triggers raw IP packet reception over the qmimux interface while IPsec is active; the uninitialized offset is accessed in xfrm_input causing an Oops and panic on ARM64 hardware.

How to fix it

Apply the upstream fix in commit d693c47fb902b988f5752182e4f7fbde5e6dcaf9 or upgrade to a kernel containing this commit; disable qmimux or IPsec over the interface as a temporary mitigation.

How to confirm the fix worked

Verify the patch is present by checking git log for d693c47fb902b988f5752182e4f7fbde5e6dcaf9, rebuild and boot the kernel, then confirm no panic occurs when sending IPsec traffic over qmimux0 on ARM64.

Typical attack path

1. Establish IPsec tunnel over qmimux0 interface
2. Receive raw IP packets via the qmi_wwan driver
3. xfrm or network stack accesses uninitialized mac_header offset
4. Kernel panic occurs due to alignment violation on ARM64

How to detect it

Search kernel logs and dmesg for 'Internal error: Oops' combined with 'xfrm_input' and references to qmimux0 or ipv6_rcv on ARM64 systems; correlate with qmi_wwan driver activity.

• xfrm_input+0xde8/0x1318
• qmimux0
• Internal error: Oops: 000000009600004f
• ip6_protocol_deliver_rcu
• net: usb: qmi_wwan

What your security team should do

• Prioritize kernel upgrade to the fixed commit for all affected systems using qmi_wwan with IPsec
• Monitor kernel logs for xfrm_input Oops entries on ARM devices
• Test IPsec connectivity over qmimux interfaces after patching