CVE-2026-90313
NoneCVSS
—
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel can let a specially crafted sequence of network or security program attachments leave behind bad memory references, potentially crashing the system or allowing misuse.
- Exploitation
- Local Privilege
- Attacker needs
- High Privilege
- Complexity
- High
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Use After Free
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Use-after-free in Linux kernel cgroup BPF attachment logic where a failed multi-attach replace operation leaves dangling storage pointers in an active program, causing invalid memory access on subsequent bpf_get_local_storage calls.
Why it matters to the business
Kernel instability, crashes, or potential code execution on Linux systems running affected kernels when BPF cgroup programs are attached and replaced under failure conditions, increasing operational risk for containerized or networking workloads.
How an attack unfolds
An attacker with sufficient privileges to load and attach BPF programs triggers a partial failure during prog replacement in multi-attach mode, leaving the prior program with invalid storage; later execution of that program dereferences the freed pointer.
How to fix it
Update to a kernel version containing the fix that saves and restores old_pl_flags, old_storage, and old_flags on error paths in __cgroup_bpf_attach.
How to confirm the fix worked
Confirm kernel source includes the restoration logic for storage and flags in the cgroup BPF attach error path; test attach/replace sequences that previously failed midway.
Typical attack path
- Obtain CAP_BPF or equivalent privileges to load cgroup-attached BPF programs
- Attach prog1 with storage in multi-attach mode
- Initiate replace with prog2 using BPF_F_REPLACE and force failure in bpf_trampoline_link_cgroup_shim or update_effective_progs
- Attach prog3 to trigger cleanup that frees new storage without restoring old pointers
- Execute prog1 to dereference dangling storage via bpf_get_local_storage
How to detect it
Review kernel logs for oops/panic messages mentioning bpf_cgroup_storages_free or invalid access during cgroup BPF operations; inspect audit logs for sequences of BPF_PROG_ATTACH and BPF_PROG_REPLACE syscalls that fail partway.
What your security team should do
- Prioritize kernel updates on systems exposing BPF cgroup attach functionality
- Restrict untrusted BPF program loading via LSM or capability controls until patched
- Monitor for kernel oops or warnings related to cgroup bpf storage during program attach operations
The record
In the Linux kernel, the following vulnerability has been resolved: bpf, cgroup: Fix invalid storage access after __cgroup_bpf_attach 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 BPF_F_REPLACE in multi-attach mode, but fails midway (e.g. in bpf_trampoline_link_cgroup_shim or update_effective_progs). 3. A new prog3 is attached to the cgroup in multi-attach mode. The reason is that __cgroup_bpf_attach overwrites pl->storage with the new storage prior to attachment completion. When attachment fails midway, the cleanup path calls bpf_cgroup_storages_free(new_storage) to free the newly allocated storage, but fails to restore pl->storage back to old_storage. Consequently, the still-active prog1 holds invalid or dangling storage pointers, leading to an invalid memory access when prog1 executes and calls bpf_get_local_storage. Additionally, original pl->flags and cgrp->bpf.flags[atype] are left unrestored. Fix this by saving old_pl_flags, old_storage, and old_flags prior to the update, and properly restoring all of them in the cleanup path on error.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|