Re: [PATCH v9 2/4] kallsyms: extend lineinfo to loadable modules

[sashiko-bot@kernel.org]

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 <sashal@kernel.org>

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/20260917133727.428546-1-sashal@kernel.org?part=2