CVE-2026-72029

net: wwan: iosm: bound device offsets in the MUX downlink decoder

HIGH
8.8
CVSS Score
Published: August 15, 2026 at 05:51 AM UTC
Updated: October 19, 2026 at 10:17 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
HIGH8.8
Exploit prediction
EPSS 0.4%
SSVC
No known exploit

Description

In the Linux kernel, the following vulnerability has been resolved: net: wwan: iosm: bound device offsets in the MUX downlink decoder mux_dl_adb_decode() walks a chain of aggregated datagram tables using offsets and lengths taken from the modem. first_table_index, next_table_index, table_length, datagram_index and datagram_length are all device supplied le values. Only first_table_index was checked, and only for being non zero. The decoder then formed adth = block + adth_index and read the table header and the datagram entries with no bound against the received skb. A modem that reports an index or a length past the downlink buffer makes the decoder read out of bounds. The buffer is IPC_MEM_MAX_DL_MUX_LITE_BUF_SIZE and skb->len is at most that, so skb->len is the real limit, but none of these in band offsets were checked against it. The table chain is also followed with no forward progress check. The loop takes the next table from adth->next_table_index and stops only when that reaches zero. A modem can stage two tables that point at each other, so the loop never ends. It runs in softirq and clones the skb on every pass. Validate every device offset and length against skb->len before use. The block header must fit. Each table header, on entry and after every next_table_index, must lie inside the skb. The datagram table must fit. Each datagram index and length must stay inside the skb. The header padding must not exceed the datagram length so the receive length does not wrap. Require each next_table_index to move forward so the chain cannot cycle. This was reproduced under KASAN as a slab out of bounds read on a normal downlink receive once the iosm net device is up.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

1f52d7b622854b8bd7a1be3de095ca2e1f77098e5.18
Vendor states this is fixed in 07f5eb6d268a37bd9e131079489655cd599182e0 (fixed)
Vendor states this is fixed in 155851e501d6c649cbcfcca6472dc26269b04b6b (fixed)
Vendor states this is fixed in 2b822df8e498aa6ca828e16afd8ffec27f7e4c88 (fixed)
Vendor states this is fixed in 526b8ef54668780c8f69e0211c342763d5dcbad1 (fixed)
Vendor states this is fixed in 55cfea8e8d9117ad086d1e1a0ff87f306f8e3ad0 (fixed)
Vendor states this is fixed in 77f0023f22f6a2616ae128e9c93961b24ae52611 (fixed)
Vendor states this is fixed in 5.18 (unaffected)
Vendor states this is fixed in 6.1.178 (unaffected)
Vendor states this is fixed in 6.12.97 (unaffected)
Vendor states this is fixed in 6.18.40 (unaffected)
Vendor states this is fixed in 6.6.145 (unaffected)
Vendor states this is fixed in 7.1.5 (unaffected)
Vendor states this is fixed in 7.2 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

SSVC — Action Prioritization

SSVCNo known exploitNot automatableTotal impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

8.8HIGHLinux
Vector?

Quick Info

StatusRECEIVED
CWE
CWE-125

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card