Re: [PATCH bpf-next 1/2] bpf: Populate mmap-able array map memory lazily

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] An integer overflow in `array_map_mmap` on 32-bit architectures allows bypassing the VMA bounds check. Combined with pointer arithmetic truncation in the new `array_map_mmap_fault` handler, an attacker can map the `struct bpf_array` header into user space, leading to Local Privilege Escalation (LPE) by overwriting the BPF map's operations pointer.
--

--- Patch [1]: [PATCH bpf-next 1/2] bpf: Populate mmap-able array map memory lazily ---
commit 07e8d5ac0a564f432fdda75a2eb43f2790e3860c
Author: Song Liu <song@kernel.org>

bpf: Populate mmap-able array map memory lazily

This commit modifies mmap-able BPF array maps to populate memory lazily
rather than upfront at map creation time. It adds a new map_mmap_fault
callback to handle inserting pages on demand, reducing the mmap and
munmap complexity to O(1) for large maps.

> diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
> --- a/kernel/bpf/arraymap.c
> +++ b/kernel/bpf/arraymap.c
> @@ -576,7 +576,6 @@ static int array_map_check_btf(struct bpf_map *map,
>  static int array_map_mmap(struct bpf_map *map, struct vm_area_struct *vma)
>  {
>  	struct bpf_array *array = container_of(map, struct bpf_array, map);
> -	pgoff_t pgoff = PAGE_ALIGN(sizeof(*array)) >> PAGE_SHIFT;
>  
>  	if (!(map->map_flags & BPF_F_MMAPABLE))
>  		return -EINVAL;
> @@ -585,8 +584,42 @@ static int array_map_mmap(struct bpf_map *map, struct vm_area_struct *vma)
>  	    PAGE_ALIGN((u64)array->map.max_entries * array->elem_size))
>  		return -EINVAL;

[Severity: Critical]
Does this bounds check in array_map_mmap overflow on 32-bit architectures?

Since the left-hand side calculation uses 32-bit unsigned long arithmetic,
could an excessive page offset overflow the result to zero, thereby
bypassing the check entirely?

> -	return remap_vmalloc_range(vma, array_map_vmalloc_addr(array),
> -				   vma->vm_pgoff + pgoff);
> +	/*
> +	 * The backing memory is vmalloc'ed up front, so instead of wiring up
> +	 * every PTE here we let array_map_mmap_fault() insert pages on demand.
> +	 * remap_vmalloc_range_partial() used to set these flags for us; keep
> +	 * them to preserve behavior (no VMA expansion, excluded from coredump).
> +	 */
> +	vm_flags_set(vma, VM_DONTEXPAND | VM_DONTDUMP);
> +
> +	return 0;
> +}
> +
> +static vm_fault_t array_map_mmap_fault(struct bpf_map *map,
> +				       struct vm_fault *vmf)
> +{
> +	struct bpf_array *array = container_of(map, struct bpf_array, map);
> +	pgoff_t pgoff = PAGE_ALIGN(sizeof(*array)) >> PAGE_SHIFT;
> +	struct page *page;
> +	void *kaddr;
> +
> +	/*
> +	 * vmf->pgoff is the page offset within the mapping (vma->vm_pgoff plus
> +	 * the offset of the faulting address). The data pages start after the
> +	 * bpf_array header, hence the extra pgoff. This mirrors the offset that
> +	 * remap_vmalloc_range(vma, ..., vma->vm_pgoff + pgoff) used to apply.
> +	 */
> +	kaddr = array_map_vmalloc_addr(array) +
> +		((u64)(vmf->pgoff + pgoff) << PAGE_SHIFT);

[Severity: Critical]
Can this pointer arithmetic lead to truncation when calculating kaddr?

On 32-bit systems, array_map_vmalloc_addr returns a 32-bit pointer.
If the 64-bit offset calculation is added to this pointer, does it truncate
the upper bits? If an overflowed pgoff was passed from the mmap bounds check,
could this truncation cause the mapping to wrap around and incorrectly
expose the internal bpf_array header memory to user space?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260722065308.4116186-1-song@kernel.org?part=1