CVE-2026-53099

What it actually does

This Linux kernel flaw is in the eBPF/BTF kfunc destructor handling path. A kernel build-time configuration symbol was renamed from CONFIG_CFI_CLANG to CONFIG_CFI, but the affected code still checked the old name. As a result, protective handling intended to account for Control-Flow Integrity behavior could be compiled out on affected kernels. In vulnerable builds, certain BPF type-format destructor kfunc paths can still trigger CFI failures, which may cause kernel warnings, crashes, or denial of service depending on kernel configuration and how the vulnerable path is reached. There is no public exploit maturity reported and the EPSS score is very low, but the issue is kernel-level and should be treated seriously where untrusted or semi-trusted users can load or influence eBPF programs.

Why it matters to the business

Successful exploitation could disrupt Linux systems by crashing the kernel or causing instability, leading to workload outages, node reboots, service interruption, or degraded availability. The risk is highest on systems that allow local users, containers, privileged workloads, or service components to load or interact with eBPF functionality. This is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has low predicted exploitation likelihood, so remediation should be scheduled through normal kernel patching processes unless the environment exposes unprivileged BPF or runs multi-tenant Linux workloads.

How an attack unfolds

An attacker would generally need local execution capability or another foothold that permits interaction with eBPF facilities. They would attempt to load or trigger BPF functionality that reaches the affected BTF destructor kfunc path. On kernels built with the renamed CONFIG_CFI option but still containing the stale CONFIG_CFI_CLANG check, the intended CFI-specific handling is absent. When the crafted BPF path invokes the affected destructor callback type, the kernel may raise a CFI failure. Depending on kernel panic settings and error handling, this can produce kernel logs, terminate the offending path, or destabilize/crash the host. There is no indication from the provided intelligence that remote unauthenticated exploitation is expected.

How to fix it

Upgrade affected Linux kernels to a vendor-supported release that includes the upstream fix switching the BPF CFI conditional from CONFIG_CFI_CLANG to CONFIG_CFI. Because no exact affected products or fixed package versions were provided, use the Linux distribution or appliance vendor advisory to identify the corrected kernel package for each platform. After patching, reboot into the fixed kernel and remove or de-prioritize vulnerable kernels from boot menus where operationally feasible. As mitigations until patching is complete, restrict eBPF access to trusted administrators, disable unprivileged BPF where supported, limit container privileges, avoid CAP_BPF/CAP_SYS_ADMIN exposure to untrusted workloads, and apply kernel lockdown or least-privilege controls appropriate for the platform.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build containing the fix, not merely that the package is installed. Validate with the active kernel version after reboot and compare it to the vendor advisory or changelog referencing the BPF CONFIG_CFI change. Review kernel configuration to understand exposure to BPF and CFI, including whether CONFIG_CFI is enabled and whether unprivileged BPF is disabled. Confirm that non-administrative users and containers cannot load arbitrary BPF programs. Check kernel logs after patching for absence of recurring CFI failures involving BPF or BTF destructor kfunc paths during normal workload operation.

Typical attack path

1. Gain local code execution, container execution, or another position that can interact with eBPF-related kernel interfaces.
2. Determine whether the running kernel permits BPF program loading or relevant BTF/kfunc functionality.
3. Craft or run a BPF program that exercises the affected BTF destructor kfunc path.
4. Trigger the CFI mismatch condition caused by the missing CONFIG_CFI handling.
5. Cause a kernel CFI failure, warning, panic, or system instability resulting in denial of service.

How to detect it

Review host telemetry for signs that the vulnerable BPF/CFI path has already been triggered. Primary sources are kernel logs, systemd journal entries, crash dumps, audit logs, and EDR telemetry that records BPF program loading or privileged container activity. Look for CFI failure messages occurring near BPF, BTF, kfunc, or verifier log entries, followed by kernel oops, panic, watchdog reset, or unexpected reboot events. Correlate these events with local user activity, container starts, privileged workload execution, or processes invoking BPF tooling. On systems with auditd or eBPF observability, review attempts to use the bpf syscall, bpftool, privileged containers, or processes with CAP_BPF/CAP_SYS_ADMIN shortly before a crash. There are no known threat actors or public exploit artifacts provided for this CVE, so detection should focus on behavioral evidence of kernel CFI failures and suspicious BPF use rather than a fixed exploit signature.

• CFI failure
• __cfi_check_fail
• btf_dtor_kfunc_t
• BPF:
• bpf:
• BTF:
• kfunc
• kernel BUG
• Kernel panic - not syncing
• Oops:
• general protection fault
• watchdog: BUG: soft lockup
• watchdog: BUG: hard LOCKUP
• bpftool
• /usr/sbin/bpftool
• /sys/fs/bpf
• CAP_BPF
• CAP_SYS_ADMIN

What your security team should do

• Inventory Linux systems that run kernels with eBPF enabled, especially multi-tenant hosts, Kubernetes nodes, CI runners, developer systems, and container platforms.
• Prioritize patching systems where untrusted users or workloads can obtain local execution or BPF-related capabilities.
• Upgrade to a vendor-supported kernel containing the CONFIG_CFI fix and reboot into the corrected kernel.
• Disable or restrict unprivileged BPF and remove CAP_BPF, CAP_SYS_ADMIN, and privileged-container access from workloads that do not require them.
• Monitor kernel logs for CFI failures, BPF verifier activity, kernel panics, and unexpected reboots until remediation is complete.
• Because this is not KEV-listed, not associated with ransomware, and has low EPSS, handle through standard vulnerability management unless compensating factors increase local exploitation risk.