CVE-2026-53074

What it actually does

This is an improper input validation flaw in the Linux kernel eBPF test-run path for socket-buffer programs. When bpf_prog_test_run_skb() receives a crafted Ethernet frame that declares IPv4 or IPv6 via EtherType but is too short to contain the corresponding layer-3 header, the kernel may access ip_hdr(skb) or ipv6_hdr(skb) before validating that the header is present. The fixed behavior rejects such malformed test inputs with -EINVAL before accessing network-header fields. The most likely technical impact is a local kernel out-of-bounds read that can trigger a kernel warning, oops, crash, or denial of service; depending on kernel build options, allocator state, and surrounding code paths, limited information disclosure cannot be ruled out. This is not a normal remote network packet parsing issue; exploitation is tied to the local BPF program test-run interface.

Why it matters to the business

Organizations running affected Linux kernels could face local system instability if a user or process with access to the BPF program test-run interface intentionally supplies malformed packet data. The practical risk is highest on multi-user systems, container hosts, CI/build runners, developer workstations, and platforms where privileged or semi-privileged workloads can load or test eBPF programs. Current public exploitation signals are low: EPSS is 0.00114, it is not listed in CISA KEV, no ransomware use is indicated, and no public exploit maturity is reported. Even so, kernel flaws should be prioritized for routine patching because successful exploitation can affect host availability and may bypass application-level isolation assumptions.

How an attack unfolds

An attacker first needs local access to a system and the ability to interact with the Linux bpf() syscall in a way that permits BPF program test execution, typically requiring elevated capabilities such as CAP_BPF, CAP_NET_ADMIN, CAP_SYS_ADMIN, or a permissive unprivileged BPF configuration depending on kernel version and distribution policy. The attacker loads or obtains a file descriptor for a suitable BPF program that can be exercised through the socket-buffer test-run facility. They then invoke BPF_PROG_TEST_RUN or the equivalent libbpf test-run path with crafted packet bytes containing an Ethernet header whose EtherType indicates IPv4 or IPv6, while omitting or truncating the actual IPv4 or IPv6 header. In vulnerable kernels, bpf_prog_test_run_skb() calls eth_type_trans(), uses skb->protocol to identify the packet family, and may access ip_hdr(skb) or ipv6_hdr(skb) even though the supplied buffer is too short. This can lead to an out-of-bounds read in kernel context, potentially causing a kernel oops, panic, KASAN report, or system crash. There is no indication of active exploitation by named threat actors or broad commodity exploitation as of the provided publication context.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the upstream fix to reject short IPv4 and IPv6 inputs in bpf_prog_test_run_skb(). Because no exact affected products or fixed package versions were provided, remediation should follow vendor kernel advisories for this CVE or for the kernel patch titled "bpf: reject short IPv4/IPv6 inputs in bpf_prog_test_run_skb". Reboot into the fixed kernel after installation; merely installing the package is insufficient if the running kernel is still vulnerable. As interim mitigation, reduce access to BPF features: disable unprivileged BPF where supported, restrict CAP_BPF, CAP_NET_ADMIN, and CAP_SYS_ADMIN to trusted users and workloads, limit privileged containers, and review seccomp, LSM, and container runtime policies to prevent unnecessary bpf() syscall access. On systems where eBPF is not operationally required, consider disabling or hardening BPF exposure according to vendor guidance.

How to confirm the fix worked

Confirm the running kernel version, not only the installed package version, after patching. Validate that the active kernel includes the fix by checking vendor changelogs, package metadata, or source patches for the bpf_prog_test_run_skb() change that returns -EINVAL when an Ethernet frame advertises IPv4 or IPv6 but lacks the minimum network header length. Where safe and appropriate in a non-production test environment, attempt a BPF_PROG_TEST_RUN using a too-short Ethernet frame with IPv4 or IPv6 EtherType and verify that the call fails cleanly with EINVAL and does not produce kernel warnings, oopses, KASAN reports, or crashes. Also verify that unprivileged BPF is disabled or restricted according to policy, and that only approved users, services, or containers retain BPF-related capabilities.

Typical attack path

1. Obtain local execution on a Linux system running an affected kernel.
2. Gain or already possess permission to use the BPF syscall and BPF program test-run functionality.
3. Load or reference an eligible BPF socket-buffer program.
4. Create a malformed test packet containing only an Ethernet header or otherwise too-short frame with EtherType 0x0800 for IPv4 or 0x86DD for IPv6.
5. Invoke BPF_PROG_TEST_RUN against the BPF program with the malformed packet as input.
6. Trigger bpf_prog_test_run_skb() to parse skb->protocol and access missing IPv4 or IPv6 header data.
7. Cause kernel out-of-bounds memory access, potentially resulting in a crash, oops, KASAN finding, or denial of service.

How to detect it

To determine whether this flaw may already have been exercised, review host-level telemetry because exploitation is local to the kernel BPF interface rather than remote network traffic. Key sources include kernel logs from journald, dmesg, syslog, crash dumps, kdump/vmcore records, auditd syscall logs for bpf(), eBPF management tooling logs, container runtime audit events, and EDR telemetry showing processes invoking BPF program test functionality. Look for temporal correlation between BPF_PROG_TEST_RUN activity and kernel warnings, oopses, panics, general protection faults, KASAN slab-out-of-bounds reports, or stack traces containing bpf_prog_test_run_skb(), eth_type_trans(), ip_hdr(), or ipv6_hdr(). Audit suspicious use by unexpected users or processes, especially inside privileged containers or from development/test tooling on production hosts. If packet test inputs are logged by instrumentation, look for very short Ethernet frames whose EtherType is IPv4 0x0800 or IPv6 0x86DD but whose total frame length is shorter than Ethernet plus the minimum IPv4 or IPv6 header. Absence of these artifacts does not prove non-exploitation, because unsuccessful or non-crashing attempts may leave little evidence unless BPF syscall auditing or tracing was enabled.

• bpf_prog_test_run_skb
• BPF_PROG_TEST_RUN
• eth_type_trans
• ip_hdr
• ipv6_hdr
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: out-of-bounds
• general protection fault
• kernel BUG at
• Oops:
• Kernel panic - not syncing
• bpf: reject short IPv4/IPv6 inputs in bpf_prog_test_run_skb
• syscall=bpf
• CAP_BPF
• CAP_NET_ADMIN
• CAP_SYS_ADMIN
• EtherType 0x0800
• EtherType 0x86DD

What your security team should do

• Inventory Linux systems where eBPF use is enabled, especially container hosts, Kubernetes nodes, observability/security sensor hosts, developer systems, CI runners, and multi-user servers.
• Patch affected kernels through the relevant OS or appliance vendor channel and reboot into the fixed kernel.
• Prioritize systems that allow untrusted local users, privileged containers, or workloads with CAP_BPF, CAP_NET_ADMIN, or CAP_SYS_ADMIN.
• Disable unprivileged BPF where operationally feasible, for example through the vendor-supported sysctl or hardening profile.
• Review container and workload policies to remove unnecessary BPF-related privileges and block unnecessary bpf() syscall access with seccomp or equivalent controls.
• Monitor kernel logs and audit telemetry for BPF_PROG_TEST_RUN activity followed by kernel faults, KASAN findings, or crashes in bpf_prog_test_run_skb(), ip_hdr(), or ipv6_hdr().
• Treat unexplained kernel oopses or panics involving BPF test-run paths as potentially security-relevant and preserve logs, crash dumps, and audit records for investigation.
• Because EPSS is low, there is no KEV listing, and exploit maturity is reported as none, handle this as routine but timely kernel maintenance unless local threat exposure is high.