Re: [PATCH v8 3/4] kallsyms: delta-compress lineinfo tables for ~2.7x size reduction

Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:
- [Medium] Missing alignment validation for inner offsets `blocks_offset` a=
nd `files_offset` from the module lineinfo header, risking fatal alignment =
traps.
--

--- Patch [3]: [PATCH v8 3/4] kallsyms: delta-compress lineinfo tables for =
~2.7x size reduction ---
commit cc36cd56474b921c9564d160db461d97e0550634
Author: Sasha Levin <[email protected]>

kallsyms: delta-compress lineinfo tables for ~2.7x size reduction

This commit replaces the flat uncompressed parallel arrays in kallsyms
lineinfo with a block-indexed, delta-encoded, ULEB128 varint compressed
format to significantly reduce the memory footprint.

> diff --git a/kernel/module/kallsyms.c b/kernel/module/kallsyms.c
> --- a/kernel/module/kallsyms.c
> +++ b/kernel/module/kallsyms.c

[ ... ]

> @@ -540,80 +535,63 @@ static bool module_lookup_lineinfo_section(const vo=
id *blob, u32 blob_size,
>  		return false;
> =20
>  	base =3D (const u8 *)blob + hdr_offset;
> -	hdr =3D (const struct mod_lineinfo_header *)base;
> -	num_entries =3D hdr->num_entries;
> -	num_files =3D hdr->num_files;
> -	filenames_size =3D hdr->filenames_size;
> +	hdr =3D base;
> =20
> -	if (num_entries =3D=3D 0)
> +	if (hdr->num_entries =3D=3D 0 || hdr->num_blocks =3D=3D 0)
>  		return false;
> =20
> -	/*
> -	 * Validate counts before multiplying =E2=80=94 sizing arithmetic could
> -	 * otherwise overflow on 32-bit with a malformed blob.  Each entry
> -	 * contributes one u32 (addrs), one u16 (file_ids), and one u32
> -	 * (lines); each file contributes one u32 (file_offsets).
> -	 */
>  	/* Validate each sub-array fits within the remaining blob bytes */
>  	{
>  		u32 avail =3D blob_size - hdr_offset;
> -		u32 needed =3D mod_lineinfo_filenames_off(num_entries, num_files);
> =20
> -		if (num_entries > U32_MAX / sizeof(u32))
> +		if (hdr->blocks_offset > avail ||
> +		    hdr->blocks_size > avail - hdr->blocks_offset)
> +			return false;
> +		if (hdr->data_offset > avail ||
> +		    hdr->data_size > avail - hdr->data_offset)
>  			return false;
> -		if (num_files > U32_MAX / sizeof(u32))
> +		if (hdr->files_offset > avail ||
> +		    hdr->files_size > avail - hdr->files_offset)
>  			return false;
> -		if (needed > avail || filenames_size > avail - needed)
> +		if (hdr->filenames_offset > avail ||
> +		    hdr->filenames_size > avail - hdr->filenames_offset)
>  			return false;
>  	}

[Severity: Medium]
Could these inner offsets (like hdr->blocks_offset and hdr->files_offset)
be unaligned in a malformed blob?

The code validates the bounds correctly here, but misses an alignment check
before these offsets are later added to the base pointer and assigned to
the u32 arrays.

If the offsets are not multiples of 4, wouldn't dereferencing tbl.blk_addrs
or tbl.file_offsets trigger an alignment exception on strict-alignment
architectures? If this happens during an NMI or panic, it seems like it
could cause a recursive fault and permanently lose the backtrace.

[ ... ]

> +	tbl.blk_addrs	=3D base + hdr->blocks_offset;
> +	tbl.blk_offsets	=3D base + hdr->blocks_offset +
> +			  hdr->num_blocks * sizeof(u32);
> +	tbl.data	=3D base + hdr->data_offset;
> +	tbl.data_size	=3D hdr->data_size;
> +	tbl.file_offsets =3D base + hdr->files_offset;
> +	tbl.filenames	=3D base + hdr->filenames_offset;
> +	tbl.num_entries	=3D hdr->num_entries;
> +	tbl.num_blocks	=3D hdr->num_blocks;
> +	tbl.num_files	=3D hdr->num_files;
> +	tbl.filenames_size =3D hdr->filenames_size;
> +
> +	return lineinfo_search(&tbl, section_offset, min_offset, file, line);
>  }

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260801143219.3975=
[email protected]?part=3D3