Re: [PATCH bpf-next v3] bpf: Better build_id caching in stack_map_get_build_id_offset()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The non-sleepable path uses `find_vma()` without verifying if the requested `ip` actually falls within the returned VMA, leading to bogus file offsets and leaking the build ID of adjacent mappings.
--

commit 61bb9d39eaa120b04f78291638b9b3dcc5b364d9
Author: Ihor Solodrai <ihor.solodrai@linux.dev>

bpf: Better build_id caching in stack_map_get_build_id_offset()

This patch refactors the build ID caching logic in
stack_map_get_build_id_offset and its sleepable variant into a shared
structure. It uses two independent slots to cache the last resolved and
unresolved VMAs, avoiding cache eviction when alternating between regions.

Link: https://lore.kernel.org/bpf/20260525223948.1920986-1-ihor.solodrai@linux.dev/
Link: https://lore.kernel.org/bpf/CAEf4Bza2fRDGhLQoPE-EzM7F34xaEJfi5Exmxb-iWVUN3F06=g@mail.gmail.com/
Link: https://lore.kernel.org/bpf/CAEf4BzZXJFr=1iiVx937ht=4PYQkQHg=eFk810zhMDzXQG3ihw@mail.gmail.com/

> diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
> --- a/kernel/bpf/stackmap.c
> +++ b/kernel/bpf/stackmap.c

[ ... ]

> @@ -365,27 +439,30 @@ static void stack_map_get_build_id_offset(struct bpf_stack_build_id *id_offs,
>  
>  	for (i = 0; i < trace_nr; i++) {
>  		u64 ip = READ_ONCE(id_offs[i].ip);
>  
> -		if (prev_build_id && range_in_vma(prev_vma, ip, ip)) {
> -			vma = prev_vma;
> -			offset = stack_map_build_id_offset(vma->vm_pgoff, vma->vm_start, ip);
> -			stack_map_build_id_set_valid(&id_offs[i], offset, prev_build_id);
> +		if (!stack_map_build_id_set_from_cache(&cache, &id_offs[i], ip))
>  			continue;
> -		}
> +
>  		vma = find_vma(current->mm, ip);
>  		if (!vma || vma_is_anonymous(vma) ||
>  		    fetch_build_id(vma, id_offs[i].build_id, may_fault)) {

[Severity: High]
This isn't a bug introduced by this patch, but does the use of find_vma()
here without a bounds check allow an unmapped ip to underflow the offset?

find_vma() returns the first VMA whose vm_end > ip, but it does not
guarantee that ip >= vma->vm_start.

If an unmapped ip is queried, could find_vma() return the next adjacent VMA,
causing the offset calculation ip - vma->vm_start to underflow? This appears
like it would report a bogus file offset and leak the build ID of the
adjacent mapping.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260615195536.1065107-1-ihor.solodrai@linux.dev?part=1