Answer in brief
CVE-2022-50488 records a High severity (CVSS 7.8) vulnerability in block, bfq: fix possible uaf for 'bfqq->bic'. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Product | Affected versions | Fixed versions |
|---|---|---|
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | Not reported | Not reported |
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=4dfc12f8c94c8052e975060f595938f75e8b7165 <5533742c7cb1bc9b1f0bf401cc397d44a3a9e07a || >=81b7d0c717a487ec50e2924a773ff501ee40f0d5 <094f3d9314d67691cb21ba091c1b528f6e3c4893 || >=3bc5e683c67d94bd839a1da2e796c15847b51b69 <b22fd72bfebda3956efc4431b60ddfc0a51e03e0 || >=3bc5e683c67d94bd839a1da2e796c15847b51b69 <761564d93c8265f65543acf0a576b32d66bfa26a || >=3bc5e683c67d94bd839a1da2e796c15847b51b69 <64dc8c732f5c2b406cc752e6aaa1bd5471159cab || 31326bf551269fb9bafa84ca99172b8340e5d8f8 || 43c51b86dbe551cff5d39b88aa2f41d29479f9c4 || 8615f6c0c9e7cf0ca90b6b5408784d797cbe5621 || >=5.10.121 <5.10.175 || >=5.15.46 <5.15.86 || >=5.4.198 <5.5 || >=5.17.14 <5.18 || >=5.18.3 <5.19 | 5533742c7cb1bc9b1f0bf401cc397d44a3a9e07a, 094f3d9314d67691cb21ba091c1b528f6e3c4893, b22fd72bfebda3956efc4431b60ddfc0a51e03e0, 761564d93c8265f65543acf0a576b32d66bfa26a, 64dc8c732f5c2b406cc752e6aaa1bd5471159cab, 5.10.175, 5.15.86, 5.5, 5.18, 5.19 |
| Linux/Linuxgeneric | 5.19 | Not reported |
Published upstream
Oct 4, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 4, 2026
In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible uaf for 'bfqq->bic' Our test report a uaf for 'bfqq->bic' in 5.10: ================================================================== BUG: KASAN: use-after-free in bfq_select_queue+0x378/0xa30 CPU: 6 PID: 2318352 Comm: fsstress Kdump: loaded Not 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 Commit 3bc5e683c67d ("bfq: Split shared queues on move between cgroups") changes that move process to a new cgroup will allocate a new bfqq to use, however, the old bfqq and new bfqq can point to the same bic: 1) Initial state, two process with io in the same cgroup. Process 1 Process 2 (BIC1) (BIC2) | Λ | Λ | | | | V | V | bfqq1 bfqq2 2) bfqq1 is merged to bfqq2. Process 1 Process 2 (BIC1) (BIC2) | | \-------------\| V bfqq1 bfqq2(coop) 3) Process 1 exit, then issue new io(denoce IOA) from Process 2. (BIC2) | Λ | | V | bfqq2(coop) 4) Before IOA is completed, move Process 2 to another cgroup and issue io. Process 2 (BIC2) Λ |\--------------\ | V bfqq2 bfqq3 Now that BIC2 points to bfqq3, while bfqq2 and bfqq3 both point to BIC2. If all the requests are completed, and Process 2 exit, BIC2 will be freed while there is no guarantee that bfqq2 will be freed before BIC2. Fix the problem by clearing bfqq->bic while bfqq is detached from bic.
Quoted source text, attributed separately from HOL analysis.