Re: [PATCH v3 bpf-next 1/1] 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:
- [High] Missing D-cache flush when lazily populating userspace mappings of vmalloc'ed memory, causing potential stale data disclosure.
--

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

bpf: Populate mmap-able array map memory lazily

This commit changes BPF array maps with BPF_F_MMAPABLE to map memory lazily.
It replaces the eager remap_vmalloc_range() call with custom fault handlers
that populate PTEs on demand to improve mmap performance for large maps.

> diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
> index 248b4818178cd..3594e26b9fb88 100644
> --- a/kernel/bpf/arraymap.c
> +++ b/kernel/bpf/arraymap.c

[ ... ]

> @@ -576,17 +577,118 @@ static int array_map_check_btf(struct bpf_map *map,
> +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);
> +	struct page *page;
> +
> +	page = array_map_fault_page(array, vmf->pgoff);
> +	if (!page)
> +		return VM_FAULT_SIGBUS;
> +
> +	get_page(page);
> +	vmf->page = page;
> +

[Severity: High]
Does this fault handler need to explicitly flush the D-cache for the resolved
vmalloc page?

Previously, the eager mapping used remap_vmalloc_range_partial() which calls
vm_insert_page(), and vm_insert_page() explicitly calls flush_dcache_folio().
By returning the page directly to the fault handler without a D-cache flush,
can architectures with aliasing D-caches expose uninitialized physical memory
to userspace, bypassing the kernel's cached writes?

> +	return 0;
> +}

[ ... ]

> +static vm_fault_t array_map_mmap_pages(struct bpf_map *map, struct vm_fault *vmf,
> +				       pgoff_t start_pgoff, pgoff_t end_pgoff)
> +{

[ ... ]

> +	for (pgoff = start_pgoff; pgoff <= end_pgoff;
> +	     pgoff++, vmf->pte++, addr += PAGE_SIZE) {
> +		struct folio *folio;
> +		struct page *page;
> +
> +		if (!pte_none(ptep_get(vmf->pte)))
> +			continue;
> +
> +		page = array_map_fault_page(array, pgoff);
> +		if (!page)
> +			continue;
> +
> +		folio = page_folio(page);
> +		folio_get(folio);

[Severity: High]
Similarly, in this fault-around handler, is a flush_dcache_folio() call
needed before installing the PTE?

Calling set_pte_range() directly bypasses the D-cache flush that
vm_insert_page() would have provided, which might result in userspace
reading stale physical RAM contents on architectures with VIVT or VIPT
aliasing D-caches.

> +		set_pte_range(vmf, folio, page, 1, addr);
> +		rss++;
> +		if (addr == vmf->address)
> +			ret = VM_FAULT_NOPAGE;
> +	}

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