CVE-2026-45927: Linux Kernel Privilege Escalation Flaw

CVE-2026-45927 Overview

CVE-2026-45927 is a Time-of-Check Time-of-Use (TOCTOU) vulnerability in the Linux kernel Berkeley Packet Filter (BPF) subsystem. The flaw resides in the bpf_map_get_info_by_fd function, which calculates and caches the hash of a BPF map regardless of the map's frozen state. Userspace can invoke BPF_OBJ_GET_INFO_BY_FD to cache the hash, modify the map contents, and then freeze the map. A trusted loader validating map integrity through the cached hash can be tricked into verifying a stale hash while the map contains modified contents. The vulnerability undermines the integrity guarantees that frozen BPF maps are intended to provide to signed or trusted BPF program loaders.

Critical Impact
A local attacker can bypass BPF map integrity checks by inducing a trusted loader to verify a stale hash, enabling smuggling of modified map contents past signature or attestation logic.

Affected Products

Linux kernel versions containing the unpatched bpf_map_get_info_by_fd hash caching logic
Distributions shipping affected upstream kernel revisions prior to the referenced stable commits
Systems relying on BPF map hash attestation for trusted loader workflows

Discovery Timeline

2026-05-27 - CVE-2026-45927 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-45927

Vulnerability Analysis

The Linux kernel BPF subsystem allows userspace to retrieve metadata about a BPF map through the BPF_OBJ_GET_INFO_BY_FD syscall. Part of that metadata is a hash of the map's contents, which trusted loaders use to verify integrity before associating the map with a signed BPF program. The kernel computes and caches this hash on first request, then returns the cached value on subsequent calls.

The flaw arises because the hash is computed even when the map is mutable. An attacker requests the hash, then writes new entries into the map, then freezes it. A loader that re-reads the hash receives the originally cached value, which no longer reflects the actual contents. This is a classic TOCTOU pattern where the check (hash retrieval) and the use (loader validation) span a window in which the underlying object changes.

Root Cause

The root cause is missing state validation in bpf_map_get_info_by_fd. The function did not verify that the map was frozen before generating or returning the cached hash. Because the hash represents a point-in-time snapshot, caching it for a mutable object produces a value that cannot be trusted across map modifications.

Attack Vector

Exploitation requires local access and the ability to create or interact with BPF maps. The attacker performs the following sequence: call BPF_OBJ_GET_INFO_BY_FD against an unfrozen map to populate the cached hash, modify the map's key-value pairs through the standard update syscalls, then issue BPF_MAP_FREEZE. A trusted loader subsequently reading the map info receives the stale cached hash, which matches the loader's expected attestation value while the runtime contents differ.

The upstream fix returns -EPERM when the hash is requested for a non-frozen map. This guarantees that the hash is only generated against the final, immutable state. See the kernel patches at commit 7752d363, commit a2c86aa6, and commit f415e114 for the implementation details.

Detection Methods for CVE-2026-45927

Indicators of Compromise

Processes issuing BPF_OBJ_GET_INFO_BY_FD followed by BPF_MAP_UPDATE_ELEM and then BPF_MAP_FREEZE against the same map file descriptor
Unprivileged or unexpected user processes interacting with BPF map syscalls on systems that normally restrict BPF usage
BPF loader audit logs reporting hash verification success on maps whose contents do not match known-good baselines

Detection Strategies

Audit kernel syscall activity for the bpf() syscall with commands BPF_OBJ_GET_INFO_BY_FD, BPF_MAP_UPDATE_ELEM, and BPF_MAP_FREEZE issued in short succession by the same process
Enable Linux audit framework rules on the bpf syscall and correlate sequences targeting identical map file descriptors
Compare runtime BPF map contents against attestation baselines to detect divergence between expected hashes and actual data

Monitoring Recommendations

Collect kernel telemetry through eBPF-based observability tools and ship it to a centralized analytics backend for sequence analysis
Alert on any failure returning -EPERM from bpf_map_get_info_by_fd after patching, which indicates loaders or tools attempting the unsafe pattern
Track kernel version inventory across the fleet to surface hosts still running pre-patch kernels

How to Mitigate CVE-2026-45927

Immediate Actions Required

Apply the upstream stable kernel updates referenced in the kernel.org commits and reboot affected systems
Restrict the bpf() syscall to privileged users by setting kernel.unprivileged_bpf_disabled=1 until patches are deployed
Audit trusted BPF loader implementations to confirm they require freeze before hash validation

Patch Information

The fix modifies bpf_map_get_info_by_fd to return -EPERM when the hash is requested against a non-frozen map. The change is distributed across the three stable kernel commits referenced in the advisory. Distribution maintainers have backported the fix to supported stable branches, so administrators should pull the latest kernel package from their distribution.

Workarounds

Disable unprivileged BPF program loading by writing 1 to /proc/sys/kernel/unprivileged_bpf_disabled
Enforce that trusted loaders call BPF_MAP_FREEZE themselves before requesting the map hash, eliminating reliance on caller-supplied freeze state
Apply seccomp or Linux Security Module policies that block the bpf() syscall for workloads that do not require it

bash

# Configuration example
# Disable unprivileged BPF until kernel patches are applied
sysctl -w kernel.unprivileged_bpf_disabled=1
echo 'kernel.unprivileged_bpf_disabled=1' >> /etc/sysctl.d/99-bpf-hardening.conf

# Verify kernel version contains the fix
uname -r