Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] Division by zero when parsing ELF symbol table sections if `sh_entsize` is maliciously or erroneously set to 0. --
commit df03e392d8f5364e6eef1e60fcadca00e2b031f8 Author: Alan Maguire <[email protected]> resolve_btfids: Extract inline BTF This commit adds an --inline option to extract LOC_PARAM, LOC_PROTO and LOCSEC types to a new inline split .BTF.inline while sorting BTF. > diff --git a/tools/bpf/resolve_btfids/main.c b/tools/bpf/resolve_btfids/main.c > index 37d7e7224207d..20b228c4d6789 100644 > --- a/tools/bpf/resolve_btfids/main.c > +++ b/tools/bpf/resolve_btfids/main.c [ ... ] > @@ -572,6 +578,58 @@ static const char *find_name_by_addr(struct object *obj, > Elf64_Addr addr) [ ... ] > +static int collect_func_symbols(struct object *obj) > +{ > + Elf_Scn *scn; > + GElf_Shdr sh; > + int n, i; > + > + if (obj->efile.symbols_shndx == -1) > + return 0; > + > + scn = elf_getscn(obj->efile.elf, obj->efile.symbols_shndx); > + if (!scn || gelf_getshdr(scn, &sh) != &sh) > + return -EINVAL; > + n = sh.sh_size / sh.sh_entsize; [Severity: Medium] Could this result in a division by zero if a malformed ELF object is provided to the build system? If sh.sh_entsize is 0, this will trigger a SIGFPE and crash the resolve_btfids tool. While this vulnerable pattern already exists in symbols_collect(), it appears to be newly introduced here in collect_func_symbols(). Should there be a check to ensure sh.sh_entsize is non-zero before performing the division? > + > + for (i = 0; i < n; i++) { > + GElf_Sym sym; > + const char *name; [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=12
