Look up another CVE · open CVE-2026-90326 in the interactive tracker
CVE-2026-90326
blk-cgroup: fix race between policy activation and blkg destruction
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem block. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-90326 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
When switching an IO scheduler on a block device, blkcg_activate_policy() allocates blkg_policy_data (pd) for all blkgs attached to the queue. However, blkcg_activate_policy() may race with concurrent blkcg deletion, leading to use-after-free and memory leak issues. The use-after-free occurs in the following race: T1 (blkcg_activate_policy): - Successfully allocates pd for blkg1 (loop0->queue, blkcgA) - Fails to allocate pd for blkg2 (loop0->queue, blkcgB) - Enters the enomem rollback path to release blkg1 resources T2 (blkcg deletion): - blkcgA is deleted concurrently - blkg1 is freed via blkg_free_workfn() - blkg1->pd is freed T1 (continued): - Rollback path accesses blkg1->pd->online after pd is freed - Triggers use-after-free In addition, blkg_free_workfn() frees pd before removing the blkg from q->blkg_list. This allows blkcg_activate_policy() to allocate a new pd for a blkg that is being destroyed, leaving the newly allocated pd unreachable when the blkg is finally freed. Fix these races by extending blkcg_mutex coverage to serialize blkcg_activate_policy() rollback and blkg destruction, ensuring pd lifecycle is synchronized with blkg list visibility.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
block/blk-cgroup.c
- What this is
- CONTROL GROUP - BLOCK IO CONTROLLER (BLKIO)MAINTAINERS section matched on block/blk-cgroup.c · cgroups@vger.kernel.org
Check it on the machine
grep -w CONFIG_BLK_CGROUP /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switch
- CONFIG_BLK_CGROUP
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-17 (31 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 6.0% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- block
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.1.16 | 6.1.17 | b5dae1cd0d83 |
| 6.2.3 | 6.2.4 | 083b58373463 |
| 6.3 | 6.18.52 | ac34e655dffa |
| 6.3 | 7.2.6 | 2cf9f50a38c1 |
| 6.3 | 7.3 | 5313d4d41739 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The triggering operations are local cgroupfs writes: tg_set_limit() (io.max) or iolatency_set_limit() (io.latency) call blk_throtl_init()/blk_iolatency_init() then blkcg_activate_policy(), while cgroup_rmdir() runs blkcg_css_offline() into blkg_free_workfn(); elv_iosched_store() is an alternate local sysfs path. No remote protocol carries the race inputs.
- AC:LAttack complexity, low
- The attacker drives both sides: one thread writes io.max/io.latency so blkcg_activate_policy() attaches pd without q->blkcg_mutex, while another rmdirs sibling blkcgs so blkg_free_workfn() calls pd_free_fn() on the same blkg->pd[] before list_del. That interleaving does not depend on GFP_KERNEL failure; the documented enomem rollback UAF on pd->online is an extra window the attacker can retry.
- PR:LPrivileges required, low
- tg_set_limit() and iolatency_set_limit() have no capable() check; io.max/io.latency are CFTYPE_NOT_ON_ROOT S_IWUSR files, and blkg_conf_open_bdev() uses blkdev_get_no_open() with no device permission check. A delegated cgroup-v2 subtree owner (typical systemd user slice or rootless container) can write those files and rmdir child cgroups; scheduler sysfs is a stricter alternate path.
- UI:NUser interaction, none
- The attacker writes io.max/io.latency in cgroups they own and rmdirs those cgroups themselves; no other user must mount a device, open a file, or otherwise participate.
- S:UScope, unchanged
- The UAF corrupts kernel blkg_policy_data (throtl_grp/iolatency_grp) in the host io controller; impact stays in the kernel's authority and does not cross a VM, IOMMU, or other security boundary.
- C:HConfidentiality impact, high
- blkg_free_workfn() frees blkg->pd[] while the object remains on q->blkg_list, so blkcg_activate_policy()'s enomem path reads pd->online and pd_offline_fn() (throtl_pd_offline()/tg_flush_bios()) walks the freed throtl_grp; spraying the slab reclaims that object for an arbitrary kernel read.
- I:HIntegrity impact, high
- The same freed pd is written (pd->online = false) and passed to pol->pd_free_fn() again (throtl_pd_free() does timer_delete_sync() and call_rcu()), a double-free of throtl_grp/iolatency_grp that yields a kernel write/control-flow primitive.
- A:HAvailability impact, high
- Use-after-free and double-free of blkg_policy_data in blkcg_activate_policy() versus blkg_free_workfn() oops/panic the kernel even when not turned into a full memory primitive.