// For flags

CVE-2021-46984

kyber: fix out of bounds access when preempted

Severity Score

6.0
*CVSS v3.1

Exploit Likelihood

*EPSS

Affected Versions

*CPE

Public Exploits

0
*Multiple Sources

Exploited in Wild

-
*KEV

Decision

Track
*SSVC
Descriptions

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

kyber: fix out of bounds access when preempted

__blk_mq_sched_bio_merge() gets the ctx and hctx for the current CPU and
passes the hctx to ->bio_merge(). kyber_bio_merge() then gets the ctx
for the current CPU again and uses that to get the corresponding Kyber
context in the passed hctx. However, the thread may be preempted between
the two calls to blk_mq_get_ctx(), and the ctx returned the second time
may no longer correspond to the passed hctx. This "works" accidentally
most of the time, but it can cause us to read garbage if the second ctx
came from an hctx with more ctx's than the first one (i.e., if
ctx->index_hw[hctx->type] > hctx->nr_ctx).

This manifested as this UBSAN array index out of bounds error reported
by Jakub:

UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9
index 13106 is out of range for type 'long unsigned int [128]'
Call Trace:
dump_stack+0xa4/0xe5
ubsan_epilogue+0x5/0x40
__ubsan_handle_out_of_bounds.cold.13+0x2a/0x34
queued_spin_lock_slowpath+0x476/0x480
do_raw_spin_lock+0x1c2/0x1d0
kyber_bio_merge+0x112/0x180
blk_mq_submit_bio+0x1f5/0x1100
submit_bio_noacct+0x7b0/0x870
submit_bio+0xc2/0x3a0
btrfs_map_bio+0x4f0/0x9d0
btrfs_submit_data_bio+0x24e/0x310
submit_one_bio+0x7f/0xb0
submit_extent_page+0xc4/0x440
__extent_writepage_io+0x2b8/0x5e0
__extent_writepage+0x28d/0x6e0
extent_write_cache_pages+0x4d7/0x7a0
extent_writepages+0xa2/0x110
do_writepages+0x8f/0x180
__writeback_single_inode+0x99/0x7f0
writeback_sb_inodes+0x34e/0x790
__writeback_inodes_wb+0x9e/0x120
wb_writeback+0x4d2/0x660
wb_workfn+0x64d/0xa10
process_one_work+0x53a/0xa80
worker_thread+0x69/0x5b0
kthread+0x20b/0x240
ret_from_fork+0x1f/0x30

Only Kyber uses the hctx, so fix it by passing the request_queue to
->bio_merge() instead. BFQ and mq-deadline just use that, and Kyber can
map the queues itself to avoid the mismatch.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: kyber: corrige el acceso fuera de los límites cuando se adelanta __blk_mq_sched_bio_merge() obtiene el ctx y el hctx para la CPU actual y pasa el hctx a ->bio_merge(). kyber_bio_merge() luego obtiene nuevamente el ctx para la CPU actual y lo usa para obtener el contexto Kyber correspondiente en el hctx pasado. Sin embargo, el hilo puede ser reemplazado entre las dos llamadas a blk_mq_get_ctx(), y es posible que el ctx devuelto la segunda vez ya no corresponda al hctx pasado. Esto "funciona" accidentalmente la mayor parte del tiempo, pero puede hacer que leamos basura si el segundo ctx proviene de un hctx con más ctx que el primero (es decir, si ctx->index_hw[hctx->type] > hctx- >nr_ctx). Esto se manifestó como este error de índice de matriz UBSAN fuera de los límites informado por Jakub: UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9 index 13106 is out of range for type ' long unsigned int [128]' Seguimiento de llamadas: dump_stack+0xa4/0xe5 ubsan_epilogue+0x5/0x40 __ubsan_handle_out_of_bounds.cold.13+0x2a/0x34 queued_spin_lock_slowpath+0x476/0x480 do_raw_spin_lock+0x1c2/0x1d0 kyber_bio_ fusionar+0x112/0x180 blk_mq_submit_bio+0x1f5/0x1100 submit_bio_noacct +0x7b0/0x870 submit_bio+0xc2/0x3a0 btrfs_map_bio+0x4f0/0x9d0 btrfs_submit_data_bio+0x24e/0x310 submit_one_bio+0x7f/0xb0 submit_extent_page+0xc4/0x440 __extent_writepage_io+0x2b8/0x5e0 __ extensión_writepage+0x28d/0x6e0 extensión_write_cache_pages+0x4d7/0x7a0 extensión_writepages+0xa2/0x110 do_writepages +0x8f/0x180 __writeback_single_inode+0x99/0x7f0 writeback_sb_inodes+0x34e/0x790 __writeback_inodes_wb+0x9e/0x120 wb_writeback+0x4d2/0x660 wb_workfn+0x64d/0xa10 Process_one_work+0x53a/0xa80 work_thread+0x69/0x5b0 kthread+0x20b/0x240 ret_from_fork+0x1f/0x30 solamente Kyber usa hctx, así que solucionelo pasando request_queue a ->bio_merge() en su lugar. BFQ y mq-deadline simplemente usan eso, y Kyber puede mapear las colas él mismo para evitar discrepancias.

*Credits: N/A
CVSS Scores
Attack Vector
Local
Attack Complexity
Low
Privileges Required
High
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
High
* Common Vulnerability Scoring System
SSVC
  • Decision:Track
Exploitation
None
Automatable
No
Tech. Impact
Partial
* Organization's Worst-case Scenario
Timeline
  • 2024-02-27 CVE Reserved
  • 2024-02-28 CVE Published
  • 2024-02-29 EPSS Updated
  • 2024-09-11 CVE Updated
  • ---------- Exploited in Wild
  • ---------- KEV Due Date
  • ---------- First Exploit
CWE
  • CWE-125: Out-of-bounds Read
CAPEC
Affected Vendors, Products, and Versions
Vendor Product Version Other Status
Vendor Product Version Other Status <-- --> Vendor Product Version Other Status
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 4.18 < 5.4.120
Search vendor "Linux" for product "Linux Kernel" and version " >= 4.18 < 5.4.120"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 4.18 < 5.10.38
Search vendor "Linux" for product "Linux Kernel" and version " >= 4.18 < 5.10.38"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 4.18 < 5.11.22
Search vendor "Linux" for product "Linux Kernel" and version " >= 4.18 < 5.11.22"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 4.18 < 5.12.5
Search vendor "Linux" for product "Linux Kernel" and version " >= 4.18 < 5.12.5"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 4.18 < 5.13
Search vendor "Linux" for product "Linux Kernel" and version " >= 4.18 < 5.13"
en
Affected