CVE-2026-53076

What it actually does

This Linux kernel eBPF flaw causes an out-of-bounds read when data is copied from a BPF_MAP_TYPE_CGROUP_STORAGE map into a per-CPU BPF map with the same value_size when that size is not 8-byte aligned. The vulnerable copy path rounds the copy length up to 8 bytes even though the source object may only contain the declared smaller size, such as 4 bytes. As a result, kernel memory adjacent to the source value can be read and copied into the destination path. The primary impact is kernel memory information disclosure, which may assist later exploitation by leaking sensitive kernel data or weakening protections such as address-space layout randomization. Exploitation generally requires the ability to create and manipulate BPF maps, which is typically local and privilege-gated on hardened systems.

Why it matters to the business

Successful exploitation could allow a local user, compromised container workload, or process with sufficient BPF privileges to expose kernel memory that should remain private. While this is not described as a remote code execution issue and has low currently observed exploitation likelihood, kernel information leaks can materially increase the risk of privilege escalation chains. Organizations running Linux systems that allow unprivileged or broadly delegated eBPF use should treat this with higher urgency because exposure may extend across shared hosts, container platforms, and multi-user compute environments.

How an attack unfolds

An attacker first obtains local execution on a Linux system and the ability to use the bpf syscall to create and update BPF maps. They create a BPF cgroup storage map whose value_size is not aligned to 8 bytes, for example 4 bytes. They then create a per-CPU BPF map using the same unaligned value_size. By causing the kernel to update the per-CPU map using data from the cgroup storage map, the vulnerable pcpu_init_value path assumes the source is rounded up to 8 bytes and performs a rounded copy. Because the source only guarantees the smaller declared value size, the kernel reads past the end of the source value. Depending on how the copied bytes can subsequently be observed, the attacker may recover adjacent kernel memory content and use that information to support further local exploitation or bypass kernel hardening.

How to fix it

Upgrade to a Linux kernel version or vendor-distributed kernel package that includes the upstream fix for the BPF pcpu_init_value out-of-bounds read. Because fixed package versions were not provided in the input, use the relevant Linux distribution security advisory, kernel changelog, or vendor errata to identify the corrected kernel build. After installing the fixed kernel, reboot systems so the patched kernel is running; simply installing the package is not sufficient if the host continues to run the old kernel. As interim mitigation, restrict access to eBPF for untrusted users and workloads: disable unprivileged BPF where supported, avoid granting CAP_BPF or CAP_SYS_ADMIN to containers and services unless required, restrict bpf syscall access with seccomp where feasible, and reduce unnecessary use of privileged containers. These mitigations reduce exploitability but do not replace applying the kernel fix.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not only the installed package, contains the vendor fix. Check the active kernel version with standard operating-system tooling and compare it against the distribution advisory or fixed kernel package. Validate that systems have been rebooted into the patched kernel after update. Where practical, confirm the upstream or vendor patch for the BPF pcpu_init_value copy behavior is present in the kernel source or package changelog. For exposure validation, review whether untrusted users or workloads can call the bpf syscall, create cgroup storage maps, or create per-CPU BPF maps. Confirm that unprivileged BPF is disabled on systems where it is not required and that containers are not unnecessarily granted CAP_BPF, CAP_SYS_ADMIN, or privileged mode.

Typical attack path

1. Gain local code execution on a Linux host or inside a workload with access to BPF functionality.
2. Confirm the process has permissions needed to invoke bpf map operations, such as CAP_BPF, CAP_SYS_ADMIN, or an environment where unprivileged BPF is enabled.
3. Create a BPF_MAP_TYPE_CGROUP_STORAGE map with a value_size that is not a multiple of 8 bytes.
4. Create a per-CPU BPF map with the same unaligned value_size.
5. Trigger a map update or copy operation from the cgroup storage map value into the per-CPU map.
6. Cause the vulnerable kernel copy routine to round the copy size up to 8 bytes and read beyond the valid source buffer.
7. Attempt to recover the extra copied bytes or use the leak to aid a follow-on local privilege escalation chain.

How to detect it

This issue is difficult to detect after the fact because successful exploitation may not create a distinctive file, network connection, crash, or authentication event. Focus on kernel, audit, EDR, and eBPF telemetry. Review audit logs for bpf syscall activity by unexpected users, services, containers, or processes, especially map creation and update operations involving cgroup storage maps and per-CPU maps with small value sizes not aligned to 8 bytes. Inspect kernel logs for BPF verifier messages, warnings, KASAN reports, general protection faults, or other memory-safety diagnostics around the time of suspicious BPF activity. In containerized environments, review orchestration audit logs and runtime telemetry for workloads launched with privileged mode, CAP_BPF, CAP_SYS_ADMIN, or relaxed seccomp profiles. If exploitation is suspected, preserve kernel logs, audit records, process execution telemetry, loaded BPF program/map metadata where available, and container runtime metadata before rebooting or patching.

• syscall=bpf
• BPF_MAP_TYPE_CGROUP_STORAGE
• BPF_MAP_TYPE_PERCPU_ARRAY
• BPF_MAP_TYPE_PERCPU_HASH
• BPF_MAP_UPDATE_ELEM
• unprivileged_bpf_disabled=0
• cap_bpf
• CAP_BPF
• cap_sys_admin
• CAP_SYS_ADMIN
• privileged=true
• operation=BPF_MAP_CREATE

What your security team should do

• Prioritize patching Linux systems that support multi-user access, container workloads, CI/CD runners, shared compute, or services that grant BPF-related capabilities.
• Inventory kernels in use and identify systems where the running kernel predates the vendor fix, including long-lived hosts that may have installed but not booted into a patched kernel.
• Disable unprivileged BPF unless there is a documented operational requirement.
• Review container and workload policies to remove unnecessary CAP_BPF, CAP_SYS_ADMIN, privileged mode, and broad device/kernel access.
• Add audit or EDR monitoring for unusual bpf syscall activity, especially creation of cgroup storage maps and per-CPU maps by non-administrative processes.
• Treat any confirmed exploitation as a potential precursor to local privilege escalation and collect volatile forensic evidence before rebooting when operationally feasible.
• Track vendor advisories for exact fixed kernel package versions because no fixed versions were supplied with this vulnerability record.