From: Petr Pavlu <petr.pavlu@suse.com>
To: "Thiébaud Weksteen" <tweek@google.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
Daniel Gomez <da.gomez@kernel.org>,
Sami Tolvanen <samitolvanen@google.com>,
Aaron Tomlin <atomlin@atomlin.com>,
Siddharth Nayyar <sidnayyar@google.com>,
linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] module: validate string table section types
Date: Wed, 8 Jul 2026 17:40:19 +0200 [thread overview]
Message-ID: <33fba1b5-d107-46cd-896f-bd2539a4a0b6@suse.com> (raw)
In-Reply-To: <20260708012107.1621513-1-tweek@google.com>
On 7/8/26 3:21 AM, Thiébaud Weksteen wrote:
> In elf_validity_cache_sechdrs, section sizes and offsets are validated,
> unless the section type is SHT_NULL or SHT_NOBITS.
>
> Later, elf_validity_cache_secstrings and elf_validity_cache_index_str
> access the section name table (.shstrtab) and symbol string table
> (.strtab) headers without first ensuring that their types are
> SHT_STRTAB. If a section type is SHT_NULL or SHT_NOBITS, sh_offset has
> not been validated and may reference out-of-bounds memory when
> dereferenced in elf_validity_cache_secstrings or
> elf_validity_cache_strtab.
>
> Validate that both string section headers are of type SHT_STRTAB before
> caching them.
The module loader should normally at least get through the signature and
blacklist checks without crashing due to a corrupted module ELF file.
Failing to validate the offset+size of .shstrtab means the module loader
could crash before the blacklist check, so I believe it is useful to add
this validation.
How did you run into this issue? Was it observed in practice with the
GNU or LLVM toolchain, or with some manually crafted module?
--
Thanks,
Petr
next prev parent reply other threads:[~2026-07-08 15:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 1:21 [PATCH] module: validate string table section types Thiébaud Weksteen
2026-07-08 1:33 ` sashiko-bot
2026-07-08 15:40 ` Petr Pavlu [this message]
2026-07-09 1:56 ` Thiébaud Weksteen
2026-07-09 9:23 ` Petr Pavlu
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=33fba1b5-d107-46cd-896f-bd2539a4a0b6@suse.com \
--to=petr.pavlu@suse.com \
--cc=atomlin@atomlin.com \
--cc=da.gomez@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=samitolvanen@google.com \
--cc=sidnayyar@google.com \
--cc=tweek@google.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