All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Fang Xieyan" <fangxy@xiaopeng.com>
Cc: linux-modules@vger.kernel.org
Subject: Re: [PATCH 2/2] module: Validate the __version_ext_names section offset
Date: Wed, 16 Sep 2026 18:05:22 +0000	[thread overview]
Message-ID: <20260916180523.1F0E21F00898@smtp.kernel.org> (raw)
In-Reply-To: <20260916174753.14870-3-fangxy@xiaopeng.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] module: allows reading arbitrary file data for SHT_NOBITS sections
--

commit 7826bfa932aee0181b2db001dad06d62e3bc7702
Author: Fang Xieyan <fangxy@xiaopeng.com>
module: Validate the __version_ext_names section offset

This commit bounds the offset of the __version_ext_names section to prevent
an out-of-bounds read when encountering a SHT_NOBITS section. It adds a call
to validate_section_offset() in elf_validity_cache_index_versions() before
dereferencing the section's offset.

> diff --git a/kernel/module/main.c b/kernel/module/main.c
> index e36bfe4734d59..adaaaca5a4e68 100644
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c
> @@ -2296,6 +2296,16 @@ static int elf_validity_cache_index_versions(struct load_info *info, int flags)
>  	 * number of entries in every section.
>  	 */
>  	if (vers_ext_crc) {
> +		/*
> +		 * The name section is walked by its sh_offset and sh_size
> +		 * below. elf_validity_check_sectionheaders() exempts SHT_NOBITS
> +		 * sections from validate_section_offset(), so a __version_ext_names
> +		 * section of that type reaches here with an unvalidated sh_offset.
> +		 * Bound it before dereferencing hdr + sh_offset.
> +		 */
> +		if (validate_section_offset(info, &info->sechdrs[vers_ext_name]))
> +			return -ENOEXEC;

[Severity: Low]
Does this allow in-bounds SHT_NOBITS sections to pass, reading arbitrary
in-bounds file data as extended version names?

This would appear to violate ELF semantics since SHT_NOBITS sections are
not supposed to hold file data.

> +
>  		crc_count = info->sechdrs[vers_ext_crc].sh_size / sizeof(u32);
>  		name = (void *)info->hdr +
>  			info->sechdrs[vers_ext_name].sh_offset;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260916174753.14870-1-fangxy@xiaopeng.com?part=2

      reply	other threads:[~2026-09-16 18:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-16 17:47 [PATCH 0/2] module: close two ELF section-validation gaps Fang Xieyan
2026-09-16 17:47 ` [PATCH 1/2] module: Sanitize the undefined sh_name of SHT_NULL sections Fang Xieyan
2026-09-16 17:47 ` [PATCH 2/2] module: Validate the __version_ext_names section offset Fang Xieyan
2026-09-16 18:05   ` sashiko-bot [this message]

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=20260916180523.1F0E21F00898@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=fangxy@xiaopeng.com \
    --cc=linux-modules@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.