blk-cgroup: fix race between policy activation and blkg destruction
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 6.1.17, 6.2.4, 6.6.160, 6.12.114, 6.18.52, and 1 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix race between policy activation and blkg destruction 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.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From 81c1188905f88b77743d1fdeeedfc8cb7b67787d · fixed in b5dae1cd0d8368b4338430ff93403df67f0b8bcc; From bfe46d2efe46c5c952f982e2ca94fe2ec5e58e2a · fixed in 083b58373463a6e5ee60ecb135269348f68ad7df; From f1c006f1c6850c14040f8337753a63119bba39b9 · fixed in 17c18a0df70c2b89ff7fcd74622f1540e98d00fd; From f1c006f1c6850c14040f8337753a63119bba39b9 · fixed in 91062e3a9ed251726df4e20ff9a1113f1c8ded59; From f1c006f1c6850c14040f8337753a63119bba39b9 · fixed in ac34e655dffa74349d885a43d098115336f53842; From f1c006f1c6850c14040f8337753a63119bba39b9 · fixed in 2cf9f50a38c1839e549a08e22aa35e8d69e2c8fd; From f1c006f1c6850c14040f8337753a63119bba39b9 · fixed in 5313d4d41739b0cb63000747c97bb1217ac45f3e; From 6.1.16 · fixed in 6.1.17; From 6.2.3 · fixed in 6.2.4
- Linux Linux
6.3
- KernelLinux
fixed in 6.1.17; From 6.2.0 · fixed in 6.2.4; From 6.3.0 · fixed in 6.6.160; fixed in 6.12.114; From 6.7.0 · fixed in 6.18.52; From 6.13.0 · fixed in 7.2.6
References 7
git.kernel.org
- stable/c/b5dae1cd0d8368b4338430ff93403df67f0b8bcc
- stable/c/083b58373463a6e5ee60ecb135269348f68ad7df
- stable/c/17c18a0df70c2b89ff7fcd74622f1540e98d00fd
- stable/c/91062e3a9ed251726df4e20ff9a1113f1c8ded59
- stable/c/ac34e655dffa74349d885a43d098115336f53842
- stable/c/2cf9f50a38c1839e549a08e22aa35e8d69e2c8fd
- stable/c/5313d4d41739b0cb63000747c97bb1217ac45f3e