CVE-2026-43010

What it actually does

This is a local Linux kernel eBPF validation flaw in the kprobe.multi attach path. kprobe_multi programs execute in atomic/RCU context, where sleeping is not allowed, but the kernel failed to reject BPF programs marked as sleepable during bpf_kprobe_multi_link_attach(). A local user with the ability to load and attach eBPF programs can attach a sleepable kprobe_multi program and invoke helpers such as bpf_copy_from_user() from a non-sleepable context, triggering kernel warnings such as “sleeping function called from invalid context.” The primary impact is availability: depending on kernel configuration, panic-on-warn behavior, workload, and operational controls, this can degrade stability or cause a local denial of service. There is no indication from the provided data of remote exploitation, privilege escalation, or data disclosure.

Why it matters to the business

Systems that allow local users, containers, observability agents, or workloads to load eBPF programs may be exposed to local disruption. Exploitation could destabilize Linux hosts, interrupt applications, or trigger reboots if the kernel is configured to panic on warnings. The EPSS score is very low and there is no known exploitation or CISA KEV listing, so this should generally be handled through normal kernel patch management unless the organization heavily uses eBPF, permits unprivileged BPF, runs multi-tenant Linux workloads, or enables panic-on-warn settings.

How an attack unfolds

An attacker first obtains local code execution on a Linux host and must have sufficient permission to load and attach eBPF programs, typically through CAP_BPF, CAP_PERFMON, CAP_SYS_ADMIN, privileged container access, or permissive unprivileged BPF settings. The attacker then prepares a BPF program marked as sleepable and attempts to attach it through the kprobe.multi interface. Because vulnerable kernels do not reject this combination at attach time, the program can run in an atomic/RCU context where sleeping helpers are invalid. When the program invokes a sleepable helper such as bpf_copy_from_user(), the kernel detects a sleeping operation in an invalid context and emits a splat. On systems configured to panic on warnings or under repeated triggering, this may cause service degradation, host instability, or denial of service.

How to fix it

Upgrade to a Linux kernel version or vendor backport that includes the fix rejecting sleepable kprobe_multi programs at attach time in bpf_kprobe_multi_link_attach(). No exact fixed package versions were provided in the input, so use the relevant distribution advisories and kernel changelogs for the deployed kernel stream. Where immediate patching is not possible, reduce exposure by disabling unprivileged eBPF where feasible, limiting CAP_BPF, CAP_PERFMON, CAP_SYS_ADMIN, and privileged container use, restricting access to performance tracing and BPF tooling, enabling kernel lockdown features where appropriate, and reviewing whether panic_on_warn or related settings would convert this warning into a full host outage. Treat hosts running multi-tenant workloads, developer sandboxes, CI runners, Kubernetes nodes with privileged workloads, and systems using custom BPF observability tooling as higher priority.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel includes the upstream or vendor fix for rejecting sleepable kprobe_multi programs during attachment. Use the distribution’s package metadata, changelog, or security advisory to verify the patched kernel is installed and that the host has been rebooted into it. Operationally, validate that unprivileged BPF is disabled where required by policy, that only approved users and workloads have BPF-related capabilities, and that privileged containers are minimized. In a controlled non-production test environment, an attempted attach of a sleepable kprobe_multi BPF program should be rejected at attach time rather than allowing execution that produces a “sleeping function called from invalid context” kernel splat.

Typical attack path

1. Gain local execution on a vulnerable Linux system, either as a local user, compromised service account, or workload/container with sufficient kernel-facing privileges.
2. Confirm that eBPF program loading and kprobe attachment are permitted through capabilities such as CAP_BPF, CAP_PERFMON, CAP_SYS_ADMIN, or permissive unprivileged BPF configuration.
3. Create or load an eBPF program marked as sleepable that targets kprobe.multi attachment.
4. Attach the sleepable program via the kprobe_multi attach path on a vulnerable kernel.
5. Trigger the probe so the program executes in atomic/RCU context and calls a helper that may sleep, such as bpf_copy_from_user().
6. Cause kernel warnings, instability, or denial of service, especially if kernel warning conditions are configured to trigger a panic or reboot.

How to detect it

Look for evidence of attempted or successful abuse in kernel logs, system journals, audit logs, and endpoint telemetry. Primary log sources include dmesg, /var/log/kern.log, /var/log/messages, systemd-journald kernel facility logs, auditd syscall records, EDR process telemetry, and container runtime logs for privileged workloads. Search for kernel splats containing “sleeping function called from invalid context,” especially when accompanied by BPF, kprobe, kprobe_multi, RCU, atomic context, or bpf_copy_from_user references. Investigate nearby process context fields such as pid and process name to identify the process that triggered the warning. Also review executions of bpftool, custom BPF loaders, tracing frameworks, or unexpected processes making BPF syscalls. Because this issue is a local denial-of-service condition and no public exploit maturity or KEV activity is reported, detection should focus on anomalous BPF activity, kernel warning bursts, unexpected reboots, and warning-to-panic events rather than network indicators.

• sleeping function called from invalid context
• BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169
• in_atomic(): 1
• RCU nest depth: 2
• bpf_kprobe_multi_link_attach
• kprobe.multi
• kprobe_multi
• bpf_copy_from_user
• preempt_count: 1, expected: 0
• bpftool prog load
• bpftool link create
• kernel.panic_on_warn = 1
• /proc/sys/kernel/panic_on_warn
• /sys/kernel/debug/tracing
• /sys/fs/bpf

What your security team should do

• Prioritize kernel updates on Linux systems that permit eBPF loading, run privileged containers, support multi-tenant workloads, or are configured to panic on kernel warnings.
• Inventory systems where unprivileged BPF is enabled and disable it unless there is a documented business need.
• Review container, service, and user permissions for CAP_BPF, CAP_PERFMON, CAP_SYS_ADMIN, privileged mode, and broad access to BPF or tracing facilities.
• Monitor kernel logs for BPF-related invalid sleep context warnings, especially messages mentioning kprobe_multi, bpf_kprobe_multi_link_attach, bpf_copy_from_user, or “sleeping function called from invalid context.”
• Ensure EDR, auditd, or Linux telemetry captures execution of BPF tooling such as bpftool and suspicious use of BPF syscalls by non-administrative users or unexpected processes.
• For high-availability systems, review panic_on_warn and related kernel panic settings to avoid avoidable outages while still preserving appropriate safety controls.
• Track vendor kernel advisories for exact fixed versions because no fixed version list was provided in the input.