From: sashiko-bot@kernel.org
To: live-patching@vger.kernel.org
Cc: "Miroslav Benes" <mbenes@suse.cz>,
"Petr Mladek" <pmladek@suse.com>,
"Josh Poimboeuf" <jpoimboe@kernel.org>,
"Song Liu" <song@kernel.org>
Subject: Re: [RFC 2/4] objtool/klp: allow special section entry size overrides
Date: Thu, 14 May 2026 20:58:30 +0000 [thread overview]
Message-ID: <20260514205831.0AEDCC2BCB3@smtp.kernel.org> (raw)
In-Reply-To: <20260512221102.2720763-3-joe.lawrence@redhat.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The custom entry size logic bypasses section size validation, allowing the creation of out-of-bounds ELF symbols.
--
commit 07468f70445bbc595d50f5edb50b5c394dc62f05
Author: Joe Lawrence <joe.lawrence@redhat.com>
objtool/klp: allow special section entry size overrides
This commit allows users to override compiled-in defaults for special
section entry sizes via environment variables. This helps process cached
unit test objects built from different kernel versions where the compiled-in
sizes may not match the actual entry sizes.
> diff --git a/tools/objtool/klp-diff.c b/tools/objtool/klp-diff.c
> index 0774ab312d033..84c00b673085b 100644
> --- a/tools/objtool/klp-diff.c
> +++ b/tools/objtool/klp-diff.c
[ ... ]
> @@ -1700,6 +1716,21 @@ static int create_fake_symbols(struct elf *elf)
> }
>
> entry_size = sec->sh.sh_entsize;
> +
> + /*
> + * Some special sections have multiple relocs per entry,
> + * so the reloc-based heuristic below doesn't work. Use
> + * the arch-defined entry sizes for known special sections.
> + */
> + if (!entry_size) {
> + if (!strcmp(sec->name, ".altinstructions"))
> + entry_size = entry_size_from_env("ALT_ENTRY_SIZE", ALT_ENTRY_SIZE);
> + else if (!strcmp(sec->name, "__jump_table"))
> + entry_size = entry_size_from_env("JUMP_ENTRY_SIZE", JUMP_ENTRY_SIZE);
> + else if (!strcmp(sec->name, "__ex_table"))
> + entry_size = entry_size_from_env("EX_ENTRY_SIZE", EX_ENTRY_SIZE);
> + }
> +
> if (!entry_size) {
> entry_size = arch_reloc_size(sec->rsec->relocs);
> if (sec_size(sec) != entry_size * sec_num_entries(sec->rsec)) {
If entry_size is populated from the environment variables, it skips this
validation check entirely.
If an invalid entry size that isn't a clean divisor of the section size is
provided, could this lead to an out-of-bounds memory access regression?
> ERROR("%s: missing special section entsize or annotations", sec->name);
> return -1;
> }
> }
>
> for (offset = 0; offset < sec_size(sec); offset += entry_size) {
> if (create_fake_symbol(elf, sec, offset, entry_size))
> return -1;
> }
For example, if sec_size(sec) is 20 and entry_size is provided as 12, the
loop will execute for offset 0 and offset 12. During the second iteration,
the fake symbol will extend from 12 to 24, which exceeds the section bounds
and may cause out-of-bounds accesses during subsequent objtool passes.
Should there be an explicit validation check to ensure the overridden
entry_size divides evenly into sec_size(sec) before proceeding to this loop?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260512221102.2720763-1-joe.lawrence@redhat.com?part=2
next prev parent reply other threads:[~2026-05-14 20:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-12 22:10 [RFC 0/4] klp-build: simple OOT module support Joe Lawrence
2026-05-12 22:10 ` [RFC 1/4] objtool/klp: add --symvers option to klp diff Joe Lawrence
2026-05-14 20:47 ` sashiko-bot
2026-05-12 22:11 ` [RFC 2/4] objtool/klp: allow special section entry size overrides Joe Lawrence
2026-05-14 20:58 ` sashiko-bot [this message]
2026-05-12 22:11 ` [RFC 3/4] objtool/klp: add --arch option to display target architecture Joe Lawrence
2026-05-14 21:10 ` sashiko-bot
2026-05-12 22:11 ` [RFC 4/4] livepatch/klp-build: add basic out-of-tree module patching support Joe Lawrence
2026-05-14 21:20 ` sashiko-bot
2026-05-12 23:30 ` [RFC 0/4] klp-build: simple OOT module support Song Liu
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=20260514205831.0AEDCC2BCB3@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=jpoimboe@kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=pmladek@suse.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=song@kernel.org \
/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.