In the Linux kernel, the following vulnerability has been resolved:
bfq: Avoid merging queues with different parents
It can happen that the parent of a bfqq changes between the moment we decide two queues are worth to merge (and set bic->stablemergebfqq) and the moment bfqsetupmerge() is called. This can happen e.g. because the process submitted IO for a different cgroup and thus bfqq got reparented. It can even happen that the bfqq we are merging with has parent cgroup that is already offline and going to be destroyed in which case the merge can lead to use-after-free issues such as:
BUG: KASAN: use-after-free in _bfqdeactivate_entity+0x9cb/0xa50 Read of size 8 at addr ffff88800693c0c0 by task runc:[2:INIT]/10544
CPU: 0 PID: 10544 Comm: runc:[2:INIT] Tainted: G E 5.15.2-0.g5fb85fd-default #1 openSUSE Tumbleweed (unreleased) f1f3b891c72369aebecd2e43e4641a6358867c70 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014 Call Trace: <IRQ> dumpstacklvl+0x46/0x5a printaddressdescription.constprop.0+0x1f/0x140 ? _bfqdeactivateentity+0x9cb/0xa50 kasanreport.cold+0x7f/0x11b ? _bfqdeactivateentity+0x9cb/0xa50 _bfqdeactivateentity+0x9cb/0xa50 ? updatecurr+0x32f/0x5d0 bfqdeactivateentity+0xa0/0x1d0 bfqdelbfqqbusy+0x28a/0x420 ? reschedcurr+0x116/0x1d0 ? bfqrequeuebfqq+0x70/0x70 ? checkpreemptwakeup+0x52b/0xbc0 _bfqbfqqexpire+0x1a2/0x270 bfqbfqqexpire+0xd16/0x2160 ? trytowakeup+0x4ee/0x1260 ? bfqendwrasyncqueues+0xe0/0xe0 ? _rawwriteunlockbh+0x60/0x60 ? rawspinlockirq+0x81/0xe0 bfqidleslicetimer+0x109/0x280 ? bfqdispatchrequest+0x4870/0x4870 _hrtimerrunqueues+0x37d/0x700 ? enqueuehrtimer+0x1b0/0x1b0 ? kvmclockgetcycles+0xd/0x10 ? ktimegetupdateoffsetsnow+0x6f/0x280 hrtimer_interrupt+0x2c8/0x740
Fix the problem by checking that the parent of the two bfqqs we are merging in bfqsetupmerge() is the same.