Re: [PATCH v9 1/4] kallsyms: embed source file:line info in kernel stack traces

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] scripts: division by zero in find_vmlinux_sym() due to missing sh_entsize check
- [Low] scripts: memory leak of dynamically allocated arrays at exit
--

commit 37641e6c997ac852eedac002b430b40b946dc18d
Author: Sasha Levin <sashal@kernel.org>
Subject: kallsyms: embed source file:line info in kernel stack traces

This commit adds CONFIG_KALLSYMS_LINEINFO, which embeds DWARF-derived
address-to-line mappings directly into the kernel image. A new host tool
(scripts/gen_lineinfo) extracts this info from vmlinux using libdw. The
stack traces will then directly print file and line numbers.

> diff --git a/scripts/gen_lineinfo.c b/scripts/gen_lineinfo.c
> new file mode 100644
> --- /dev/null
> +++ b/scripts/gen_lineinfo.c

[ ... ]

> +static unsigned long long find_vmlinux_sym(Elf *elf, const char *name,
> +					   unsigned long long fallback,
> +					   bool required)
> +{
> +	size_t nsyms, i;
> +	Elf_Scn *scn = NULL;
> +	GElf_Shdr shdr;
> +
> +	while ((scn = elf_nextscn(elf, scn)) != NULL) {
> +		Elf_Data *data;
> +
> +		if (!gelf_getshdr(scn, &shdr))
> +			continue;
> +		if (shdr.sh_type != SHT_SYMTAB)
> +			continue;
> +
> +		data = elf_getdata(scn, NULL);
> +		if (!data)
> +			continue;
> +
> +		nsyms = shdr.sh_size / shdr.sh_entsize;

[Severity: Low]
Can this division cause a crash if a malformed ELF file is encountered?

If the vmlinux ELF file is malformed and contains an SHT_SYMTAB section
where shdr.sh_entsize is zero, this will result in a division by zero and
a SIGFPE crash. Other functions in this file, such as
collect_symbol_starts(), appear to validate !shdr.sh_entsize before
performing this division. Should this loop skip sections with a zero
sh_entsize as well?

[ ... ]

> +int main(int argc, char *argv[])
> +{

[ ... ]

> +	/* Cleanup */
> +	free(entries);
> +	free(sym_starts);
> +	free(seq_ends);
> +	for (unsigned int i = 0; i < num_files; i++)
> +		free(files[i]);
> +	free(files);
> +
> +	return 0;
> +}

[Severity: Low]
Does this cleanup block miss some dynamically allocated arrays?

The main() function allocates text_starts, asm_spans, and cu_row_seq_end
during execution, but omits freeing them here. While the OS reclaims memory
upon process exit (making the leak relatively harmless for a short-lived
build tool), the presence of a dedicated cleanup block implies an intent to
achieve a clean memory leak check. Could text_starts, asm_spans, and
cu_row_seq_end be added to this cleanup section?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260917133727.428546-1-sashal@kernel.org?part=1