CVE-2026-90325

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 UAF is reached by writing the local sysfs file /sys/block/<dev>/queue/scheduler (elv_iosched_store → elevator_switch → bfq_create_group_hierarchy → blkcg_activate_policy) or by writing the local cgroup files io.max (tg_set_limit → blk_throtl_init) or io.latency (iolatency_set_limit → blk_iolatency_init). No remote protocol carries the triggering state.

AC:LAttack complexity, low

The attacker drives both sides: one thread writes io.max/io.latency or queue/scheduler so blkcg_activate_policy() takes the GFP_NOWAIT-fail retry and calls blkg_get() on a q->blkg_list entry, while another rmdirs a sibling io cgroup so blkcg_css_offline() → blkg_destroy() kills that blkg's percpu_ref. The mkdir/write/rmdir cycle can be repeated until the window hits.

PR:LPrivileges required, low

cgroup_add_file() creates io.max and io.latency with mode 0644 and current_fsuid(), so an unprivileged user who mkdir's in a delegated cgroup v2 subtree (systemd user@.service, rootless containers) can write those files and rmdir the cgroup. tg_set_limit()/iolatency_set_limit() have no capability check, and blkg_conf_open_bdev() looks up the disk by MAJ:MIN via blkdev_get_no_open() without opening it.

UI:NUser interaction, none

The attacker performs the mkdir, the io.max/io.latency or scheduler write that enters blkcg_activate_policy(), and the concurrent rmdir that runs blkg_destroy(), all from its own processes; no other user must mount a device or open a file.

S:UScope, unchanged

Double call_rcu on blkg->rcu_head corrupts host-kernel RCU callback lists and the slab-backed blkcg_gq. That stays inside the same kernel security authority and is not a VM, IOMMU, or hypervisor escape.

C:HConfidentiality impact, high

blkcg_activate_policy() calls blkg_get() (percpu_ref_get, not tryget) on a blkg whose refcnt blkg_destroy() already killed, resurrecting it; the matching blkg_put() after mutex_unlock races blkg_free_workfn()'s kfree(blkg) and issues a second call_rcu on the same rcu_head, which the report shows as a UAF in rcu_accelerate_cbs. A UAF on the RCU list and blkcg_gq is an arbitrary kernel-memory read.

I:HIntegrity impact, high

The second call_rcu(&blkg->rcu_head) from the resurrected blkg_put() corrupts the RCU callback list (rcu_accelerate_cbs) while blkg_free_workfn() still does list_del_init() and pd_free_fn() on that object. Those writes through a freed, sprayable blkcg_gq are a kernel write primitive suitable for control-flow hijack.

A:HAvailability impact, high

The commit documents a use-after-free in rcu_accelerate_cbs from the second call_rcu on blkg->rcu_head after blkg_get() resurrects a killed ref; that UAF oopses or panics the kernel even if it is not further exploited.