CVE-2026-90250: bpf, cgroup: Fix storage null-ptr-deref after replacing prog
In the Linux kernel, the following vulnerability has been resolved:
bpf, cgroup: Fix storage null-ptr-deref after replacing prog
Syzkaller reported a storage null-ptr-deref issue after replacing prog. This occurs in the following scenario: 1. prog A, an empty prog, is attached to a cgrp. 2. prog B uses BPFMAPTYPEPERCPUCGROUPSTORAGE and calls the bpfgetlocalstorage helper. 3. linkupdate is called to replace prog A with prog B.
The reason is that cgroupbpfreplace fails to alloc and assign the required cgrp storage for the incoming replacement prog. Consequently, the new prog inherits an uninit storage, leading to null-ptr-deref panic when kick the new prog.
Fix this by rejecting a link update if newprog's cgroup storage is incompatible with link->prog.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the panic?
A cgroup must have an empty BPF program attached, then a link update must replace it with a program that uses BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE and calls bpf_get_local_storage. When the replacement program is subsequently executed, it can dereference uninitialized cgroup storage and panic.
Is a normal BPF program replacement affected?
The issue is specific to replacing a linked cgroup BPF program where the incoming program requires per-CPU cgroup storage but the existing linked program does not have compatible storage. The described failure path is link_update from an empty program to a storage-using program.
What does the fix change?
The fix rejects a link update when the replacement program's cgroup storage is incompatible with the program currently associated with the link. This prevents the replacement program from inheriting uninitialized storage.