On Sun, 18 Oct 2026 19:04:19 -0500
Leizhen Zhang [off-list ref] 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 <redacted>
---
scripts/tracepoint-update.c | 5 +++++