CVE-2026-90250

What it actually does

A link_update operation that replaces an attached BPF cgroup program can fail to allocate and assign the required cgroup storage for the incoming program when it uses BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE. The replacement therefore inherits an uninitialized storage pointer, which later triggers a null-pointer dereference when the new program is executed and calls bpf_get_local_storage.

Why it matters to the business

Systems running affected kernels may experience sudden kernel panics during routine BPF program updates on cgroups, causing service outages, container restarts, or host reboots that disrupt workloads relying on cgroup-attached BPF programs.

How an attack unfolds

An attacker with the ability to load and attach BPF programs and perform link updates on a target cgroup first attaches an empty program, then replaces it with a program that uses per-CPU cgroup storage. Because the kernel does not validate storage compatibility during replacement, the new program runs with a null storage pointer and crashes the kernel on first access to that storage.

How to fix it

Upgrade to a kernel that includes the fix rejecting link updates when the replacement program's cgroup storage requirements are incompatible with the existing link. Where immediate patching is not possible, restrict untrusted users from performing BPF link updates on cgroups via LSM or seccomp policies.

How to confirm the fix worked

Confirm the kernel source contains the check that aborts cgroup_bpf_replace when new_prog storage is incompatible; test by attempting a link_update with an empty program followed by a PERCPU_CGROUP_STORAGE program and verify the operation is now rejected with an appropriate error instead of panicking.

Typical attack path

1. Obtain CAP_BPF or equivalent privileges to load and attach programs to cgroups
2. Attach an empty BPF program to a chosen cgroup
3. Prepare a replacement program that declares BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE and invokes bpf_get_local_storage
4. Issue a link update operation to swap the attached program
5. Trigger execution of the replacement program to cause the null dereference panic

How to detect it

Review kernel logs for oops or panic messages containing references to __cgroup_bpf_replace, bpf_get_local_storage, or null pointer dereference in the cgroup BPF storage path; correlate with audit records of BPF link update syscalls around the time of the crash.

What your security team should do

• Prioritize kernel updates on any system that permits unprivileged or semi-privileged BPF cgroup attachments
• Audit existing cgroup BPF programs and links for use of storage maps
• Apply capability and LSM restrictions to limit which users or services may perform link_update operations
• Monitor for kernel oops/panic reports referencing cgroup storage or bpf_get_local_storage