CVE-2026-53111

What it actually does

This is a Linux kernel denial-of-service flaw in the BPF skb test-run path. When a BPF program executed through bpf_prog_test_run_skb invokes the lightweight tunnel encapsulation helper path, bpf_lwt_xmit_push_encap / bpf_lwt_push_ip_encap can dereference skb_dst(skb)->dev even though the test-created skb may not have skb->_skb_refdst initialized. The resulting NULL pointer dereference occurs in kernel mode and can trigger an oops or panic, depending on kernel configuration, causing local system instability or a crash. The vulnerability is not known to provide code execution or privilege escalation based on the available information.

Why it matters to the business

Successful exploitation can crash affected Linux systems or disrupt workloads running on them, creating availability risk for servers, container hosts, CI systems, appliances, and platforms that allow BPF program loading or BPF test execution. Risk is reduced by the currently low EPSS score, lack of known public exploitation, and absence from the CISA KEV catalog, but systems exposing BPF functionality to untrusted local users or workloads should still prioritize remediation because kernel crashes can cause service outages.

How an attack unfolds

An attacker needs local ability to interact with the BPF syscall and load or test-run an eligible BPF program. They craft a BPF program or test-run input that reaches the skb-based BPF test execution path and invokes the lightweight tunnel IP encapsulation helper. In the vulnerable kernel path, the skb created for test execution lacks an initialized destination reference, but the helper assumes skb_dst(skb)->dev is valid while calculating required headroom. That invalid assumption leads to a NULL pointer dereference in kernel space, producing an oops and potentially a full system panic or reboot if panic-on-oops or similar hardening settings are enabled. There is no current indication of ransomware use, named threat actor exploitation, or mature public exploit activity.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or upstream stable branch that includes the fix for the BPF test-run skb destination initialization issue. Where immediate patching is not possible, reduce exposure by disabling unprivileged BPF if not required, restricting access to the bpf syscall, limiting CAP_BPF and CAP_SYS_ADMIN to trusted workloads only, and preventing untrusted containers from receiving elevated BPF-related capabilities. Consider enforcing seccomp, LSM, or container runtime policies that block bpf syscall use for workloads that do not explicitly need it. If kernel panic-on-oops is enabled on production systems, evaluate whether the operational risk is acceptable because this flaw can turn a kernel oops into a full reboot.

How to confirm the fix worked

Confirm the running kernel package includes the vendor fix by checking the installed kernel version and distribution advisory status, then reboot into the patched kernel. Verify that older vulnerable kernels are not still booted by comparing the installed package version with uname -a output. Validate exposure controls by checking whether unprivileged BPF is disabled, whether seccomp or LSM policy blocks the bpf syscall for untrusted services, and whether containers lack CAP_BPF and CAP_SYS_ADMIN unless explicitly required. On test systems only, kernel maintainers may confirm the fix by running the relevant BPF selftest or reproducer and verifying that bpf_prog_test_run_skb no longer triggers an oops in bpf_lwt_push_ip_encap.

Typical attack path

1. Gain local code execution or shell access on a Linux system where BPF program loading or BPF test execution is permitted.
2. Check whether unprivileged BPF is enabled or whether the attacker has sufficient privileges such as CAP_BPF, CAP_SYS_ADMIN, or equivalent container/runtime permissions.
3. Load or prepare a BPF program using skb test-run functionality.
4. Trigger a path that invokes the lightweight tunnel encapsulation helper, such as bpf_lwt_push_ip_encap, during bpf_prog_test_run_skb execution.
5. Cause the kernel to dereference a NULL skb destination/device pointer.
6. Crash the kernel or destabilize the host, resulting in denial of service.

How to detect it

Review kernel logs, persistent journal entries, crash dumps, and monitoring events for kernel oops, panic, or reboot activity involving the BPF skb test-run and lightweight tunnel encapsulation functions. Useful sources include dmesg output, /var/log/kern.log, /var/log/messages, systemd journal kernel facility logs, kdump/vmcore artifacts, crash reporting systems, EDR telemetry for bpf syscall activity, auditd syscall logs if bpf syscall auditing is enabled, and container runtime logs showing privileged or BPF-capable workloads. Focus on stack traces containing bpf_lwt_push_ip_encap, bpf_lwt_xmit_push_encap, bpf_prog_test_run_skb, bpf_test_run, __sys_bpf, or __x64_sys_bpf near a NULL pointer dereference. A matching crash is not definitive proof of malicious exploitation, as the issue can also be triggered by testing or fuzzing, so correlate with local user activity, recently executed proof-of-concept binaries, suspicious BPF loaders, unexpected privileged containers, and repeated crash attempts.

• BUG: kernel NULL pointer dereference, address: 0000000000000000
• RIP: 0010:bpf_lwt_push_ip_encap
• bpf_lwt_push_ip_encap+0x
• bpf_lwt_xmit_push_encap+0x
• bpf_prog_test_run_skb+0x
• bpf_test_run+0x
• __sys_bpf+0x
• __x64_sys_bpf+0x
• Oops: 0000
• supervisor read access in kernel mode
• Comm: poc
• /var/log/kern.log
• /var/log/messages
• /proc/sys/kernel/unprivileged_bpf_disabled

What your security team should do

• Patch affected Linux kernels through the normal OS or appliance vendor channel and ensure systems are rebooted into the fixed kernel.
• Prioritize internet-facing infrastructure, multi-tenant hosts, container platforms, CI runners, developer workstations, and systems where untrusted users can execute local code.
• Disable unprivileged BPF where it is not required, for example by setting kernel.unprivileged_bpf_disabled according to distribution support and operational requirements.
• Restrict CAP_BPF, CAP_SYS_ADMIN, privileged containers, and direct bpf syscall access to trusted administrative workloads only.
• Add monitoring for kernel oops or panic events referencing bpf_lwt_push_ip_encap, bpf_lwt_xmit_push_encap, bpf_prog_test_run_skb, or __sys_bpf.
• Review recent host crashes and unexpected reboots for matching kernel traces to determine whether exploitation or accidental triggering occurred.
• Track distribution advisories because fixed versions vary by kernel branch and vendor backporting policy.