Look up another CVE · open CVE-2026-63802 in the interactive tracker
CVE-2026-63802
blk-cgroup: fix UAF in __blkcg_rstat_flush()
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem block. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-63802 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 | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | fixed | 6.12.95-1 | Update the kernel and reboot. Fixed in 6.12.95-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.3-1 | Update the kernel and reboot. Fixed in 7.1.3-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.3-1 | Update the kernel and reboot. Fixed in 7.1.3-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
When multiple blkgs in the same blkcg are released concurrently, a use-after-free can occur. The race happens when one blkg's __blkcg_rstat_flush() removes another blkg's iostat entries via llist_del_all(). The second blkg sees an empty list and proceeds to free itself while the first is still iterating over its entries. Move the flush from __blkg_release() (RCU callback) to blkg_release() (before call_rcu). This ensures the RCU grace period waits for any concurrent flush's rcu_read_lock() section to complete before freeing.
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-07-19 (3 months 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.13%, higher than 2.5% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- 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.4 | 6.6.144 | 96e545410c4f |
| 6.4 | 6.12.95 | bbebd9425cad |
| 6.4 | 6.18.38 | 5e5b7f2ef854 |
| 6.4 | 7.1.3 | afebe44facc4 |
| 6.4 | 7.2 | 0ab5ee5a1bad |
| 6.3.9 | 0 | 0 |
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
- Exploitation requires local cgroup management (rmdir on cgroupfs) and concurrent block I/O to populate per-blkcg rstat lists; the vulnerable code is in the block cgroup teardown path, not in any network protocol handler.
- AC:LAttack complexity, low
- The attacker controls both sides of the race by issuing I/O on multiple block devices to create multiple blkgs with pending stats, then concurrently destroying the cgroup to trigger parallel blkg_release() calls on multiple CPUs.
- PR:LPrivileges required, low
- Triggering cgroup deletion and block I/O requires only delegated cgroup write access or namespace/container root (CAP_SYS_ADMIN in a user namespace), not init-namespace root; this is routinely available in containers, Kubernetes pods, and systemd user cgroup hierarchies.
- UI:NUser interaction, none
- No victim interaction is required; the attacker programmatically performs I/O and cgroup teardown from their own process or container.
- S:UScope, unchanged
- The UAF corrupts kernel heap memory within the same kernel security domain; it does not inherently cross a VM, container, or IOMMU boundary without a separate privilege-escalation step.
- C:HConfidentiality impact, high
- The use-after-free dereferences freed blkg structures and associated iostat data during list iteration, enabling arbitrary kernel memory read primitives typical of slab UAF bugs.
- I:HIntegrity impact, high
- UAF on kmalloc-allocated blkg objects allows heap grooming and write through dangling pointers, which can be leveraged for arbitrary kernel memory modification or code execution.
- A:HAvailability impact, high
- Concurrent use-after-free during blkg teardown can cause immediate kernel oops/panic from accessing freed memory, and repeated triggering enables reliable denial of service.