CVE-2026-43333: Linux Kernel Use-After-Free Vulnerability

CVE-2026-43333 Overview

CVE-2026-43333 is a null pointer dereference vulnerability [CWE-476] in the Linux kernel's Berkeley Packet Filter (BPF) subsystem. The flaw resides in check_mem_access(), which uses base_type() to match PTR_TO_BUF pointers. This matching strips the PTR_MAYBE_NULL flag, permitting direct dereference without a prior null check. Map iterator context fields ctx->key and ctx->value are typed as PTR_TO_BUF | PTR_MAYBE_NULL and become NULL during stop callbacks, triggering a kernel NULL pointer dereference.

Critical Impact

A local, low-privileged user able to load BPF programs can trigger a kernel NULL pointer dereference during BPF map iterator stop callbacks, causing system-wide denial of service.

Affected Products

• Linux Kernel (multiple stable branches)
• Linux Kernel 7.0 release candidates rc1 through rc6
• Distributions shipping affected upstream kernel versions

Discovery Timeline

• 2026-05-08 - CVE-2026-43333 published to NVD
• 2026-05-15 - Last updated in NVD database

Technical Details for CVE-2026-43333

Vulnerability Analysis

The vulnerability exists in the BPF verifier's memory access validation routine, check_mem_access(). The Linux BPF type system uses composite type tags to encode pointer properties, where PTR_MAYBE_NULL indicates a pointer that the verifier cannot statically prove non-NULL. When the verifier categorizes a pointer using base_type(), the helper strips qualifier flags including PTR_MAYBE_NULL, returning only the base pointer kind.

For the PTR_TO_BUF branch in check_mem_access(), the code path did not re-check whether the original type carried PTR_MAYBE_NULL. The verifier therefore accepted direct dereference of PTR_TO_BUF pointers without requiring a preceding null check, contrary to the safety guarantee BPF promises kernel callers.

Root Cause

BPF map iterator programs receive a context structure containing ctx->key and ctx->value fields, both typed as PTR_TO_BUF | PTR_MAYBE_NULL. During iterator stop callbacks, the kernel passes NULL values for these fields because no current map element exists. A verified BPF program that dereferences ctx->key or ctx->value without a null check passes verification, then dereferences NULL at runtime inside the kernel, producing an oops.

Attack Vector

Exploitation requires local access and the ability to load BPF programs, typically CAP_BPF or CAP_SYS_ADMIN. An attacker authors a BPF map iterator program that directly reads ctx->key or ctx->value. The verifier accepts the program because base_type() masks the nullable qualifier. Attaching and running the iterator triggers the stop callback, dereferencing NULL inside kernel context. The result is a kernel panic or oops, denying service to the host.

The upstream fix adds a type_may_be_null() guard to the PTR_TO_BUF branch, mirroring the existing PTR_TO_BTF_ID pattern, so nullable buffer pointers must be null-checked before dereference.

Detection Methods for CVE-2026-43333

Indicators of Compromise

• Kernel oops or panic messages referencing check_mem_access, bpf_iter, or NULL pointer dereferences in BPF map iterator code paths
• Unexpected dmesg entries citing BUG: kernel NULL pointer dereference correlated with recent bpf() syscalls
• Unprivileged or service accounts loading BPF iterator programs targeting map types they do not normally use

Detection Strategies

• Audit bpf() syscall activity using kernel auditing (auditctl -a always,exit -F arch=b64 -S bpf) and flag BPF program loads of type BPF_PROG_TYPE_TRACING attaching to bpf_iter
• Correlate kernel crash dumps with preceding BPF program load events from the same UID and session
• Inventory hosts running affected kernel versions and rank by BPF loader capability exposure

Monitoring Recommendations

• Forward /var/log/kern.log and dmesg to centralized logging and alert on NULL pointer dereference signatures involving BPF symbols
• Track issuance of CAP_BPF and CAP_SYS_ADMIN to non-administrative workloads, including container runtimes
• Monitor for repeated host reboots or kernel panics on Linux fleets pending patch deployment

How to Mitigate CVE-2026-43333

Immediate Actions Required

• Apply the upstream stable kernel patches referenced in the vendor advisories and reboot affected systems
• Restrict CAP_BPF and CAP_SYS_ADMIN to trusted administrative accounts and remove these capabilities from container workloads where feasible
• Set kernel.unprivileged_bpf_disabled=1 via sysctl to block unprivileged BPF program loads on hosts that do not require them

Patch Information

The fix introduces a type_may_be_null() guard in the PTR_TO_BUF branch of check_mem_access(), matching the existing handling for PTR_TO_BTF_ID. Patches are available across multiple stable branches via the following commits: 10bc4a4d, 21a10c06, 4f6c99dc, 63276547, 70abd9d1, 8755066f, and b0db1acc. Apply the patch matching your kernel branch and rebuild or install the vendor-provided package.

Workarounds

• Disable unprivileged BPF by setting kernel.unprivileged_bpf_disabled=1 in /etc/sysctl.d/ and reloading sysctl values
• Remove CAP_BPF from container security profiles and Kubernetes pod specifications that do not require BPF functionality
• Use Linux Security Modules (SELinux, AppArmor) to constrain which processes may invoke the bpf() syscall

# Configuration example
# Disable unprivileged BPF program loading
echo 'kernel.unprivileged_bpf_disabled=1' | sudo tee /etc/sysctl.d/99-disable-unpriv-bpf.conf
sudo sysctl --system

# Verify the setting
sysctl kernel.unprivileged_bpf_disabled

# Audit BPF syscall usage
sudo auditctl -a always,exit -F arch=b64 -S bpf -k bpf_calls