Re: [PATCH bpf-next v6 3/3] bpf: Cache build IDs in sleepable stackmap path

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The code incorrectly uses `!vma->vm_file` to determine if a VMA has a backing file instead of using `vma_is_anonymous()`.
--

commit 064bc7134cce521fa9fe6d8d8e8a26a362f8ccdb
Author: Ihor Solodrai <ihor.solodrai@linux.dev>

bpf: Cache build IDs in sleepable stackmap path

This commit adds caching for the last successfully parsed build ID,
VMA range, and backing file in the sleepable stackmap path to avoid
repeated VMA locking and file parsing.

> diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
> --- a/kernel/bpf/stackmap.c
> +++ b/kernel/bpf/stackmap.c
[ ... ]
> @@ -253,6 +261,17 @@ static void stack_map_get_build_id_offset_sleepable(struct bpf_stack_build_id *i
>  	for (u32 i = 0; i < trace_nr; i++) {
>  		ip = READ_ONCE(id_offs[i].ip);
[ ... ]
>  		vma = stack_map_lock_vma(&lock, ip);
>  		if (!vma || !vma->vm_file) {

[Severity: High]
This is a pre-existing issue, but using vma->vm_file as a proxy to check if
a VMA is file-backed or anonymous can be problematic. Anonymous VMAs (like
private mappings of /dev/zero or driver mmaps that call vma_set_anonymous())
can leave vma->vm_file set.

If this code treats such VMAs as standard file-backed VMAs, could
build_id_parse_file() end up invoking kernel_read() on character devices
like TTYs or input devices? 

This might block indefinitely waiting for input, potentially leading to a
local denial of service in a sleepable BPF tracing program.

Should this check use vma_is_anonymous(vma) to accurately classify the VMA
instead of checking !vma->vm_file?

>  			stack_map_build_id_set_ip(&id_offs[i]);
>  			stack_map_unlock_vma(&lock);
>  			continue;
>  		}

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