CVE-2026-45837

What it actually does

This is a Linux kernel use-after-free in the eBPF arena memory-management path. When an arena-backed VMA is inherited across fork or manipulated through certain mremap behavior, internal arena metadata can continue pointing to the original parent VMA after it has been unmapped. A child process can then trigger bpf_arena_free_pages(), causing the kernel to dereference stale VMA state in zap_pages(). Because this occurs in kernel memory-management code, successful exploitation can plausibly lead to local privilege escalation, kernel memory corruption, information disclosure, or denial of service. Exploitation requires local code execution and privileges sufficient to use the affected BPF arena functionality, which may be restricted by kernel BPF hardening settings.

Why it matters to the business

A local user or compromised workload on an affected Linux system could potentially turn limited access into full control of the host or crash the system. This is most concerning for multi-user Linux servers, container hosts, CI/CD runners, developer workstations, and shared compute platforms where untrusted or semi-trusted users can run code. The vulnerability is not listed in CISA KEV and has low EPSS at this time, suggesting no confirmed widespread exploitation, but kernel local privilege-escalation flaws should still be prioritized because they are commonly chained after initial access.

How an attack unfolds

An attacker first needs the ability to run code locally on an affected Linux kernel and to access the BPF arena functionality. They create an eBPF arena mapping, fork a child process so the arena VMA state is inherited incorrectly, and then arrange for the parent mapping to be unmapped so the arena metadata retains a dangling pointer to freed VMA memory. The child then calls functionality such as bpf_arena_free_pages(), which reaches zap_pages() and causes the kernel to use the stale VMA pointer. With a reliable memory-corruption primitive, an attacker may attempt to shape kernel heap state and redirect the corruption toward privilege escalation; a less reliable attempt may simply trigger a kernel oops or panic. A related mremap(MREMAP_FIXED) path is also addressed by the fix to prevent unsafe VMA copying/rollback behavior.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the BPF arena VMA lifecycle issue. The fix prevents arena VMAs from being inherited across fork by using VM_DONTCOPY, prevents unsafe VMA splits via a may_split callback, and rejects unsafe mremap behavior with -EINVAL. If an immediate kernel upgrade is not possible, reduce exposure by disabling unprivileged BPF where operationally feasible, restricting local shell access, limiting who can run workloads on shared hosts, applying container hardening, and enforcing least privilege for CAP_BPF, CAP_SYS_ADMIN, and related capabilities. Reboot into the fixed kernel after patching; merely installing kernel packages without booting the patched kernel does not remediate runtime exposure.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, contains the vendor backport or upstream fix. Validate with `uname -r`, distribution package metadata, and the vendor security advisory for this CVE. Check whether unprivileged BPF is disabled with `/proc/sys/kernel/unprivileged_bpf_disabled` where applicable, and review container/runtime capability policies for CAP_BPF and CAP_SYS_ADMIN. If source or symbol validation is available, confirm the BPF arena VMA handling includes VM_DONTCOPY, rejects mremap for the arena VMA, and prevents splitting. After patching, reboot and verify the active kernel version has changed to the fixed build.

Typical attack path

1. Obtain local code execution on a Linux system running an affected kernel.
2. Verify that BPF arena functionality is available and not blocked by local BPF restrictions.
3. Create an eBPF arena-backed memory mapping.
4. Fork a child process so arena VMA state is inherited in an unsafe way.
5. Unmap the arena VMA in the parent process, leaving child-side arena metadata referencing stale VMA memory.
6. Invoke bpf_arena_free_pages() or related arena page-freeing behavior from the child process.
7. Trigger kernel use-after-free in the arena/zap_pages path.
8. Attempt to convert kernel memory corruption into privilege escalation, kernel information disclosure, or denial of service.

How to detect it

Detection should focus on signs of attempted kernel memory corruption and suspicious BPF use because this vulnerability does not produce a unique, reliable network indicator. Review kernel logs from journald, dmesg, syslog, crash dumps, and KASAN/KFENCE reports for use-after-free, general protection faults, BUG/Oops messages, or panics referencing BPF arena functions such as arena_vm_close, arena_vm_open, bpf_arena_free_pages, zap_pages, mremap, munmap, or VMA handling. Review auditd or eBPF telemetry, if enabled, for local processes making bpf() syscalls, creating BPF maps/programs, then rapidly using fork(), munmap(), and mremap(MREMAP_FIXED). Investigate unexpected privilege changes shortly after BPF activity, such as non-root users spawning root shells, writing to privileged paths, loading kernel-facing tools, or causing repeated kernel instability. In container environments, correlate privileged containers or workloads with CAP_BPF/CAP_SYS_ADMIN use and host kernel crashes. Absence of these artifacts does not prove non-exploitation because a successful local privilege escalation may leave minimal traces if kernel logging is not persistent.

• BUG: KASAN: use-after-free
• KASAN: use-after-free in bpf_arena_free_pages
• KASAN: use-after-free in zap_pages
• BUG: kernel NULL pointer dereference
• general protection fault
• kernel BUG at
• Oops:
• arena_vm_close
• arena_vm_open
• bpf_arena_free_pages
• zap_pages
• mremap(MREMAP_FIXED)
• MREMAP_FIXED
• vm_area_dup
• copy_vma
• bpf(BPF_MAP_CREATE
• BPF_MAP_TYPE_ARENA
• /proc/sys/kernel/unprivileged_bpf_disabled

What your security team should do

• Inventory Linux systems and prioritize shared, multi-tenant, container-host, CI/CD, and internet-facing systems where post-compromise privilege escalation would have high impact.
• Patch and reboot affected systems to a kernel build containing the BPF arena use-after-free fix.
• Until patching is complete, disable unprivileged BPF where feasible and restrict CAP_BPF, CAP_SYS_ADMIN, and privileged container execution.
• Hunt for kernel crashes, KASAN reports, oops messages, or audit events involving BPF arena activity, fork, munmap, mremap, and suspicious local privilege-escalation behavior.
• Treat exploitation suspicion as host compromise: preserve volatile evidence, collect kernel logs and audit logs, isolate the host if needed, and rotate credentials or secrets accessible from the system.
• Monitor vendor advisories for exact fixed package versions, because many Linux distributions backport kernel fixes without changing to the upstream kernel version that originally introduced the patch.