CVE-2026-43333

What it actually does

This flaw is in the Linux kernel eBPF verifier. The verifier incorrectly treats nullable PTR_TO_BUF pointers as safe for direct memory access because check_mem_access() matches the base pointer type while stripping the PTR_MAYBE_NULL attribute. In map iterator stop callbacks, ctx->key and ctx->value can be NULL; a crafted BPF program can dereference these nullable pointers and trigger a kernel NULL pointer dereference. The expected impact is local denial of service through a kernel crash or panic, not data theft or privilege escalation based on the available description.

Why it matters to the business

A local user or compromised low-privileged workload with permission to load BPF programs may be able to crash affected Linux systems, causing service interruption, node reboots, workload eviction, or availability loss. The CVSS availability impact is high, but public exploitation is not currently reported, EPSS is very low, and it is not listed in CISA KEV, so remediation should be prioritized for multi-user Linux systems, container hosts, Kubernetes nodes, CI runners, and environments where unprivileged or delegated BPF use is allowed.

How an attack unfolds

An attacker first needs local code execution on an affected Linux system and the ability to invoke the bpf() syscall to load or run an eBPF program. They craft a BPF program that uses a map iterator callback path where ctx->key or ctx->value may be NULL during the stop callback. Because the vulnerable verifier fails to reject direct access to a nullable PTR_TO_BUF pointer, the program is accepted instead of requiring a NULL check. When the iterator stop callback executes, the BPF program dereferences a NULL key or value pointer, causing a kernel NULL pointer dereference. Depending on kernel panic settings and workload supervision, this can crash the kernel, reboot the system, or destabilize affected services.

How to fix it

Apply a Linux kernel update that includes the upstream fix rejecting direct access to nullable PTR_TO_BUF pointers in the BPF verifier. Because no package-specific fixed versions were provided, use the fixed kernel releases from the relevant Linux distribution or vendor advisory and reboot into the patched kernel. As mitigation until patching is complete, restrict BPF program loading to trusted administrators only, disable unprivileged BPF where supported with sysctl kernel.unprivileged_bpf_disabled=1, limit CAP_BPF/CAP_SYS_ADMIN delegation, restrict access to bpftool and BPF loaders, and ensure container runtimes do not grant unnecessary capabilities that allow BPF program loading. On systems where BPF is not operationally required, consider disabling or blocking BPF use through distribution-supported hardening controls.

How to confirm the fix worked

Confirm that each affected system is running a vendor kernel build containing the fix for nullable PTR_TO_BUF access in the BPF verifier. Validate after reboot with uname -a, package-manager kernel version checks, and vendor advisory mapping rather than only checking installed packages. Review /proc/sys/kernel/unprivileged_bpf_disabled and capability assignments to ensure untrusted users cannot load BPF programs. In a non-production test system, a regression test should show that BPF programs attempting direct access to nullable map iterator ctx->key or ctx->value without a NULL check are rejected by the verifier rather than accepted and executed. Also confirm there have been no recent kernel oops, panic, or reboot events matching BPF verifier or BPF iterator activity.

Typical attack path

1. Gain local code execution on an affected Linux host, container host, or workload node.
2. Confirm the ability to load or execute eBPF programs through the bpf() syscall, bpftool, a custom loader, or another BPF-capable framework.
3. Create a malicious BPF map iterator program that directly dereferences ctx->key or ctx->value without a NULL check.
4. Load the program so the vulnerable verifier incorrectly accepts the unsafe direct PTR_TO_BUF access.
5. Trigger the iterator stop callback where ctx->key and ctx->value can be NULL.
6. Cause a kernel NULL pointer dereference, resulting in denial of service through kernel crash, panic, or reboot.

How to detect it

Detection is primarily based on evidence of attempted BPF program loading followed by kernel NULL pointer dereference, oops, panic, reboot, or watchdog events. Review kernel logs from journald, dmesg, /var/log/kern.log, /var/log/messages, crash dumps, and kdump/vmcore artifacts for NULL pointer dereferences that mention BPF, map iterators, verifier activity, or bpftool/custom BPF loaders. Review auditd or eBPF security telemetry for bpf() syscall use, especially BPF_PROG_LOAD events from unexpected users, containers, service accounts, or processes shortly before a crash. In containerized environments, correlate node reboots or kubelet/node-not-ready events with privileged container starts, containers granted CAP_BPF or CAP_SYS_ADMIN, or workloads invoking bpftool/libbpf. Since a successful exploit may only leave crash artifacts, preserve pre-reboot kernel logs and configure persistent journald, netconsole, pstore, or kdump where feasible.

• BUG: kernel NULL pointer dereference
• Oops: 0000
• Kernel panic - not syncing
• RIP: *bpf*
• RIP: *bpf_iter*
• RIP: *check_mem_access*
• bpf: Failed to load program
• BPF_PROG_LOAD
• SYSCALL=bpf
• comm="bpftool"
• kernel.unprivileged_bpf_disabled
• /sys/fs/bpf
• /proc/sys/kernel/unprivileged_bpf_disabled
• /var/crash/vmcore
• /sys/fs/pstore/dmesg-ramoops

What your security team should do

• Inventory Linux systems that permit BPF program loading, with priority on shared servers, container hosts, Kubernetes nodes, developer workstations, CI/CD runners, and high-availability infrastructure.
• Patch affected kernels using distribution or vendor updates and reboot to activate the fixed kernel.
• Until patching is complete, disable unprivileged BPF and remove unnecessary CAP_BPF, CAP_SYS_ADMIN, or privileged-container access from users and workloads.
• Monitor for BPF program load activity and kernel crash logs, especially on systems where non-administrative users or containers can invoke the bpf() syscall.
• Treat unexplained kernel panics or NULL pointer dereferences involving BPF, map iterators, or bpftool as potential exploitation attempts and preserve logs for forensics.
• Because EPSS is currently very low and there is no KEV listing, prioritize remediation based on exposure: highest for systems with local multi-tenancy or delegated BPF access, lower for tightly controlled single-purpose hosts.