CVE-2026-45839

What it actually does

This Linux kernel flaw is an improper input validation bug in BPF CO-RE relocation parsing. The kernel accepts negative CO-RE accessor indices, even though valid accessors should be non-negative structure, array, or enum indices. A negative index can bypass the existing upper-bound check and later be cast to a large unsigned integer, causing an out-of-bounds kernel read during BPF program loading. On systems with vmlinux BTF enabled, which is common on major Linux distributions, a crafted BPF program can trigger a deterministic kernel crash during BPF_PROG_LOAD. The issue is locally reachable by a user or process with sufficient BPF privileges, such as CAP_BPF, and may affect confidentiality, integrity, and availability depending on kernel configuration and exploitability beyond the documented crash path.

Why it matters to the business

An attacker who already has local access and BPF loading privileges could crash affected Linux systems, causing service outages, workload disruption, and possible node instability in server, container, and cloud environments. Because BPF is widely used for observability, security tooling, networking, and performance monitoring, vulnerable kernels may exist across many operational roles even if BPF is not directly exposed to untrusted users. The currently reported exploitation maturity is none, EPSS is low, and the vulnerability is not listed in CISA KEV, but the impact can still be severe for multi-user systems or environments where CAP_BPF is granted to workloads, agents, or privileged containers.

How an attack unfolds

An attacker first obtains local execution on an affected Linux system and the ability to invoke the bpf() system call with privileges sufficient to load BPF programs. They then craft a BPF program containing CO-RE relocation metadata with a negative accessor component, such as an accessor path that includes -1 against a BTF type present in the running kernel. During BPF_PROG_LOAD, the kernel verifier and BTF relocation logic parse the malformed accessor. Because the parser accepts the negative value and the bounds check only rejects overly large positive indices, the negative value reaches member-offset handling and is converted to a large unsigned value. The kernel then reads outside the expected BTF member array, leading to a kernel page fault and an Oops/panic or system crash. There is no indication from the provided intelligence that this CVE is currently being used by named threat actors or ransomware campaigns.

How to fix it

Upgrade the Linux kernel to a version that includes the fix rejecting negative CO-RE accessor indices in bpf_core_parse_spec(). No exact fixed package versions were provided in the input, so use the fixed kernel builds published by the relevant Linux distribution or kernel vendor. Where immediate patching is not possible, reduce exposure by restricting BPF program loading to trusted administrators only, removing CAP_BPF from untrusted users, containers, and services, disabling unprivileged BPF where applicable, and reviewing privileged observability or networking agents that load BPF programs. Consider kernel lockdown, LSM policy, seccomp, and container runtime controls to limit access to the bpf() system call for workloads that do not require it.

How to confirm the fix worked

Confirm the running kernel build includes the vendor fix for rejecting negative CO-RE accessor indices. Validate package state using the distribution package manager and compare the installed kernel version against the vendor advisory. Confirm runtime exposure by checking whether unprivileged BPF is disabled, whether CAP_BPF is granted to non-administrative users or containers, and whether workloads can invoke BPF_PROG_LOAD. After remediation, a crafted BPF program with a negative CO-RE accessor should be rejected cleanly during validation rather than causing a kernel Oops or crash. Review kernel logs after testing to ensure no page faults, Oops messages, or call traces involving bpf_core_parse_spec, bpf_core_apply, check_core_relo, or bpf_prog_load are generated.

Typical attack path

1. Gain local code execution on an affected Linux host.
2. Obtain or abuse privileges that allow BPF program loading, such as CAP_BPF or equivalent elevated privileges.
3. Prepare a crafted BPF program with CO-RE relocation metadata containing a negative accessor index.
4. Submit the crafted program through the bpf() system call using BPF_PROG_LOAD.
5. Trigger kernel CO-RE relocation parsing during verifier processing.
6. Cause an out-of-bounds kernel read that results in a kernel Oops, panic, or host crash.

How to detect it

Look for evidence of attempted or successful malformed BPF program loading followed by kernel faults. Primary data sources include kernel logs from dmesg, journald, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore analysis, auditd records for the bpf syscall, and EDR telemetry showing processes invoking BPF_PROG_LOAD. Search for kernel Oops or panic events with call traces containing bpf_core_parse_spec, bpf_core_calc_relo_insn, bpf_core_apply, check_core_relo, bpf_check, bpf_prog_load, or __sys_bpf. Correlate these events with local users, containers, or processes that recently gained CAP_BPF/CAP_SYS_ADMIN or attempted BPF program loading. Successful exploitation is likely to manifest as a host crash or reboot shortly after BPF_PROG_LOAD activity; unsuccessful or blocked attempts may appear as denied bpf syscall events, seccomp/LSM denials, or verifier rejection messages. Because no public in-the-wild indicators or threat actor tooling are provided, detection should focus on behavioral artifacts and kernel crash signatures rather than file hashes or known malware names.

• bpf_core_parse_spec
• bpf_core_calc_relo_insn
• bpf_core_apply
• check_core_relo
• bpf_check
• bpf_prog_load
• __sys_bpf
• BPF_PROG_LOAD
• BUG: unable to handle page fault
• supervisor read access in kernel mode
• Oops: Oops
• RAX: 00000000ffffffff
• kernel BUG at
• Call Trace:
• audit: type=1326
• syscall=bpf
• capability=CAP_BPF
• CAP_BPF

What your security team should do

• Prioritize patching Linux kernels on multi-user systems, container hosts, Kubernetes nodes, CI runners, and servers where BPF-capable agents or privileged workloads run.
• Inventory hosts with CONFIG_DEBUG_INFO_BTF/vmlinux BTF enabled and BPF loading capability, as these are most directly exposed to the documented crash path.
• Remove CAP_BPF, CAP_SYS_ADMIN, and other BPF-enabling privileges from workloads and users that do not explicitly require them.
• Disable unprivileged BPF where operationally feasible and enforce least privilege for the bpf() system call using seccomp, LSM, or container runtime policy.
• Review privileged containers and host agents that load eBPF programs, including observability, tracing, networking, and security tools, to ensure they are trusted and updated.
• Monitor kernel logs and crash telemetry for BPF verifier or CO-RE relocation call traces that may indicate attempted exploitation.
• Because EPSS is currently low and there is no KEV listing, treat this as a high-impact local hardening and patching issue rather than an active internet-scale exploitation emergency.