Re: [PATCH v2 2/3] kallsyms: Add dynamic lookup index for batch resolution

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] kallsyms: use-after-free on dyn_kallsyms_offsets in lookup paths
- [Low] kallsyms: undeclared get_symbol_data() causes build failure
--

commit ab1fc0aa56a3930399c450aad78232a641c6e73f
Author: Jim Cromie <jim.cromie@gmail.com>
kallsyms: Add dynamic lookup index for batch resolution

This commit introduces a dynamically allocated lookup index for kallsyms to
accelerate batch symbol resolution. The index is built on-demand in transient
RAM and freed when the batch concludes, falling back to a linear scan
otherwise.

> diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
> index b9e573e9a10b9..862a6b773ac5e 100644
> --- a/kernel/kallsyms.c
> +++ b/kernel/kallsyms.c

[ ... ]

> +static u32 *kallsyms_build_offsets(void)
> +{
> +	const u8 *name = kallsyms_names;
> +	u32 *offsets;
> +	unsigned int i;
> +
> +	offsets = kvmalloc_array(kallsyms_num_syms, sizeof(u32), GFP_KERNEL);
> +	if (!offsets)
> +		return NULL;
> +
> +	for (i = 0; i < kallsyms_num_syms; i++) {
> +		unsigned int len;
> +		const u8 *data;
> +
> +		offsets[i] = name - kallsyms_names;
> +		data = get_symbol_data(offsets[i], &len);

[Severity: Low]
Does this cause a build failure? I noticed that get_symbol_data() does not
seem to be declared or defined in the codebase at this commit. Even if it is
introduced in a later patch in the series, each commit should compile
independently to preserve git bisectability.

> +		name = data + len;
> +	}
> +
> +	return offsets;
> +}

[ ... ]

> +/*
> + * Find the offset on the compressed table given an index in the
> + * kallsyms array.
> + */
> +static inline unsigned int get_symbol_offset(unsigned long pos)
> +{
> +	u32 *offsets = rcu_dereference_raw(dyn_kallsyms_offsets);
> +
> +	if (offsets)
> +		return offsets[pos];

[Severity: High]
Could this lead to a use-after-free when kallsyms_lookup_batch_end() tears
down the batch?

Because rcu_dereference_raw() is used here, static analysis and lockdep 
cannot verify whether rcu_read_lock() is held. Readers like the 
/proc/kallsyms seq_file iterators (e.g., reset_iter()) or exported APIs 
(like lookup_symbol_name() or kallsyms_lookup_buildid()) can call this 
function in preemptible contexts without RCU protection. 

If a reader is preempted after dereferencing the pointer but before
accessing the array element, and another thread completes 
kallsyms_lookup_batch_end(), synchronize_rcu() will not wait for the 
preempted reader, which will then access the freed array.

> +
> +	return get_symbol_offset_marker(pos);
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260922-ksyms-tune-v2-0-a333ee31eac7@gmail.com?part=2