BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "David Laight" <david.laight.linux@gmail.com>,
	"Petr Mladek" <pmladek@suse.com>, "Kees Cook" <kees@kernel.org>,
	linux-kbuild@vger.kernel.org, bpf@vger.kernel.org,
	"Jim Cromie" <jim.cromie@gmail.com>,
	"Lorenzo Stoakes" <ljs@kernel.org>
Cc: "Luis Chamberlain" <mcgrof@kernel.org>,
	"Andrey Grodzovsky" <andrey.grodzovsky@crowdstrike.com>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Samuel Wu" <wusamuel@google.com>,
	nathan@kernel.org, nsc@kernel.org
Subject: Re: [PATCH v3 next 04/13] scripts/kallsyms: make use of binary data output optional
Date: Wed, 11 Nov 2026 12:32:07 +0000	[thread overview]
Message-ID: <sashiko-outbox-208980@kernel.org> (raw)
In-Reply-To: <20261111115911.1142000-5-david.laight.linux@gmail.com>

Thank you for your contribution! Sashiko AI review found 3 potential
issues to consider:
- [Medium] scripts/kallsyms: wrong variable negated for negative offsets
  in write_src()
- [Medium] scripts/kallsyms: 9-digit buffer in write_src() clobbers sign
  on large offsets
- [Low] scripts/kallsyms: missing endian.h include for htobe32() and
  htole32()
--

commit b5cbf4ceba792715bcee0dd6d58ce67f9542a5ad
Author: David Laight <david.laight.linux@gmail.com>

scripts/kallsyms: make use of binary data output optional

This commit makes the binary output file and input ELF file optional in
scripts/kallsyms, writes the markers table in target endianness when using
binary output, and formats pc-relative offsets into a buffer for fwrite().

> diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
> index aa3a8ec83fbb8..74db751600b4f 100644
> --- a/scripts/kallsyms.c
> +++ b/scripts/kallsyms.c
[ ... ]
> @@ -406,51 +417,105 @@ static void write_src(FILE *out_bin_file, const char *out_bin_name)
[ ... ]
> +		if (out_bin_file) {
> +			if ((i & 0xFF) == 0)
> +				markers[i >> 8] = big_endian ? htobe32(off) : htole32(off);

[Severity: Low]
Does scripts/kallsyms.c need to include <endian.h> for htobe32() and
htole32()?  Glibc pulls it in transitively through <stdlib.h>, but on
musl libc hosts neither scripts/kallsyms.c nor its included headers
declare these functions, breaking the host tool build.

[ ... ]

> @@ -458,31 +523,15 @@ static void write_src(FILE *out_bin_file, const char *out_bin_name)
[ ... ]
>  	output_label("kallsyms_offsets");
>  
>  	for (i = 0; i < table_cnt; i++) {
>  		if (pc_relative) {
> +			/* All 64 bit builds and (at least) relocatable 32 bit ones */
> +			static char line[] = "\t.long\t_text - . +123456789";
> +			char *end = line + sizeof(line) - 1;
>  			long long offset = table[i]->addr - _text;
> +			int off32;
>  
>  			if (offset < INT_MIN || offset > INT_MAX) {
>  				errx(EXIT_FAILURE, "kallsyms failure: "
> @@ -490,12 +539,28 @@ static void write_src(FILE *out_bin_file, const char *out_bin_name)
>  					table[i]->addr);
>  				exit(EXIT_FAILURE);
>  			}
> -			printf("\t.long\t_text - . + (%d)\t/* %s */\n",
> -			       (int)offset, table[i]->sym);
> +
> +			/* Build the line so the the faster fwrite() can be used */
> +			*end-- = out_bin_file ? '\n' : '\t';
> +			memset(end - 8, ' ', 8);
> +			off32 = offset;
> +			if (off32 < 0) {
> +				end[-9] = '-';
> +				offset = -off32;
> +			} else {
> +				end[-9] = '+';
> +			}

[Severity: Medium]
Should this negate off32 (or an unsigned magnitude) instead of assigning
-off32 back to offset?  Because offset is not used after this point,
off32 stays negative when a symbol lies below _text, so off32 % 10 in the
digit loop below yields negative remainders and writes non-digit ASCII
characters into the assembly output (and -off32 overflows if off32 is
INT_MIN).

> +			do
> +				*end-- = '0' + off32 % 10;
> +			while (off32 /= 10);

[Severity: Medium]
Can a 10-digit offset in [INT_MIN, INT_MAX] overwrite the '+' or '-' sign
in line[]?  The template only reserves 9 digit slots after end[-9], so any
symbol at least 1,000,000,000 bytes from _text runs 10 iterations of the
loop and clobbers end[-9], emitting invalid assembly syntax.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261111115911.1142000-1-david.laight.linux@gmail.com?part=4

  reply	other threads:[~2026-11-11 12:32 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-11 11:58 [PATCH v3 next 00/13] kallsyms: optimise symbol search by name David Laight
2026-11-11 11:58 ` [PATCH v3 next 01/13] scripts/kallsyms: Avoid overrunning on-stack buffer David Laight
2026-11-11 11:59 ` [PATCH v3 next 02/13] scripts/kallsyms: Improve error reporting David Laight
2026-11-11 12:14   ` sashiko-bot
2026-11-11 23:33   ` bot+bpf-ci
2026-11-11 11:59 ` [PATCH v3 next 03/13] scripts/elf-parse: add elf_map_big_endian() helper David Laight
2026-11-11 11:59 ` [PATCH v3 next 04/13] scripts/kallsyms: make use of binary data output optional David Laight
2026-11-11 12:32   ` sashiko-bot [this message]
2026-11-11 23:34   ` bot+bpf-ci
2026-11-11 11:59 ` [PATCH v3 next 05/13] kallsyms: Fix selftest startup delay David Laight
2026-11-11 12:36   ` sashiko-bot
2026-11-11 11:59 ` [PATCH v3 next 06/13] kallsyms: Improve selftest test_perf_kallsyms_lookup_name() output David Laight
2026-11-11 23:17   ` bot+bpf-ci
2026-11-11 11:59 ` [PATCH v3 next 07/13] kallsyms: Match compressed tokens on the fly during binary search David Laight
2026-11-11 12:46   ` sashiko-bot
2026-11-11 11:59 ` [PATCH v3 next 08/13] kallsyms: Optimise symbol name search David Laight
2026-11-11 12:59   ` sashiko-bot
2026-11-11 11:59 ` [PATCH v3 next 09/13] kallsyms: Add a kernel parameter to change the kallsyms_markers[] density David Laight
2026-11-11 13:07   ` sashiko-bot
2026-11-11 23:33   ` bot+bpf-ci
2026-11-11 11:59 ` [PATCH v3 next 10/13] scripts/kallsyms: Keep full expansion of tokens David Laight
2026-11-11 11:59 ` [PATCH v3 next 11/13] scripts/kallsyms: Optimise compress_symbols() David Laight
2026-11-11 11:59 ` [PATCH v3 next 12/13] scripts/kallsyms: Reuse tokens that have no references David Laight
2026-11-11 23:34   ` bot+bpf-ci
2026-11-11 11:59 ` [PATCH v3 next 13/13] scripts/kallsyms: Reuse little-used compression tokens David Laight
2026-11-11 13:37   ` sashiko-bot

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=sashiko-outbox-208980@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=andrey.grodzovsky@crowdstrike.com \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=david.laight.linux@gmail.com \
    --cc=jim.cromie@gmail.com \
    --cc=kees@kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=nathan@kernel.org \
    --cc=nsc@kernel.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=wusamuel@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