CVE-2026-98236
NoneCVSS
—
EPSS
0.2%
Published
Oct 6, 2026
CISA due date
—
Cloudanix analysis
A wireless modem driver bug could let internal operating-system information leak out over the network connection.
- Exploitation
- Adjacent Network
- Attacker needs
- None
- Complexity
- Moderate
- Impact
- Data Exposure
- Component
- OS kernel
- Class
- Information Disclosure
- Remediation
- Patch
- Effort
- Low
- Patch risk
- None
What it actually does
A malicious modem can supply a DPE pointing outside the received NTB; skb_copy_bits fails yet the driver still hands an uninitialized sk_buff to netif_rx, leaking kernel heap memory into the network stack.
Why it matters to the business
Potential exposure of kernel memory contents over the network interface increases the risk of sensitive data leakage on systems using affected WWAN drivers; the issue has not been observed in active exploitation campaigns and carries low exploitation probability.
How an attack unfolds
An attacker who can control or emulate a WWAN modem crafts an NTB containing a DPE whose offset and length lie outside the buffer. The driver performs only a bounds check against the NTB itself, calls skb_copy_bits without checking its return value, and delivers the freshly allocated but uninitialized sk_buff to netif_rx, allowing the leaked kernel bytes to be observed as network traffic.
How to fix it
Apply the upstream kernel patch that adds a check on skb_copy_bits return value, drops the skb, and increments the rx-error counter on failure; update to a kernel release containing this fix once it is available in your distribution.
How to confirm the fix worked
Confirm the presence of the skb_copy_bits return-value check in mhi_mbim_rx and mhi_mbim_rx_drop; re-test with a fault injector that supplies an out-of-bounds DPE and verify that the packet is dropped rather than delivered with uninitialized data.
Typical attack path
- Gain ability to send crafted NTB frames from a WWAN modem or emulator
- Construct an NTB whose DPE offset/length points outside the received skb
- Trigger mhi_mbim_rx processing on the host
- Observe kernel-heap contents delivered via netif_rx as packets with unknown protocol
How to detect it
Inspect WWAN interface logs and packet captures for unexpected 'unknown protocol' frames containing previously unwritten bytes; correlate with mhi_mbim_rx error counters and skb allocation patterns around modem receive paths.
What your security team should do
- Track distribution kernel updates that include the skb_copy_bits validation fix
- Prioritize patching WWAN-enabled systems once the fix reaches stable branches
- Review network-interface error counters on WWAN devices for anomalous rx drops
The record
In the Linux kernel, the following vulnerability has been resolved: net: wwan: mhi_wwan_mbim: check skb_copy_bits() return value mhi_mbim_rx() ignores the return value of skb_copy_bits() when it copies each datagram out of the NTB. The datagram offset and length come from the DPE, which is only checked to lie within the NTB itself, so a modem can point a datagram outside the received skb. The copy then fails and the freshly allocated skbn is passed to netif_rx() with its uninitialized contents still in place, leaking kernel heap memory into the network stack. Free the skb and account an error when the copy fails. Verified in a QEMU guest with a fault injector pointing a DPE outside the received NTB: the copy fails, and the unpatched driver hands the uninitialized skbn to the network stack (observed as "unknown protocol" on bytes that were never written). With this check the failed datagram is dropped and counted as an rx error. Changes in v2: factor the free-and-count sequence out into mhi_mbim_rx_drop(), shared with the unknown-protocol path, as suggested by Loic Poulain.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|