Re: [PATCH v2 14/40] bpf: arena: mark arena_map_mmap() mappings VM_MIXEDMAP
From: sashiko-bot@kernel.org
Date: 2026-09-14 18:46:15
Also in:
bpf, dri-devel, kvm, kvmarm, linux-rdma, linux-s390, linux-scsi, linux-trace-kernel, selinux
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: Pre-existing issues: - [High] VMA traversal on an external `mm_struct` in `zap_pages` without verifying if the address space is stable. -- commit cbf53175992b654249c64afadb9a535e0ca6aecd Author: Lorenzo Stoakes (ARM) [off-list ref] bpf: arena: mark arena_map_mmap() mappings VM_MIXEDMAP The bpf_map->ops->map_mmap callback invoked by bpf_map_mmap() can be set to one of ringbuf_map_mmap_kern(), ringbuf_map_mmap_user(), array_map_mmap() or arena_map_mmap(). [ ... ]
quoted hunk ↗ jump to hunk
diff --git a/kernel/bpf/arena.c b/kernel/bpf/arena.c index 7b6847200b431..b69fe5e343393 100644 --- a/kernel/bpf/arena.c +++ b/kernel/bpf/arena.c@@ -620,8 +620,9 @@ static int arena_map_mmap(struct bpf_map *map, struct vm_area_struct *vma) * clears VM_MAYEXEC. Set VM_DONTEXPAND to avoid potential change * of user_vm_start. Set VM_DONTCOPY to prevent arena VMA from * being copied into the child process on fork. + * This is a kernel page so set VM_MIXEDMAP. */ - vm_flags_set(vma, VM_DONTEXPAND | VM_DONTCOPY); + vm_flags_set(vma, VM_MIXEDMAP | VM_DONTEXPAND | VM_DONTCOPY); vma->vm_ops = &arena_vm_ops; return 0; }
[Severity: High] This is a pre-existing issue, but does zap_pages() traverse the maple tree of an external mm without verifying if the address space is stable? kernel/bpf/arena.c:zap_pages() mmap_read_lock(mm); /* * Re-resolve: while we waited the VMA could have been unmapped * and a different mapping installed at the same address. */ vma = find_vma(mm, vm_start); If a BPF program frees arena pages, triggering zap_pages(), it iterates over the mm_struct of every process that mapped the arena and calls find_vma(mm, vm_start). If one of those processes concurrently failed dup_mmap() during fork() or was reaped by the OOM killer, its address space is marked MMF_UNSTABLE and its maple tree is in an inconsistent state. Can traversing an unstable maple tree here cause a kernel panic when find_vma() encounters XA_ZERO_ENTRY markers or incomplete tree state? Should this path call check_stable_address_space(mm) before traversing? -- Sashiko AI review · https://sashiko.dev/#/patchset/20260914-b4-mmap-prepare-vma-flag-sanify-v2-0-7d9781ed5361@kernel.org?part=14