From: Maoyi Xie <maoyixie.tju@gmail.com>
To: Vaibhav Agarwal <vaibhav.sr@gmail.com>,
Mark Greer <mgreer@animalcreek.com>
Cc: Johan Hovold <johan@kernel.org>, Alex Elder <elder@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
greybus-dev@lists.linaro.org, linux-staging@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: staging: greybus: audio: possible out of bounds read in the topology parser
Date: Fri, 19 Jun 2026 10:36:10 +0800 [thread overview]
Message-ID: <178183657058.3862365.12892304946786698397@maoyixie.com> (raw)
Hi all,
I think the Greybus audio topology parser in
drivers/staging/greybus/audio_topology.c can read past the topology blob
when a module reports inconsistent counts. I would appreciate it if you
could take a look.
gb_audio_gb_get_topology() allocates the blob to a device-reported u16 size
and only checks that it is at least sizeof(struct gb_audio_topology).
size = le16_to_cpu(size_resp.size);
if (size < sizeof(*topo))
return -ENODATA;
topo = kzalloc(size, GFP_KERNEL);
After that the parser trusts the interior fields. gb_generate_enum_strings()
walks one C string per item with no end pointer.
items = le32_to_cpu(gbenum->items);
for (i = 0; i < items; i++) {
strings[i] = data;
while (*data != '\0')
data++;
data++;
}
items is a device le32 and there is no guarantee the blob holds that many
NUL terminated strings, so the while loop runs off the end of the
allocation. The same pattern is in gbaudio_tplg_process_header(), which
derives the control, widget and route offsets by adding device le32 block
sizes with no check against the end of the blob, and in the csize cursor
advance in gbaudio_tplg_process_kcontrols() and gbaudio_tplg_create_widget().
The whole blob is device data parsed on the probe path with no privilege
needed. The attacker here is a malicious or faulty Greybus audio module on
the interface.
I reproduced the enum string walk under KASAN on 7.1-rc7. A blob with one
NUL per item stays inside the allocation. A blob with missing terminators
makes KASAN report a slab out of bounds read past the buffer.
I have a partial fix that passes the buffer end into the enum walk and stops
on overrun. A complete fix also needs to bound the header offsets and the
csize advances against the allocation size, so I wanted to ask before
sending a series.
Does this look like a real bug to you? If it does I am happy to send a
proper patch. The parser was added in c8e6336bb3f8 ("greybus: audio: Add
topology parser for GB codec"), which I think is the right Fixes tag.
Thanks,
Maoyi
https://maoyixie.com/
next reply other threads:[~2026-06-19 2:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-19 2:36 Maoyi Xie [this message]
2026-06-19 4:37 ` Greg Kroah-Hartman
2026-06-19 5:35 ` Maoyi Xie
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=178183657058.3862365.12892304946786698397@maoyixie.com \
--to=maoyixie.tju@gmail.com \
--cc=elder@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=greybus-dev@lists.linaro.org \
--cc=johan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=mgreer@animalcreek.com \
--cc=vaibhav.sr@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
all inboxes | Powered by JetHome®