CVE-2026-53036

What it actually does

CVE-2026-53036 is an improper range-validation flaw in the Linux kernel arm64 eBPF JIT compiler. The JIT helper used to validate branch displacement immediates accepts values that fit in a signed N+1-bit range instead of the intended signed N-bit range. For affected arm64 branch encodings, an out-of-range forward branch can be masked into the instruction field with the sign bit set, causing the generated native instruction to branch backward instead of forward. In practical terms, a specially crafted BPF program may cause incorrect JIT-generated control flow on arm64 systems. Impact depends on kernel configuration, BPF exposure, verifier constraints, and whether unprivileged BPF loading is permitted; plausible outcomes include kernel instability, denial of service, or potentially unintended execution paths in JIT-compiled BPF code.

Why it matters to the business

Organizations running affected Linux kernels on ARM64 infrastructure could experience reliability or availability issues if malicious or malformed BPF programs trigger incorrect JIT output. The highest-risk environments are those that allow unprivileged users, containers, workloads, or observability/security agents to load BPF programs. EPSS is currently low and there is no known KEV listing or public exploit maturity indicated, so this is not presently a broad active-exploitation emergency; however, kernel flaws in BPF are sensitive because they can affect shared hosts, container platforms, edge devices, and cloud ARM instances. Delayed remediation may leave systems exposed to future exploit development as researchers analyze the patch.

How an attack unfolds

An attacker first needs a path to load or influence eBPF programs on an affected ARM64 Linux system. This may be through local shell access, a compromised container with sufficient BPF capabilities, a service or agent that accepts BPF program input, or an environment where unprivileged BPF is enabled. The attacker crafts a BPF program whose JIT compilation requires a branch displacement near the boundary of the immediate field accepted by the arm64 branch instruction encoding. Because the vulnerable range check incorrectly allows a displacement too large for the signed field, the encoder masks the value into the instruction, turning the intended forward branch into a backward branch. The resulting native code may execute with unexpected control flow. Depending on surrounding generated code and kernel defenses, this could crash the kernel, hang execution, or potentially create exploitable behavior. No confirmed in-the-wild exploitation or named threat actor activity is provided for this CVE.

How to fix it

Upgrade to a Linux kernel version that includes the arm64 BPF JIT fix for the off-by-one immediate range check. Where vendor advisories are available, use the vendor-provided kernel package rather than relying only on upstream version comparisons. No exact fixed package versions were provided in the input, so security teams should consult their Linux distribution, appliance, cloud image, or device vendor advisory for the specific patched release. As interim mitigation, reduce BPF attack surface: disable unprivileged BPF where operationally feasible, restrict CAP_BPF, CAP_SYS_ADMIN, and related privileges, limit container access to BPF features, disable or restrict BPF JIT if acceptable for performance and compatibility, and ensure only trusted observability/security tooling can load BPF programs.

How to confirm the fix worked

Confirm that deployed ARM64 systems are running a kernel package containing the upstream fix to validate signed N-bit immediate ranges correctly in the arm64 BPF JIT. Inventory systems by architecture and kernel version, prioritizing ARM64 hosts with BPF JIT enabled. Check runtime exposure by reviewing sysctl settings such as kernel.unprivileged_bpf_disabled and net.core.bpf_jit_enable, and by auditing which services, containers, and users have BPF-loading privileges. If mitigation was applied, verify unprivileged BPF loading is disabled or appropriately restricted and confirm production observability or networking functions that rely on BPF still operate as expected. Where possible, use vendor-provided vulnerability scanners or package compliance tooling to verify the patched kernel build is installed and booted, not merely downloaded.

Typical attack path

1. Identify an affected ARM64 Linux kernel with eBPF JIT enabled.
2. Obtain the ability to load BPF programs, such as local user access, container capabilities, privileged helper access, or an exposed BPF-loading service.
3. Craft a BPF program that causes the arm64 JIT to generate a branch displacement outside the true signed immediate range but inside the incorrectly accepted range.
4. Trigger JIT compilation of the crafted BPF program.
5. Cause the malformed branch encoding to redirect execution unexpectedly, potentially producing a kernel crash, hang, or other unintended behavior.
6. Use the resulting impact for denial of service or, if further exploitation primitives are discovered, to pursue deeper kernel compromise.

How to detect it

To assess possible prior exploitation, focus on ARM64 hosts with BPF JIT enabled and review evidence of unusual BPF program loading followed by kernel instability. Useful sources include auditd logs for bpf() syscalls, eBPF subsystem telemetry from endpoint detection tools, syslog/journald kernel messages, crash dumps, kdump/vmcore data, container runtime audit logs, Kubernetes audit events for privileged pods or added BPF-related capabilities, and shell/process accounting showing use of BPF tooling. Look for unexpected use of bpftool, custom loaders invoking the bpf syscall, privileged containers mounting /sys/fs/bpf, changes to BPF-related sysctls, and temporal correlation with kernel oops, panic, watchdog, soft lockup, or unexplained reboot events. There are no public exploit-specific payload strings in the supplied intelligence, so detection should emphasize behavioral indicators rather than a single signature.

• bpftool prog load
• bpftool prog loadall
• bpftool prog attach
• bpf(BPF_PROG_LOAD
• BPF_PROG_LOAD
• /sys/fs/bpf
• kernel.unprivileged_bpf_disabled=0
• net.core.bpf_jit_enable=1
• CAP_BPF
• CAP_SYS_ADMIN
• privileged: true
• kernel BUG
• kernel panic
• Oops:
• Unable to handle kernel
• soft lockup
• hard LOCKUP
• watchdog: BUG: soft lockup
• rcu_sched detected stalls
• arm64 bpf jit
• bpf_jit
• BPF JIT

What your security team should do

• Prioritize patching ARM64 Linux systems that allow local users, containers, CI jobs, agents, or tenants to load BPF programs.
• Verify that the patched kernel is both installed and actively booted; schedule reboots or live-patching validation as required.
• Disable unprivileged BPF loading unless there is a documented business need.
• Restrict CAP_BPF, CAP_SYS_ADMIN, privileged containers, and access to /sys/fs/bpf to trusted administrators and approved agents only.
• Review container runtime, Kubernetes, and workload policies to prevent unnecessary BPF capabilities in application containers.
• Consider temporarily disabling or restricting BPF JIT on high-risk systems if patching is delayed and performance impact is acceptable.
• Monitor for kernel warnings, crashes, soft lockups, unexpected reboots, and unusual BPF program load activity on ARM64 hosts.
• Track Linux distribution and appliance vendor advisories for exact fixed package versions and backported patches.
• Because EPSS is low and there is no KEV listing, treat this as important kernel hardening rather than an active mass-exploitation incident, unless local telemetry shows suspicious BPF activity.