CVE-2025-68178: blk-cgroup: fix possible deadlock while configuring policy

In the Linux kernel, the following vulnerability has been resolved:

blk-cgroup: fix possible deadlock while configuring policy

Following deadlock can be triggered easily by lockdep:

WARNING: possible circular locking dependency detected 6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted ------------------------------------------------------ check/1334 is trying to acquire lock: ff1100011d9d0678 (&q->sysfslock){+.+.}-{4:4}, at: blkunregisterqueue+0x53/0x180

but task is already holding lock: ff1100011d9d00e0 (&q->qusagecounter(queue)#3){++++}-{0:0}, at: delgendisk+0xba/0x110

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (&q->qusagecounter(queue)#3){++++}-{0:0}: blkqueueenter+0x40b/0x470 blkgconfprep+0x7b/0x3c0 tgsetlimit+0x10a/0x3e0 cgroupfilewrite+0xc6/0x420 kernfsfopwriteiter+0x189/0x280 vfswrite+0x256/0x490 ksyswrite+0x83/0x190 x64syswrite+0x21/0x30 x64syscall+0x4608/0x4630 dosyscall64+0xdb/0x6b0 entrySYSCALL64afterhwframe+0x76/0x7e

-> #1 (&q->rqqosmutex){+.+.}-{4:4}: mutexlock+0xd8/0xf50 mutexlocknested+0x2b/0x40 wbtinit+0x17e/0x280 wbtenabledefault+0xe9/0x140 blkregisterqueue+0x1da/0x2e0 adddisk+0x38c/0x5d0 adddiskfwnode+0x89/0x250 deviceadddisk+0x18/0x30 virtblkprobe+0x13a3/0x1800 virtiodevprobe+0x389/0x610 reallyprobe+0x136/0x620 driverprobedevice+0xb3/0x230 driverprobedevice+0x2f/0xe0 driverattach+0x158/0x250 busforeachdev+0xa9/0x130 driverattach+0x26/0x40 busadddriver+0x178/0x3d0 driverregister+0x7d/0x1c0 registervirtiodriver+0x2c/0x60 virtioblkinit+0x6f/0xe0 dooneinitcall+0x94/0x540 kernelinitfreeable+0x56a/0x7b0 kernelinit+0x2b/0x270 retfromfork+0x268/0x4c0 retfromforkasm+0x1a/0x30

-> #0 (&q->sysfslock){+.+.}-{4:4}: lockacquire+0x1835/0x2940 lockacquire+0xf9/0x450 mutexlock+0xd8/0xf50 mutexlocknested+0x2b/0x40 blkunregisterqueue+0x53/0x180 delgendisk+0x226/0x690 delgendisk+0xba/0x110 sdremove+0x49/0xb0 [sdmod] deviceremove+0x87/0xb0 devicereleasedriverinternal+0x11e/0x230 devicereleasedriver+0x1a/0x30 busremovedevice+0x14d/0x220 devicedel+0x1e1/0x5a0 scsiremovedevice+0x1ff/0x2f0 scsiremovedevice+0x37/0x60 sdevstoredelete+0x77/0x100 devattrstore+0x1f/0x40 sysfskfwrite+0x65/0x90 kernfsfopwriteiter+0x189/0x280 vfswrite+0x256/0x490 ksyswrite+0x83/0x190 x64syswrite+0x21/0x30 x64syscall+0x4608/0x4630 dosyscall64+0xdb/0x6b0 entrySYSCALL64afterhwframe+0x76/0x7e

other info that might help us debug this:

Chain exists of: &q->sysfslock --> &q->rqqosmutex --> &q->qusagecounter(queue)#3

Possible unsafe locking scenario:

CPU0 CPU1 ---- ---- lock(&q->qusagecounter(queue)#3); lock(&q->rqqosmutex); lock(&q->qusagecounter(queue)#3); lock(&q->sysfslock);

Root cause is that queueusagecounter is grabbed with rqqosmutex held in blkgconfprep(), while queue should be freezed before rqqosmutex from other context.

The blkqueueenter() from blkgconfprep() is used to protect against policy deactivation, which is already protected with blkcgmutex, hence convert blkqueueenter() to blkcgmutex to fix this problem. Meanwhile, consider that blkcgmutex is held after queue is freezed from policy deactivation, also convert blkgalloc() to use GFPNOIO.