[PATCH] tracepoint-update: bound section names by the section name table

[PATCH] tracepoint-update: bound section names by the section name table

[Leizhen Zhang]

process_tracepoints() finds its two sections by name:

	secstrings = (const char *)ehdr + shdr_offset(string_sec);
	...
		idx = shdr_name(shdr);
		if (!strcmp(secstrings + idx, "__tracepoint_check")) {

sh_name is a 32-bit offset read from the file and nothing bounds it, so one
section header can point the name anywhere and strcmp() reads from there.

Found by fuzzing the host ELF tools with mutated object files under
ASan/UBSan. Reproducer, setting only sh_name of section 1 in an otherwise
valid .o:

  $ python3 -c 'import struct
  d = bytearray(open("tiny.o","rb").read())
  shoff, = struct.unpack_from("<Q", d, 0x28)
  entsize, = struct.unpack_from("<H", d, 0x3a)
  struct.pack_into("<I", d, shoff + entsize, 0x7ffffff0)
  open("t.o","wb").write(bytes(d))'

  $ ./tracepoint-update t.o
  ERROR: AddressSanitizer: SEGV on unknown address 0x7f8d689ae848
    #0 in strcmp
    #1 in process_tracepoints scripts/tracepoint-update.c

Skip a section whose name offset is outside the name table. Such a section
is neither __tracepoint_check nor __tracepoints_strings, so skipping it
changes nothing for a valid object: the reproducer and an unmodified object
now both print the same "no __tracepoint_check in file" line and exit 1.

This bounds the index into the table, not the table itself: a name table
whose own sh_offset or sh_size is bogus is a separate gap, and in the
elf_map() path used here there is no mapped size to check it against.

Fixes: e30f8e61e251 ("tracing: Add a tracepoint verification check at build time")
Assisted-by: LLM ASan UBSan
Signed-off-by: Leizhen Zhang <lzsx618@gmail.com>
---
 scripts/tracepoint-update.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/scripts/tracepoint-update.c b/scripts/tracepoint-update.c
index 5cf43c0aac89..2736e91e6f06 100644
--- a/scripts/tracepoint-update.c
+++ b/scripts/tracepoint-update.c
@@ -157,6 +157,7 @@ static int process_tracepoints(bool mod, void *addr, const char *fname)
 	Elf_Shdr *shdr_start;
 	Elf_Shdr *string_sec;
 	const char *secstrings;
+	uint64_t secstrings_size;
 	unsigned int shnum;
 	unsigned int shstrndx;
 	int shentsize;
@@ -171,6 +172,7 @@ static int process_tracepoints(bool mod, void *addr, const char *fname)
 		shstrndx = shdr_link(shdr_start);
 	string_sec = get_index(shdr_start, shentsize, shstrndx);
 	secstrings = (const char *)ehdr + shdr_offset(string_sec);
+	secstrings_size = shdr_size(string_sec);
 
 	shnum = ehdr_shnum(ehdr);
 	if (shnum == SHN_UNDEF)
@@ -179,7 +181,10 @@ static int process_tracepoints(bool mod, void *addr, const char *fname)
 	for (int i = 0; done && i < shnum; i++) {
 		Elf_Shdr *shdr = get_index(shdr_start, shentsize, i);
 
+		/* sh_name is a file-supplied offset into the name table. */
 		idx = shdr_name(shdr);
+		if ((uint32_t)idx >= secstrings_size)
+			continue;
 
 		/* locate the __tracepoint_check in vmlinux */
 		if (!strcmp(secstrings + idx, "__tracepoint_check")) {
-- 
2.34.1

Re: [PATCH] tracepoint-update: bound section names by the section name table

[Steven Rostedt]

On Sun, 18 Oct 2026 19:04:19 -0500
Leizhen Zhang <lzsx618@gmail.com> wrote:

> process_tracepoints() finds its two sections by name:
> 
> 	secstrings = (const char *)ehdr + shdr_offset(string_sec);
> 	...
> 		idx = shdr_name(shdr);
> 		if (!strcmp(secstrings + idx, "__tracepoint_check")) {
> 
> sh_name is a 32-bit offset read from the file and nothing bounds it, so one
> section header can point the name anywhere and strcmp() reads from there.
> 
> Found by fuzzing the host ELF tools with mutated object files under
> ASan/UBSan. Reproducer, setting only sh_name of section 1 in an otherwise
> valid .o:
> 
>   $ python3 -c 'import struct
>   d = bytearray(open("tiny.o","rb").read())
>   shoff, = struct.unpack_from("<Q", d, 0x28)
>   entsize, = struct.unpack_from("<H", d, 0x3a)
>   struct.pack_into("<I", d, shoff + entsize, 0x7ffffff0)
>   open("t.o","wb").write(bytes(d))'
> 
>   $ ./tracepoint-update t.o
>   ERROR: AddressSanitizer: SEGV on unknown address 0x7f8d689ae848
>     #0 in strcmp
>     #1 in process_tracepoints scripts/tracepoint-update.c
> 
> Skip a section whose name offset is outside the name table. Such a section
> is neither __tracepoint_check nor __tracepoints_strings, so skipping it
> changes nothing for a valid object: the reproducer and an unmodified object
> now both print the same "no __tracepoint_check in file" line and exit 1.
> 
> This bounds the index into the table, not the table itself: a name table
> whose own sh_offset or sh_size is bogus is a separate gap, and in the
> elf_map() path used here there is no mapped size to check it against.
> 
> Fixes: e30f8e61e251 ("tracing: Add a tracepoint verification check at build time")

This is not a fix. This is just passing a corrupt object file into the
build tooling and showing that it fails.

Show me that this can be triggered by a legitimate object file and then I
would consider it. Otherwise, you are chasing made up bugs.

-- Steve


> Assisted-by: LLM ASan UBSan
> Signed-off-by: Leizhen Zhang <lzsx618@gmail.com>
> ---
>  scripts/tracepoint-update.c | 5 +++++

Re: [PATCH] tracepoint-update: bound section names by the section name table

[Leizhen Zhang]

On Sun, 19 Oct 2026 09:53:02 -0400 Steven Rostedt <rostedt@goodmis.org> wrote:
> This is not a fix. This is just passing a corrupt object file into the
> build tooling and showing that it fails.
>
> Show me that this can be triggered by a legitimate object file and then I
> would consider it. Otherwise, you are chasing made up bugs.

I cannot, so I am withdrawing it.

The only way I reached that strcmp() was by writing 0x7ffffff0 into sh_name
myself. I have no case where a compiler, assembler or linker produces an
object whose sh_name points outside the name table, and I could not construct
one from a truncated or interrupted build either -- a short .o fails earlier
and differently. Without that, this is a check against a file that cannot get
there, which is the "made up bug" you are describing.

Please drop it. The same applies to the sorttable patch I sent alongside it
(same shape, same hand-edited reproducer); I am withdrawing that one too and
have said so in the cover-letter thread.

For what it is worth, the one thing in this round that does not depend on a
corrupt file is the undefined shift on e_type, which you were fine with, so I
am sending only that as v2 and nothing else.