Re: [PATCH bpf-next v2 2/7] bpf: Factor out raw_mode-related fields in bpf_call_arg_meta

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] `bpf_map_peek_elem` reads uninitialized stack memory when used with `BPF_MAP_TYPE_BLOOM_FILTER`, causing a kernel stack information leak.
--

--- Patch [2]: [PATCH bpf-next v2 2/7] bpf: Factor out raw_mode-related fields in bpf_call_arg_meta ---
commit b67be9cc9af835cbe1e71cd21cd41e24382f1240
Author: Amery Hung <ameryhung@gmail.com>

bpf: Factor out raw_mode-related fields in bpf_call_arg_meta

This patch groups scattered MEM_UNINIT memory argument fields into a new
struct arg_raw_mem_desc. It identifies raw arguments upfront in
check_raw_mode_ok(), matching them by register number in
check_stack_range_initialized() to eliminate the separate raw_mode flag.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 7dd961ede88df..1a41f99a9133c 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c

[ ... ]

> @@ -7727,7 +7725,13 @@ static bool arg_type_is_mem_size(enum bpf_arg_type type)
>  
>  static bool arg_type_is_raw_mem(enum bpf_arg_type type)
>  {
> -	return base_type(type) == ARG_PTR_TO_MEM &&
> +	/*
> +	 * A map value output buffer (e.g. bpf_map_pop_elem) is also a raw
> +	 * (uninitialized) memory argument, and like ARG_PTR_TO_MEM it may be
> +	 * passed as a PTR_TO_STACK that reaches check_stack_range_initialized().
> +	 */
> +	return (base_type(type) == ARG_PTR_TO_MEM ||
> +		base_type(type) == ARG_PTR_TO_MAP_VALUE) &&
>  	       type & MEM_UNINIT;
>  }

[Severity: Critical]
This is a pre-existing issue, but does treating ARG_PTR_TO_MAP_VALUE as
uninitialized memory expose a stack information leak when used with
bpf_map_peek_elem() and Bloom filters?

The verifier prototype bpf_map_peek_elem_proto specifies MEM_UNINIT | MEM_WRITE,
which assumes the map operation acts as an output buffer and will initialize
the memory.

However, when called on a BPF_MAP_TYPE_BLOOM_FILTER, bloom_map_peek_elem()
uses the buffer strictly as an input to compute a hash without writing to it:

kernel/bpf/bloom_filter.c:bloom_map_peek_elem() {
    ...
    for (i = 0; i < bloom->nr_hash_funcs; i++) {
        h = hash(bloom, value, map->value_size, i);
        if (!test_bit(h, bloom->bitset))
            return -ENOENT;
    }
    ...
}

Since the map never initializes the buffer, but the verifier believes it
does, could a BPF program use this to read uninitialized kernel stack memory?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260715064047.1793790-1-ameryhung@gmail.com?part=2