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

[Ihor Solodrai <ihor.solodrai@linux.dev>]

On 6/15/26 1:12 PM, sashiko-bot@kernel.org wrote:
> 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.
> 

This was raised in v1, ignoring as it's not relevant to the patch.