Thank you for your contribution! Sashiko AI review found 1 potential issue(s) 
to consider:
- [Medium] scripts: gen_lineinfo: integer overflow in relocation bounds check 
allows OOB access
--

commit 39f395f93fb90faf7a6d102ff862dc9fb6013c84
Author: Sasha Levin <[email protected]>

kallsyms: extend lineinfo to loadable modules

This commit adds CONFIG_KALLSYMS_LINEINFO_MODULES to extend the lineinfo
feature to loadable kernel modules. It post-processes each .ko file at
build time to embed binary tables containing section-relative offsets,
file IDs, line numbers, and filenames.

> diff --git a/scripts/gen_lineinfo.c b/scripts/gen_lineinfo.c
> --- a/scripts/gen_lineinfo.c
> +++ b/scripts/gen_lineinfo.c
[ ... ]
> +static void apply_one_debug_reloc(Elf_Data *dl_data, Elf_Data *sym_data,
> +                               bool target_le, const GElf_Ehdr *ehdr,
> +                               unsigned int abs32_type,
> +                               unsigned int abs64_type, GElf_Xword r_info,
> +                               GElf_Addr r_offset, GElf_Sxword addend,
> +                               bool has_addend, bool bias)
> +{
[ ... ]
> +     if (arith_width) {
> +             uint64_t cur;
> +
> +             if (r_offset + arith_width > dl_data->d_size)
> +                     return;

[Severity: Medium]
Could an integer overflow occur here? If a malformed ELF relocation
has an r_offset near UINT64_MAX, r_offset + arith_width could wrap around
to a small value and incorrectly pass this bounds check.

Since the tool subsequently does pointer arithmetic using r_offset:
(unsigned char *)dl_data->d_buf + r_offset

Would this allow an out-of-bounds read and write on the section buffer?

> +             /*
> +              * A delta, not an address: the section bias would appear in
> +              * the ADD and cancel in the matching SUB, so leave it out.
> +              */
> +             cur = elf_read_uint((unsigned char *)dl_data->d_buf + r_offset,
> +                                 arith_width, target_le);
> +             value = (uint64_t)(sym.st_value + addend);
> +             cur = is_sub ? cur - value : cur + value;
> +             elf_write_uint((unsigned char *)dl_data->d_buf + r_offset,
> +                            cur, arith_width, target_le);
> +             return;
> +     }
> +
> +     width = is_abs64 ? 8 : 4;
> +
> +     if (r_offset + width > dl_data->d_size)
> +             return;

[Severity: Medium]
Similarly, can r_offset + width overflow here? A crafted .ko or .o file
might bypass this validation due to wrapping, leading to the same
out-of-bounds access on the dl_data->d_buf buffer further down.

-- 
Sashiko AI review ยท 
https://sashiko.dev/#/patchset/[email protected]?part=2

Reply via email to