Re: [PATCH bpf] bpf: harden bloom filter allocation sizing on 32-bit kernels

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] The patch prevents a 0-byte allocation on 32-bit architectures, but fails to address a critical out-of-bounds access bug caused by negative indexing when `bitset_mask == U32_MAX`.
--

--- Patch [1]: [PATCH bpf] bpf: harden bloom filter allocation sizing on 32-bit kernels ---
commit 02e5a6622a3bf43a5a551fa2588059c5317afd7d
Author: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>

bpf: harden bloom filter allocation sizing on 32-bit kernels

This commit addresses an under-allocation issue for bloom filter maps on
32-bit kernels by computing the required bitset size using u64 arithmetic,
preventing an integer overflow during allocation.

> --- a/kernel/bpf/bloom_filter.c
> +++ b/kernel/bpf/bloom_filter.c
> @@ -127,23 +128,21 @@ static struct bpf_map *bloom_map_alloc(union bpf_attr *attr)
>  	if (check_mul_overflow(attr->max_entries, nr_hash_funcs, &nr_bits) ||
>  	    check_mul_overflow(nr_bits / 5, (u32)7, &nr_bits) ||
>  	    nr_bits > (1UL << 31)) {
> -		/* The bit array size is 2^32 bits but to avoid overflowing the
> -		 * u32, we use U32_MAX, which will round up to the equivalent
> -		 * number of bytes
> -		 */
> -		bitset_bytes = BITS_TO_BYTES(U32_MAX);
>  		bitset_mask = U32_MAX;

[Severity: Critical]
This is a pre-existing issue, but does setting bitset_mask to U32_MAX leave
the map vulnerable to backward out-of-bounds accesses on 32-bit architectures?

When the map is accessed, the generated u32 hash is masked and passed to
test_bit() and set_bit():

kernel/bpf/bloom_filter.c:bloom_map_peek_elem() {
    ...
    if (!test_bit(h, bloom->bitset))
        return -ENOENT;
    ...
}

kernel/bpf/bloom_filter.c:bloom_map_push_elem() {
    ...
    set_bit(h, bloom->bitset);
    ...
}

On 32-bit systems, test_bit() and set_bit() expect a signed long index.
If the u32 hash value is greater than or equal to 0x80000000, it is
implicitly converted to a negative bit offset.

Because some architectures handle this as a signed offset relative to the
memory base, could this result in reading or writing memory before the
allocated bloom->bitset buffer and corrupting the bpf_bloom_filter struct?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260731204917.3845309-1-Jeremy.Jean@oss.cyber.gouv.fr?part=1