CVE-2026-90313: bpf, cgroup: Fix invalid storage access after __cgroup_bpf_attach failed
In the Linux kernel, the following vulnerability has been resolved:
bpf, cgroup: Fix invalid storage access after cgroupbpfattach failed
A potential invalid storage access issue can occur after replacing a cgroup bpf prog.
This occurs in the following scenario: 1. prog1 with storage is attached to a cgroup in multi-attach mode. 2. prog1 is replaced with prog2 using BPFFREPLACE in multi-attach mode, but fails midway (e.g. in bpftrampolinelinkcgroupshim or updateeffectiveprogs). 3. A new prog3 is attached to the cgroup in multi-attach mode.
The reason is that cgroupbpfattach overwrites pl->storage with the new storage prior to attachment completion. When attachment fails midway, the cleanup path calls bpfcgroupstoragesfree(newstorage) to free the newly allocated storage, but fails to restore pl->storage back to oldstorage.
Consequently, the still-active prog1 holds invalid or dangling storage pointers, leading to an invalid memory access when prog1 executes and calls bpfgetlocalstorage. Additionally, original pl->flags and cgrp->bpf.flags[atype] are left unrestored.
Fix this by saving oldplflags, oldstorage, and oldflags prior to the update, and properly restoring all of them in the cleanup path on error.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the invalid storage access?
A cgroup BPF program with local storage must be attached in multi-attach mode, then replaced using BPF_F_REPLACE in multi-attach mode. The replacement must fail after storage has been overwritten but before attachment completes, and a subsequent program must then be attached in multi-attach mode.
What happens after the failed replacement?
The previously active program can retain dangling pointers to storage that was freed during cleanup. If that program later executes and calls bpf_get_local_storage, it can perform an invalid memory access.
Are configuration flags also affected by the failed attach cleanup?
Yes. The original program-link flags and the cgroup attachment-type flags may remain unrestored after the failed replacement attempt.