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 <[email protected]>
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/[email protected]?part=1

Reply via email to