[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"repo-stars":3,"vuln-DEBIAN-CVE-2021-46984":6},{"stargazers_count":4,"fetched_at":5},7,"2026-06-04T08:53:30.047Z",{"id":7,"descriptions":8,"cisa":9,"weaknesses":10,"exploits":11,"aliases":12,"duplicate_of":9,"upstream":13,"downstream":16,"duplicates":17,"related":18,"reserved_at":9,"published_at":19,"modified_at":20,"state":9,"summary":21,"references_raw":23,"kevs":30,"epss":9,"epss_history":31,"metrics":32,"affected":39},"DEBIAN-CVE-2021-46984","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.",null,[],[],[],[14],{"_key":15},"CVE-2021-46984",[],[],[],"2024-02-28T09:15:37.450Z","2026-04-28T20:23:16.260890Z",{"cisa_kev":22,"cisa_ransomware":22,"cisa_vendor":9,"epss_severity":9,"epss_score":9,"severity":9,"severity_score":9,"severity_version":9,"severity_source":9,"severity_vector":9,"severity_status":9},false,[24],{"url":25,"sources":26,"tags":28},"https://security-tracker.debian.org/tracker/CVE-2021-46984",[27],"osv_debian",[29],"Advisory",[],[],[33],{"source":27,"cvss_v2_0":9,"cvss_v3_0":9,"cvss_v3_1":34,"cvss_v4_0":9},{"baseScore":35,"baseSeverity":9,"vectorString":36,"impactScore":37,"exploitabilityScore":38},7.8,"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",9.8,4.6,[40],{"ecosystem":41,"name":42,"vendor":43,"product":42,"cpe_part":9,"purl_type":44,"purl_namespace":43,"purl_name":42,"source":9,"versions":45},"Debian","linux","debian","deb",[46,52,53,54],{"version":47,"is_range":48,"range_type":49,"version_start":9,"version_start_type":9,"version_end":50,"version_end_type":51,"fixed_in":9},"lt5_10_38_1",true,"ecosystem","5.10.38-1","excluding",{"version":47,"is_range":48,"range_type":49,"version_start":9,"version_start_type":9,"version_end":50,"version_end_type":51,"fixed_in":9},{"version":47,"is_range":48,"range_type":49,"version_start":9,"version_start_type":9,"version_end":50,"version_end_type":51,"fixed_in":9},{"version":47,"is_range":48,"range_type":49,"version_start":9,"version_start_type":9,"version_end":50,"version_end_type":51,"fixed_in":9}]