CVE-2026-43306

What it actually does

This is a local denial-of-service flaw in the Linux kernel BPF crypto code path when Control Flow Integrity (CONFIG_CFI) is enabled. The kernel registers a BPF crypto context destructor kfunc with an incompatible function pointer type, so when BPF object field cleanup invokes the destructor indirectly, CFI can detect a type mismatch and trigger a kernel oops/panic. A local user with sufficient ability to load or exercise relevant BPF functionality can cause high availability impact by crashing the kernel or destabilizing the host. The issue does not directly provide confidentiality or integrity impact based on the published description.

Why it matters to the business

Successful exploitation can crash affected Linux systems, interrupting workloads, network services, containers, or infrastructure components running on those hosts. Because exploitation is local and requires privileges, the primary business risk is service disruption from a compromised or semi-trusted local account, container escape-adjacent misuse of BPF capabilities, or intentional abuse by users with BPF access. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has very low EPSS, so remediation should be prioritized based on exposure of BPF to local users and the operational criticality of affected Linux hosts.

How an attack unfolds

An attacker first obtains local access to an affected Linux system and the privileges or capabilities needed to exercise BPF functionality, such as loading BPF programs or triggering BPF self-test-like crypto object handling paths. The attacker then causes creation and cleanup of BPF crypto context-backed objects in a kernel built with CONFIG_CFI enabled. During object cleanup, the kernel calls the registered destructor through an indirect function pointer. Because the registered destructor has the wrong kfunc type, CFI identifies the mismatch and raises a CFI failure. This can lead to a kernel oops or panic, making the system unavailable until it recovers or is rebooted. There is currently no indication of public weaponized exploitation or named threat actor use.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the upstream fix for the BPF crypto destructor kfunc type mismatch. No exact fixed package versions were provided in the input, so track vendor advisories for the specific distribution, kernel branch, appliance, or managed image in use. As interim risk reduction, restrict BPF access to trusted administrators only, disable unprivileged BPF where feasible, avoid granting CAP_BPF or CAP_SYS_ADMIN broadly, and review privileged container profiles that may permit BPF use. If CONFIG_CFI is enabled, prioritize patching systems where local users, build agents, container workloads, or multi-tenant workloads can access BPF functionality.

How to confirm the fix worked

Confirm that the running kernel package or build includes the vendor fix for the BPF crypto destructor kfunc registration. Validate using the distribution package manager, kernel changelog, vendor advisory, or source tree commit history for the fix described as using the correct destructor kfunc type for BPF crypto. Check the active kernel with uname -a and ensure the system has been rebooted into the patched kernel after installation. Verify exposure controls by checking whether unprivileged BPF is disabled where intended and whether only trusted processes have BPF-related capabilities. On test systems, relevant BPF self-tests or BPF crypto cleanup paths should no longer produce CFI failures, oops messages, or panics.

Typical attack path

1. Gain local code execution or shell access on an affected Linux host.
2. Obtain or already possess permissions needed to use BPF-related functionality, such as CAP_BPF, CAP_SYS_ADMIN, privileged container access, or permissive unprivileged BPF settings depending on kernel configuration.
3. Trigger the vulnerable BPF crypto context lifecycle path by creating and freeing objects that use the affected destructor kfunc.
4. Cause the kernel to perform the indirect destructor call under CONFIG_CFI enforcement.
5. Induce a CFI failure resulting in kernel oops, panic, service interruption, or host reboot.

How to detect it

Look for evidence of kernel CFI failures, oopses, panics, or unexpected reboots that reference BPF object cleanup or BPF crypto context release functions. Useful sources include kernel ring buffer output, persistent system journal logs, /var/log/kern.log, /var/log/messages, crash dump directories, kdump/vmcore records, hypervisor reboot telemetry, and endpoint telemetry that records privileged BPF usage. Search around the time of any crash for local users or containers invoking BPF loaders, bpftool, custom eBPF binaries, test harnesses, or processes with CAP_BPF/CAP_SYS_ADMIN. Indicators are mostly crash artifacts rather than network IOCs because exploitation is local and causes availability impact. If repeated crashes include the same CFI mismatch at bpf_obj_free_fields targeting bpf_crypto_ctx_release, treat that as strong evidence the vulnerable path was exercised.

• CFI failure at bpf_obj_free_fields
• target: bpf_crypto_ctx_release
• bpf_crypto_ctx_release+0x0
• Internal error: Oops - CFI
• Oops - CFI
• kernel: CFI failure
• bpf_obj_free_fields+0x190
• bpf_crypto_ctx_release+0x0/0x94
• CONFIG_CFI
• bpftool
• /sys/kernel/debug/tracing
• /proc/sys/kernel/unprivileged_bpf_disabled
• CAP_BPF
• CAP_SYS_ADMIN

What your security team should do

• Inventory Linux hosts running kernels with BPF enabled, especially those with CONFIG_CFI enabled and local multi-user, CI/CD, container, or shared workload exposure.
• Apply vendor kernel updates that include the fix, then reboot into the patched kernel; prioritize critical production hosts and systems where local users or containers can use BPF.
• Disable unprivileged BPF where operationally feasible, for example by enforcing the distribution-supported sysctl or kernel setting for unprivileged BPF restrictions.
• Limit CAP_BPF, CAP_SYS_ADMIN, privileged containers, and broad eBPF tooling access to trusted administrators and approved observability/security agents.
• Review kernel logs for historical CFI failures, oopses, or panics referencing BPF crypto cleanup functions to determine whether the issue may already have been triggered.
• Monitor vendor advisories because exact fixed versions vary by distribution and kernel branch, and no universal fixed version was provided.
• Treat repeated local kernel crashes involving BPF as potentially malicious even though current exploit maturity is listed as none and the vulnerability is not in CISA KEV.