Medium [CVE-2026-74354] Take mmap_lock in zap_pages

In the Linux kernel, the following vulnerability has been resolved: bpf: Take mmap_lock in zap_pages() zap_vma_range() requires the owning mm's mmap_lock to be held. Taking mmap_read_lock under arena->lock would AB-BA against arena_vm_close() and arena_map_mmap(), both of which run with mmap_write_lock held and then acquire arena->lock.

Instead drop arena->lock, mmget_not_zero() the vma's mm, take mmap_read_lock, and re-resolve the vma via find_vma() since it may have been unmapped or replaced while waiting.

Track processed vmls with a per-call generation in vml->zap_gen and serialize zap_pages() callers with a new arena->zap_mutex so concurrent callers on different uaddr ranges do not mark each other's vmls processed before the zap is done. A flaw was found in the Linux kernel's Berkeley Packet Filter (BPF) subsystem.

A local attacker could exploit a locking issue within the `zap_pages()` function. This vulnerability arises because `zap_vma_range()` requires a specific memory map lock (`mmap_lock`) that, when acquired under certain conditions, can lead to a deadlock.

This deadlock can cause the system to become unresponsive, resulting in a Denial of Service (DoS). Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).

Weakness: CWE-833. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9.