Re: [PATCH bpf-next v1 1/2] bpf: Disable raw mdoe for bloom filter map_peek

["Kumar Kartikeya Dwivedi" <memxor@gmail.com>]

On Wed Jul 15, 2026 at 7:38 PM CEST, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] bpf_map_pop_elem() and bpf_map_peek_elem() leak uninitialized kernel stack memory on queue and stack maps if the map's spinlock is contended.
> --
>
> --- Patch [1]: [PATCH bpf-next v1 1/2] bpf: Disable raw mdoe for bloom filter map_peek ---
> commit 89de02f623877f9e477f4639136b8a23b2fbbd7c
> Author: Amery Hung <ameryhung@gmail.com>
>
> bpf: Disable raw mdoe for bloom filter map_peek
>
> This commit prevents an information leak by disabling raw mode for
> bpf_map_peek_elem() when used with a bloom filter. It notes that unlike
> queue or stack maps, bloom filters use the value buffer as an input and
> do not fill it.
>
>> bpf: Disable raw mdoe for bloom filter map_peek
>
> [Severity: Low]
> This isn't a bug, but there is a typo (mdoe) in the commit subject line.
>
>> bpf_map_peek_elem() tags its value argument ARG_PTR_TO_MAP_VALUE |
>> MEM_UNINIT, telling the verifier the callee fills the buffer. This holds
>> for queue/stack maps, but not for a bloom filter, which reads the buffer
>> as an input to test set membership and never writes it.
>
> [Severity: High]
> This is a pre-existing issue and was not introduced by this patch, but
> since the commit message mentions that the MEM_UNINIT assumption holds for
> queue and stack maps, does it hold true if the map's spinlock is contended?
>
> Looking at __queue_map_get() in kernel/bpf/queue_stack_maps.c:
>
> 	if (raw_res_spin_lock_irqsave(&qs->lock, flags))
> 		return -EBUSY;
>
> And similarly in __stack_map_get():
>
> 	if (raw_res_spin_lock_irqsave(&qs->lock, flags))
> 		return -EBUSY;
>

We should probably do memset(value, 0, qs->map.value_size) like the case below
in the branch returning -EBUSY.

> If the lock fails (e.g. due to deadlock detection), these functions return
> -EBUSY immediately without zero-initializing the output memory. Since the
> verifier assumes the buffer is initialized due to the MEM_UNINIT tag, could
> a BPF program read uninitialized kernel stack memory if bpf_map_pop_elem()
> or bpf_map_peek_elem() is called on a queue or stack map and hits this
> contention path?