CVE-2026-45838

What it actually does

This is a local Linux kernel bug in the BPF cgroup storage map key-iteration path. The vulnerable function, cgroup_storage_get_next_key(), incorrectly assumes list_next_entry() can return NULL at the end of a list; instead, it wraps to the list head. When a caller asks for the key after the final entry, the kernel can read a key from an invalid/bogus pointer that aliases internal map fields and copy that result back to userspace instead of returning end-of-list. In practical terms, a local user able to exercise the relevant BPF map operation may trigger invalid kernel memory access or kernel instability, leading primarily to denial of service.

Why it matters to the business

Successful exploitation can destabilize or crash affected Linux systems, interrupting workloads, containers, or services running on those hosts. The risk is most relevant on multi-user systems, developer hosts, Kubernetes/container platforms, CI runners, and other environments where non-root users or workloads may be permitted to use BPF features. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no public exploit maturity reported, so urgency should be driven by exposure of local users/workloads to BPF rather than internet-facing attack surface.

How an attack unfolds

An attacker first needs local code execution or an account on an affected Linux host with sufficient permission to interact with BPF cgroup storage maps. They create or access a relevant BPF map and repeatedly call the BPF map key-iteration operation, specifically the get-next-key path, until the iterator reaches the last list element. On a vulnerable kernel, the end-of-list condition is not detected correctly. Instead of returning that there are no more keys, the kernel treats the list head as though it were another entry, reads from an invalid structure location, and copies the bogus key data to userspace. Depending on kernel configuration, memory layout, and runtime state, this can produce incorrect results, trigger kernel warnings, or cause a kernel fault/panic that disrupts availability.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix changing end-of-list detection in cgroup_storage_get_next_key() from a NULL check to list_entry_is_head(). If using a distribution kernel, apply the vendor-provided security update rather than relying only on upstream version numbers, because fixes are commonly backported. Where immediate patching is not possible, reduce exposure by disabling unprivileged BPF where operationally feasible, restricting access to the bpf() syscall, limiting CAP_BPF/CAP_SYS_ADMIN in containers and service accounts, and applying seccomp, LSM, or container runtime policies that block unnecessary BPF map operations. Reboot into the fixed kernel after installation; merely installing kernel packages is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, contains the fix. Check the active kernel with uname -r and compare it with the distribution advisory or package changelog for the backported fix for cgroup_storage_get_next_key(). Validate that systems have been rebooted into the patched kernel. Where source or debug symbols are available, confirm the patched code uses list_entry_is_head() for end-of-list detection in the cgroup storage get-next-key path. For mitigation validation, verify unprivileged BPF is disabled where intended, confirm containers and services do not retain unnecessary CAP_BPF or CAP_SYS_ADMIN, and test that unauthorized users cannot invoke BPF map operations through the bpf() syscall.

Typical attack path

1. Gain local execution on an affected Linux system, such as through a shell, compromised service account, container workload, or developer/CI job.
2. Confirm BPF usage is permitted or obtain the privileges required to invoke the bpf() syscall for the relevant map operations.
3. Create or access a BPF cgroup storage map with entries suitable for key iteration.
4. Call BPF_MAP_GET_NEXT_KEY repeatedly until the current key is the final element in the internal list.
5. Trigger the flawed end-of-list handling in cgroup_storage_get_next_key().
6. Cause the kernel to read from a bogus pointer and return invalid data or potentially crash/oops the system, resulting in denial of service.

How to detect it

To determine whether exploitation may have occurred, review kernel logs, system journals, audit logs, and endpoint telemetry for suspicious BPF map key-iteration activity followed by kernel warnings, oopses, panics, or unexplained reboots. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, auditd records for the bpf syscall, EDR process telemetry, container runtime audit logs, and crash dump infrastructure such as kdump/vmcore. Look for local processes making repeated BPF_MAP_GET_NEXT_KEY calls, especially from unexpected users, containers, CI jobs, or services, and correlate that activity with kernel faults mentioning BPF, cgroup storage, list traversal, general protection faults, NULL or non-canonical pointer dereferences, KASAN reports, or system resets. Because exploitation artifacts are likely to be transient and local, absence of logs does not prove non-exploitation if kernel crash logging or auditd was not enabled.

• cgroup_storage_get_next_key
• BPF_MAP_GET_NEXT_KEY
• bpf(BPF_MAP_GET_NEXT_KEY
• syscall=bpf
• comm="bpf"
• kernel: BUG:
• kernel: Oops:
• kernel: general protection fault
• kernel: KASAN:
• kernel: panic
• list_next_entry
• list_entry_is_head
• /var/crash
• /proc/sys/kernel/unprivileged_bpf_disabled

What your security team should do

• Inventory Linux hosts where local users, containers, CI jobs, or untrusted workloads may be able to use BPF features.
• Prioritize patching multi-tenant, container-hosting, developer, and CI/CD systems before single-purpose appliances or tightly controlled servers.
• Apply vendor kernel updates that include the cgroup_storage_get_next_key() fix and reboot systems into the fixed kernel.
• Temporarily disable unprivileged BPF where feasible using the platform-supported sysctl or vendor guidance.
• Review container and service privileges; remove CAP_BPF, CAP_SYS_ADMIN, and broad privileged-container settings unless explicitly required.
• Add monitoring for unusual bpf() syscall usage and kernel crashes/oopses involving BPF map operations.
• Because this is not in KEV, has low EPSS, and has no reported public exploit maturity, treat it as important defense-in-depth patching rather than an emergency internet-facing response unless BPF is exposed to untrusted local workloads.