From: Maoyi Xie <maoyixie.tju@gmail.com>
To: Loic Poulain <loic.poulain@oss.qualcomm.com>,
Sergey Ryazanov <ryazanov.s.a@gmail.com>,
Johannes Berg <johannes@sipsolutions.net>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: net: wwan: iosm: possible out of bounds read in the MUX downlink decoder
Date: Fri, 19 Jun 2026 11:05:20 +0800 [thread overview]
Message-ID: <178183832043.3878023.3610072137230679925@maoyixie.com> (raw)
Hi all,
I think mux_dl_adb_decode() in drivers/net/wwan/iosm/iosm_ipc_mux_codec.c can
read past the downlink buffer when the modem reports a large table index. I
would appreciate it if you could take a look.
The decoder takes the table offset straight from the device ADB header.
block = skb->data;
adbh = (struct mux_adbh *)block;
adth_index = le32_to_cpu(adbh->first_table_index);
if (adth_index < 1)
goto adb_decode_err;
...
adth = (struct mux_adth *)(block + adth_index);
first_table_index is a device le32 and the only check is that it is not
zero. After that adth points at block + adth_index with no upper bound and
the code reads adth->table_length and the datagram table from there. The
downlink buffer is IPC_MEM_MAX_DL_MUX_LITE_BUF_SIZE, 2048 bytes, so an index
past 2048 reads past the slab object.
mux_dl_process_dg() has the same issue further down. It reads
dg->datagram_index and dg->datagram_length per entry, bounded only by the
device block_length, which is itself never checked against skb->len.
The protocol layer below only caps the total transfer at the pipe buffer
size and skb_put()s it, so skb->len is at most 2048, but none of these
in band offsets and lengths are checked against it.
The data here comes from the modem, so it is device input we should not
trust, especially with an external or compromised PCIe baseband. It fires on
a normal downlink receive once the iosm net device is up.
I reproduced the adth_index read under KASAN on 7.1-rc7. With an index that
fits the buffer the read stays inside. With an index past the buffer KASAN
reports a slab out of bounds read past the downlink buffer.
The fix I have in mind validates every device offset and length against
skb->len before use, rejecting an adth_index that leaves no room for a
struct mux_adth and a datagram that runs past the buffer.
Does this look like a real bug to you? The aggregation decoder has moved
around over the years, so I am not certain of the exact introducing commit.
1f52d7b62285 ("net: wwan: iosm: Enable M.2 7360 WWAN card support") is the
broadly cited landing point. I am happy to send a proper patch.
Thanks,
Maoyi
https://maoyixie.com/
next reply other threads:[~2026-06-19 3:05 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-19 3:05 Maoyi Xie [this message]
2026-06-19 7:43 ` net: wwan: iosm: possible out of bounds read in the MUX downlink decoder Loic Poulain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=178183832043.3878023.3610072137230679925@maoyixie.com \
--to=maoyixie.tju@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=loic.poulain@oss.qualcomm.com \
--cc=netdev@vger.kernel.org \
--cc=ryazanov.s.a@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox