CVE-2026-63865

What it actually does

This is a local Linux kernel privilege-escalation flaw in the BPF LSM hook handling. The vulnerable kernel allowed sleepable BPF LSM programs to be associated with hooks that execute in non-sleepable contexts: task_to_inode runs under rcu_read_lock(), and inet_conn_established can run from softirq context. If a sleepable BPF program is reached from those contexts, the kernel can enter unsafe execution paths such as sleeping while atomic or while inside an RCU read-side critical section. Depending on kernel configuration and exploitability, this can lead to kernel memory corruption, denial of service, or privilege escalation with confidentiality, integrity, and availability impact.

Why it matters to the business

An attacker who already has local execution with low privileges may be able to turn that access into kernel-level control, potentially compromising the entire host, escaping workload isolation boundaries, tampering with security controls, or causing crashes. The EPSS score is currently low and it is not listed in CISA KEV, but because the impact is kernel-level and the issue is recent, exposed Linux systems that allow BPF program loading should still be prioritized for remediation.

How an attack unfolds

An attacker first gains local code execution on a vulnerable Linux host. They then determine whether BPF and BPF LSM functionality are available and whether their privileges, capabilities, namespace configuration, or local policy allow BPF program loading. The attacker loads a crafted sleepable BPF LSM program targeting one of the affected hook paths, then triggers activity that reaches task_to_inode or inet_conn_established, such as process or inode-related operations or establishing network connections. On a vulnerable kernel, the sleepable program can execute from a context where sleeping is unsafe, such as under RCU protection or softirq handling. A reliable exploit would attempt to turn the resulting unsafe kernel behavior into privilege escalation or kernel compromise; less reliable attempts may cause kernel warnings, oopses, soft lockups, or system crashes.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix removing task_to_inode and inet_conn_established from sleepable BPF LSM hook usage. No product-specific fixed versions were provided, so use the patched kernel packages from the relevant Linux distribution, appliance vendor, cloud image provider, or kernel maintainer. If immediate patching is not possible, reduce exposure by disabling unprivileged BPF where supported, restricting CAP_BPF, CAP_SYS_ADMIN, and CAP_PERFMON to trusted administrators only, preventing containers or sandboxed workloads from loading BPF programs, enabling kernel lockdown or equivalent hardening where appropriate, and monitoring or blocking unexpected bpf() syscall usage. Reboot into the patched kernel after installation; merely installing kernel packages is not sufficient if the system continues running the vulnerable kernel.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated to a build containing the fix. Validate with uname -a, package manager kernel version checks, and vendor advisory mapping. Confirm that unprivileged BPF is disabled or appropriately restricted with sysctl kernel.unprivileged_bpf_disabled where applicable. Use bpftool or equivalent administrative tooling to enumerate loaded BPF programs and confirm there are no unexpected BPF LSM programs. Where safe and authorized, validate that attempts to attach sleepable BPF LSM programs to the affected hook paths are rejected on the patched kernel. Review boot history to ensure all nodes have rebooted into the fixed kernel.

Typical attack path

1. Obtain local low-privileged execution on a Linux system.
2. Check whether BPF, BPF LSM, and unprivileged or capability-enabled BPF loading are available.
3. Load a crafted sleepable BPF LSM program that targets the affected hook behavior.
4. Trigger the vulnerable hook path through inode/task activity or established network connections.
5. Abuse the unsafe sleepable execution in an atomic, RCU, or softirq context to corrupt kernel state or destabilize the system.
6. Escalate privileges, disable controls, access protected data, or cause denial of service.

How to detect it

To assess whether exploitation may already have occurred, review kernel logs, audit logs, EDR telemetry, and BPF inventory data for unusual BPF program loading followed by kernel warnings, crashes, or privilege changes. Key sources include journald, dmesg, /var/log/kern.log, /var/log/messages, auditd records for the bpf syscall, process execution logs for bpftool or custom BPF loaders, container runtime logs showing unexpected elevated capabilities, and EDR events involving CAP_BPF or CAP_SYS_ADMIN. Look for BPF LSM programs loaded shortly before kernel messages about sleeping in atomic context, RCU misuse, softirq misuse, kernel oopses, panics, soft lockups, or unexpected reboots. Also investigate unknown persistent services or startup scripts that load BPF programs, unexplained root shells, unexpected setuid file changes, disabled security agents, and tampering with kernel or audit logging. Absence of logs does not prove absence of exploitation, because successful kernel-level exploitation may suppress or destroy forensic evidence.

• bpf_lsm_task_to_inode
• bpf_lsm_inet_conn_established
• task_to_inode
• inet_conn_established
• BUG: sleeping function called from invalid context
• sleeping function called from invalid context
• in_atomic()
• RCU read-side critical section
• suspicious RCU usage
• softirq
• kernel BUG at
• kernel NULL pointer dereference
• general protection fault
• Kernel panic - not syncing
• BUG: unable to handle page fault
• bpf(BPF_PROG_LOAD
• BPF_PROG_LOAD
• BPF_PROG_TYPE_LSM
• bpftool prog load
• bpftool prog attach
• /sys/fs/bpf
• kernel.unprivileged_bpf_disabled
• CAP_BPF
• CAP_SYS_ADMIN

What your security team should do

• Prioritize patching Linux systems that allow BPF program loading, run untrusted local workloads, provide shell access, or host multi-tenant/containerized workloads.
• Reboot systems after applying patched kernel packages and verify the running kernel version fleet-wide.
• Disable unprivileged BPF unless there is a documented business requirement for it.
• Restrict CAP_BPF, CAP_SYS_ADMIN, and related capabilities from users, services, and containers that do not explicitly require them.
• Inventory loaded BPF programs with bpftool and investigate unexpected BPF LSM programs or recent BPF loads by non-administrative accounts.
• Enable audit coverage for the bpf syscall and capability use where feasible.
• Review kernel logs for sleeping-in-atomic, RCU, softirq, BPF verifier, kernel oops, or panic messages around suspicious local activity.
• Treat unexplained kernel crashes on systems with BPF enabled as potentially security-relevant until ruled out.