CVE-2022-50488 in Linux
Zusammenfassung
von VulDB • 30.05.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
block, bfq: Behebung eines möglichen Use-After-Free (UAF) für 'bfqq->bic'
Unser Testbericht meldet einen Use-After-Free (UAF) für 'bfqq->bic' in Version 5.10:
================================================================== BUG: KASAN: use-after-free in bfq_select_queue+0x378/0xa30
CPU: 6 PID: 2318352 Comm: fsstress Kdump: geladen Nicht tainted 5.10.0-60.18.0.50.h602.kasan.eulerosv2r11.x86_64 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-20220320_160524-szxrtosci10000 04/01/2014 Call Trace: bfq_select_queue+0x378/0xa30 bfq_dispatch_request+0xe8/0x130 blk_mq_do_dispatch_sched+0x62/0xb0 __blk_mq_sched_dispatch_requests+0x215/0x2a0 blk_mq_sched_dispatch_requests+0x8f/0xd0 __blk_mq_run_hw_queue+0x98/0x180 __blk_mq_delay_run_hw_queue+0x22b/0x240 blk_mq_run_hw_queue+0xe3/0x190 blk_mq_sched_insert_requests+0x107/0x200 blk_mq_flush_plug_list+0x26e/0x3c0 blk_finish_plug+0x63/0x90 __iomap_dio_rw+0x7b5/0x910 iomap_dio_rw+0x36/0x80 ext4_dio_read_iter+0x146/0x190 [ext4]
ext4_file_read_iter+0x1e2/0x230 [ext4]
new_sync_read+0x29f/0x400 vfs_read+0x24e/0x2d0 ksys_read+0xd5/0x1b0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6
Der Commit 3bc5e683c67d ("bfq: Split shared queues on move between cgroups") ändert das Verhalten so, dass beim Verschieben eines Prozesses in eine neue cgroup eine neue bfqq zugewiesen wird. Allerdings können die alte bfqq und die neue bfqq auf dieselbe bic verweisen:
1) Anfangszustand: Zwei Prozesse mit E/A im selben cgroup.
Prozess 1 Prozess 2 (BIC1) (BIC2) | Λ | Λ | | | | V | V | bfqq1 bfqq2
2) bfqq1 wird mit bfqq2 zusammengeführt.
Prozess 1 Prozess 2 (BIC1) (BIC2) | | \-------------\| V bfqq1 bfqq2(coop)
3) Prozess 1 beendet sich, dann gibt Prozess 2 neue E/A aus (dequeue IOA).
(BIC2) | Λ | | V | bfqq2(coop)
4) Vor Abschluss der IOA wird Prozess 2 in eine andere cgroup verschoben und E/A ausgegeben.
Prozess 2 (BIC2) Λ |\--------------\ | V bfqq2 bfqq3
Nun zeigt BIC2 auf bfqq3, während bfqq2 und bfqq3 beide auf BIC2 verweisen. Wenn alle Anfragen abgeschlossen sind und Prozess 2 sich beendet, wird BIC2 freigegeben, ohne dass garantiert ist, dass bfqq2 vor BIC2 freigegeben wird.
Das Problem wird behoben, indem bfqq->bic gelöscht wird, während bfqq von bic getrennt wird.
If you want to get best quality of vulnerability data, you may have to visit VulDB.