CVE-2026-53032

What it actually does

This is a Linux kernel eBPF verifier flaw that can dereference a NULL pointer while validating BPF map kptr type compatibility. The vulnerable path occurs when a scalar register is handled where the verifier expects BTF-backed pointer metadata; the code calls btf_is_kernel(reg->btf) before confirming the register is a PTR_TO_BTF_ID type. A local user or process able to load crafted eBPF programs can trigger a kernel NULL pointer dereference, causing an oops and potentially a full system crash depending on kernel panic settings such as panic_on_oops.

Why it matters to the business

Successful exploitation can interrupt workloads by crashing affected Linux systems or destabilizing hosts that allow BPF program loading. The risk is highest on multi-user systems, container hosts, CI/build systems, developer workstations, and servers where unprivileged BPF is enabled or where workloads have CAP_BPF, CAP_SYS_ADMIN, or similar privileges. EPSS is currently very low and there is no known KEV listing or ransomware association, but the issue still warrants normal kernel patching because denial-of-service flaws in the kernel can affect service availability.

How an attack unfolds

An attacker first needs local code execution or access to a process/container context that can load eBPF programs. They craft a BPF program and map interaction that causes a scalar register to be stored or checked against a kptr slot, reaching the vulnerable map_kptr_match_type() verifier logic. During verification, the kernel attempts to inspect BTF metadata through reg->btf before confirming the register type actually carries BTF information. Because scalar registers do not have associated BTF metadata, the kernel dereferences NULL. The immediate result is a kernel oops; on systems configured to panic on oops or where the fault destabilizes critical kernel state, this can produce a complete host crash and service outage.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or vendor that includes the upstream fix moving the base_type() != PTR_TO_BTF_ID guard before any access to reg->btf in map_kptr_match_type(). Because no product-specific fixed versions were provided, use vendor advisories for the exact patched kernel package for each distribution. As interim mitigation, disable unprivileged BPF where possible by setting kernel.unprivileged_bpf_disabled=1, restrict CAP_BPF and CAP_SYS_ADMIN from non-essential users and containers, avoid privileged containers unless required, and use seccomp/LSM/container runtime policy to limit bpf() syscall access for untrusted workloads. Consider setting operational policy around panic_on_oops based on availability requirements, recognizing that this changes crash behavior but does not fix the vulnerability.

How to confirm the fix worked

Confirm the running kernel package is at or above the vendor-fixed version and that the active booted kernel, not just the installed package, has been updated. Validate with uname -r, package manager queries, and vendor advisory metadata. Confirm unprivileged BPF is disabled where used as a mitigation by checking sysctl kernel.unprivileged_bpf_disabled. Review container and service configurations for unnecessary CAP_BPF, CAP_SYS_ADMIN, privileged mode, or broad seccomp allowances. If source-level validation is required, verify that map_kptr_match_type() checks the register base type before calling btf_is_kernel() or otherwise dereferencing reg->btf.

Typical attack path

1. Obtain local execution on a Linux host or within a container/process context with permission to load eBPF programs.
2. Verify that BPF program loading is permitted, for example through CAP_BPF, CAP_SYS_ADMIN, privileged container settings, or unprivileged BPF being enabled.
3. Submit a crafted eBPF program/map operation involving kptr handling that causes a scalar register to reach the vulnerable type-matching path.
4. Trigger the vulnerable verifier path in map_kptr_match_type().
5. Cause a kernel NULL pointer dereference, resulting in a kernel oops or system panic.
6. Repeat exploitation to sustain denial of service until the kernel is patched or BPF access is restricted.

How to detect it

To determine whether this was already exploited, review kernel logs and crash artifacts for NULL pointer dereferences in or near map_kptr_match_type(), btf_is_kernel(), BPF verifier code, or bpf_kptr_xchg handling. Relevant sources include journalctl -k, /var/log/kern.log, /var/log/messages, dmesg output, kdump/vmcore records, crash dumps, hypervisor reset logs, and endpoint telemetry that records bpf() syscall use or BPF program loading. Correlate kernel oops or panic timestamps with local process execution, container launches, bpftool invocations, untrusted user sessions, CI jobs, or workloads granted CAP_BPF/CAP_SYS_ADMIN. Look for repeated crashes with similar call traces, failed BPF verifier messages immediately before a crash, or host reboots without normal shutdown records. Absence of these artifacts does not prove non-exploitation, especially if persistent kernel logs or crash dumps are not retained.

• map_kptr_match_type
• btf_is_kernel
• bpf_kptr_xchg
• Unable to handle kernel NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops: 0000
• Kernel panic - not syncing
• panic_on_oops
• BPF:
• bpf:
• verifier
• /var/log/kern.log
• /var/log/messages
• /sys/kernel/debug/tracing
• /proc/sys/kernel/unprivileged_bpf_disabled
• bpftool

What your security team should do

• Prioritize patching Linux systems where untrusted local users, containers, CI jobs, or third-party workloads can execute code.
• Identify hosts that allow BPF program loading by unprivileged users or workloads with CAP_BPF/CAP_SYS_ADMIN and treat them as higher exposure.
• Apply vendor kernel updates and reboot into the fixed kernel; confirm the running kernel version after reboot.
• Disable unprivileged BPF on systems that do not explicitly require it.
• Remove CAP_BPF, CAP_SYS_ADMIN, and privileged container settings from workloads unless there is a documented need.
• Add monitoring for kernel oops/panic events referencing map_kptr_match_type, btf_is_kernel, BPF verifier activity, or NULL pointer dereference.
• Investigate unexplained host crashes shortly after bpf() syscall activity, bpftool usage, or BPF program loading attempts.
• Because there is no known public exploitation or KEV listing and EPSS is low, handle through standard kernel vulnerability SLAs unless the system exposes BPF capabilities to untrusted users.