Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2022-50084 State: PUBLISHED Published: 2025-06-18T11:02:25.998Z Last Updated: 2025-06-18T11:02:25.998Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dm raid: fix address sanitizer warning in raid_status There is this warning when using a kernel with the address sanitizer and running this testsuite: https://gitlab.com/cki-project/kernel-tests/-/tree/main/storage/swraid/scsi_raid ================================================================== BUG: KASAN: slab-out-of-bounds in raid_status+0x1747/0x2820 [dm_raid] Read of size 4 at addr ffff888079d2c7e8 by task lvcreate/13319 CPU: 0 PID: 13319 Comm: lvcreate Not tain
x2820 [dm_raid] Read of size 4 at addr ffff888079d2c7e8 by task lvcreate/13319 CPU: 0 PID: 13319 Comm: lvcreate Not tainted 5.18.0-0.rc3.<snip> #1 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 Call Trace: <TASK> dump_stack_lvl+0x6a/0x9c print_address_description.constprop.0+0x1f/0x1e0 print_report.cold+0x55/0x244 kasan_report+0xc9/0x100 raid_status+0x1747/0x2820 [dm_raid] dm_ima_measure_on_table_load+0x4b8/0xca0 [dm_mod] table_load+0x35c/0x630 [dm_mod] ctl_ioctl+0x411/0x630 [dm_mod] dm_ctl_ioctl+0xa/0x10 [dm_mod] __x64_sys_ioctl+0x12a/0x1a0 do_syscall_64+0x5b/0x80 The warning is caused by reading conf->max_nr_stripes in raid_status. The code in raid_status reads mddev->private, casts it
arning is caused by reading conf->max_nr_stripes in raid_status. The code in raid_status reads mddev->private, casts it to struct r5conf and reads the entry max_nr_stripes. However, if we have different raid type than 4/5/6, mddev->private doesn't point to struct r5conf; it may point to struct r0conf, struct r1conf, struct r10conf or struct mpconf. If we cast a pointer to one of these structs to struct r5conf, we will be reading invalid memory and KASAN warns about it. Fix this bug by reading struct r5conf only if raid type is 4, 5 or 6. References: - https://git.kernel.org/stable/c/1ae0ebfb576b72c2ef400917a5484ebe7892d80b - https://git.kernel.org/stable/c/90b006da40dd42285b24dd3c940d2c32aca
/stable/c/1ae0ebfb576b72c2ef400917a5484ebe7892d80b - https://git.kernel.org/stable/c/90b006da40dd42285b24dd3c940d2c32aca9a70b - https://git.kernel.org/stable/c/b856ce5f4b55f752144baf17e9d5c415072652c5 - https://git.kernel.org/stable/c/cb583ca6125ac64c98e9d65128e95ebb5be7d322 - https://git.kernel.org/stable/c/49dba30638e091120256a9e89125340795f034dc - https://git.kernel.org/stable/c/4c233811a49578634d10a5e70a9dfa569d451e94 - https://git.kernel.org/stable/c/d8971b595d7adac3421c21f59918241f1574061e - https://git.kernel.org/stable/c/b4c6c07c92b6cba2bf3cb2dfa722debeaf8a8abe - https://git.kernel.org/stable/c/1fbeea217d8f297fe0e0956a1516d14ba97d0396
CVE ID: CVE-2022-50085 State: PUBLISHED Published: 2025-06-18T11:02:26.700Z Last Updated: 2025-07-15T15:43:45.187Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dm raid: fix address sanitizer warning in raid_resume There is a KASAN warning in raid_resume when running the lvm test lvconvert-raid.sh. The reason for the warning is that mddev->raid_disks is greater than rs->raid_disks, so the loop touches one entry beyond the allocated length. References: - https://git.kernel.org/stable/c/c2f075e729636a44e98d9722e3852c2fa6fa49b6 - https://git.kernel.org/stable/c/3bfdc95466f5be4d8d95db5a5b470d61641a7c24 - https://git.kernel.org/sta
e3852c2fa6fa49b6 - https://git.kernel.org/stable/c/3bfdc95466f5be4d8d95db5a5b470d61641a7c24 - https://git.kernel.org/stable/c/71f601c779b3cc1baf497796f5b922c3fe5d2a1e - https://git.kernel.org/stable/c/c2d47bef93fb74aa97d90f9a40ca657b8f376083 - https://git.kernel.org/stable/c/50235d9a1f1f742619ed9963cb9f240e5b821d46 - https://git.kernel.org/stable/c/74af83732a39ab7d3bc9b49219a535853e25679f - https://git.kernel.org/stable/c/2a9faa704d83ff0b04387e385efd8ae21cd95af6 - https://git.kernel.org/stable/c/7dad24db59d2d2803576f2e3645728866a056dab
CVE ID: CVE-2022-50086 State: PUBLISHED Published: 2025-06-18T11:02:27.283Z Last Updated: 2025-06-18T11:02:27.283Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: block: don't allow the same type rq_qos add more than once In our test of iocost, we encountered some list add/del corruptions of inner_walk list in ioc_timer_fn. The reason can be described as follows: cpu 0 cpu 1 ioc_qos_write ioc_qos_write ioc = q_to_ioc(queue); if (!ioc) { ioc = kzalloc(); ioc = q_to_ioc(queue); if (!ioc) { ioc = kzalloc(); ... rq_qos_add(q, rqos); } ... rq_qos_add(q, rqos); ... } When the io.cost.qos file is written by two cpus concurrently, rq_qo
_qos_add(q, rqos); } ... rq_qos_add(q, rqos); ... } When the io.cost.qos file is written by two cpus concurrently, rq_qos may be added to one disk twice. In that case, there will be two iocs enabled and running on one disk. They own different iocgs on their active list. In the ioc_timer_fn function, because of the iocgs from two iocs have the same root iocg, the root iocg's walk_list may be overwritten by each other and this leads to list add/del corruptions in building or destroying the inner_walk list. And so far, the blk-rq-qos framework works in case that one instance for one type rq_qos per queue by default. This patch make this explicit and also fix the crash above. References: - https
or one type rq_qos per queue by default. This patch make this explicit and also fix the crash above. References: - https://git.kernel.org/stable/c/0b7f5d7a4d2a72ad9de04ab8ccba2a31904aa638 - https://git.kernel.org/stable/c/08ef66e800a85afc6b54cb95841f6502627eee2e - https://git.kernel.org/stable/c/0c9bb1acd1d103a3070b2126870eb52761d606ce - https://git.kernel.org/stable/c/14a6e2eb7df5c7897c15b109cba29ab0c4a791b6
CVE ID: CVE-2022-50087 State: PUBLISHED Published: 2025-06-18T11:02:28.079Z Last Updated: 2025-07-15T15:43:46.317Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails When scpi probe fails, at any point, we need to ensure that the scpi_info is not set and will remain NULL until the probe succeeds. If it is not taken care, then it could result use-after-free as the value is exported via get_scpi_ops() and could refer to a memory allocated via devm_kzalloc() but freed when the probe fails. References: - https://git.kernel.org/stable/c/5aa558232edc30468d1f35108826d
vm_kzalloc() but freed when the probe fails. References: - https://git.kernel.org/stable/c/5aa558232edc30468d1f35108826dd5b3ffe978f - https://git.kernel.org/stable/c/18048cba444a7c41dbf42c180d6b46606fc24c51 - https://git.kernel.org/stable/c/08272646cd7c310642c39b7f54348fddd7987643 - https://git.kernel.org/stable/c/0c29e149b6bb498778ed8a1c9597b51acfba7856 - https://git.kernel.org/stable/c/87c4896d5dd7fd9927c814cf3c6289f41de3b562 - https://git.kernel.org/stable/c/4f2d7b46d6b53c07f44a4f8f8f4438888f0e9e87 - https://git.kernel.org/stable/c/689640efc0a2c4e07e6f88affe6d42cd40cc3f85
CVE ID: CVE-2022-50088 State: PUBLISHED Published: 2025-06-18T11:02:28.802Z Last Updated: 2025-06-18T11:02:28.802Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/damon/reclaim: fix potential memory leak in damon_reclaim_init() damon_reclaim_init() allocates a memory chunk for ctx with damon_new_ctx(). When damon_select_ops() fails, ctx is not released, which will lead to a memory leak. We should release the ctx with damon_destroy_ctx() when damon_select_ops() fails to fix the memory leak. References: - https://git.kernel.org/stable/c/9d3e9e1e0856f4c905bbb870f16f42ae72477071 - https://git.kernel.org/stable/c/700aa4e11a3c4d2a4
s://git.kernel.org/stable/c/9d3e9e1e0856f4c905bbb870f16f42ae72477071 - https://git.kernel.org/stable/c/700aa4e11a3c4d2a44d06758db431a013d9e1b61 - https://git.kernel.org/stable/c/188043c7f4f2bd662f2a55957d684fffa543e600
CVE ID: CVE-2022-50089 State: PUBLISHED Published: 2025-06-18T11:02:29.451Z Last Updated: 2025-06-18T11:02:29.451Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: ensure pages are unlocked on cow_file_range() failure There is a hung_task report on zoned btrfs like below. https://github.com/naota/linux/issues/59 [726.328648] INFO: task rocksdb:high0:11085 blocked for more than 241 seconds. [726.329839] Not tainted 5.16.0-rc1+ #1 [726.330484] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [726.331603] task:rocksdb:high0 state:D stack: 0 pid:11085 ppid: 11082 flags:0x00000000 [726.331608] Call Trac
message. [726.331603] task:rocksdb:high0 state:D stack: 0 pid:11085 ppid: 11082 flags:0x00000000 [726.331608] Call Trace: [726.331611] <TASK> [726.331614] __schedule+0x2e5/0x9d0 [726.331622] schedule+0x58/0xd0 [726.331626] io_schedule+0x3f/0x70 [726.331629] __folio_lock+0x125/0x200 [726.331634] ? find_get_entries+0x1bc/0x240 [726.331638] ? filemap_invalidate_unlock_two+0x40/0x40 [726.331642] truncate_inode_pages_range+0x5b2/0x770 [726.331649] truncate_inode_pages_final+0x44/0x50 [726.331653] btrfs_evict_inode+0x67/0x480 [726.331658] evict+0xd0/0x180 [726.331661] iput+0x13f/0x200 [726.331664] do_unlinkat+0x1c0/0x2b0 [726.331668] __x64_sys_unlink+0x23/0x30 [726.331670] do_syscall_64+0x3b/0xc0
/0x200 [726.331664] do_unlinkat+0x1c0/0x2b0 [726.331668] __x64_sys_unlink+0x23/0x30 [726.331670] do_syscall_64+0x3b/0xc0 [726.331674] entry_SYSCALL_64_after_hwframe+0x44/0xae [726.331677] RIP: 0033:0x7fb9490a171b [726.331681] RSP: 002b:00007fb943ffac68 EFLAGS: 00000246 ORIG_RAX: 0000000000000057 [726.331684] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb9490a171b [726.331686] RDX: 00007fb943ffb040 RSI: 000055a6bbe6ec20 RDI: 00007fb94400d300 [726.331687] RBP: 00007fb943ffad00 R08: 0000000000000000 R09: 0000000000000000 [726.331688] R10: 0000000000000031 R11: 0000000000000246 R12: 00007fb943ffb000 [726.331690] R13: 00007fb943ffb040 R14: 0000000000000000 R15: 00007fb943ffd260 [726.331
0000000246 R12: 00007fb943ffb000 [726.331690] R13: 00007fb943ffb040 R14: 0000000000000000 R15: 00007fb943ffd260 [726.331693] </TASK> While we debug the issue, we found running fstests generic/551 on 5GB non-zoned null_blk device in the emulated zoned mode also had a similar hung issue. Also, we can reproduce the same symptom with an error injected cow_file_range() setup. The hang occurs when cow_file_range() fails in the middle of allocation. cow_file_range() called from do_allocation_zoned() can split the give region ([start, end]) for allocation depending on current block group usages. When btrfs can allocate bytes for one part of the split regions but fails for the other region (e.g. beca
group usages. When btrfs can allocate bytes for one part of the split regions but fails for the other region (e.g. because of -ENOSPC), we return the error leaving the pages in the succeeded regions locked. Technically, this occurs only when @unlock == 0. Otherwise, we unlock the pages in an allocated region after creating an ordered extent. Considering the callers of cow_file_range(unlock=0) won't write out the pages, we can unlock the pages on error exit from cow_file_range(). So, we can ensure all the pages except @locked_page are unlocked on error case. In summary, cow_file_range now behaves like this: - page_started == 1 (return value) - All the pages are unlocked. IO is started. - unl
_file_range now behaves like this: - page_started == 1 (return value) - All the pages are unlocked. IO is started. - unlock == 1 - All the pages except @locked_page are unlocked in any case - unlock == 0 - On success, all the pages are locked for writing out them - On failure, all the pages except @locked_page are unlocked References: - https://git.kernel.org/stable/c/b367f125c80fa838eae49e3b138dc67dfc9f46ef - https://git.kernel.org/stable/c/9535ec371d741fa037e37eddc0a5b25ba82d0027 - https://git.kernel.org/stable/c/e160aa87c87a9c4e0c8d1430235f715a3a91e2cd - https://git.kernel.org/stable/c/9ce7466f372d83054c7494f6b3e4b9abaf3f0355
CVE ID: CVE-2022-50090 State: PUBLISHED Published: 2025-06-18T11:02:30.088Z Last Updated: 2025-06-18T11:02:30.088Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: replace BTRFS_MAX_EXTENT_SIZE with fs_info->max_extent_size On zoned filesystem, data write out is limited by max_zone_append_size, and a large ordered extent is split according the size of a bio. OTOH, the number of extents to be written is calculated using BTRFS_MAX_EXTENT_SIZE, and that estimated number is used to reserve the metadata bytes to update and/or create the metadata items. The metadata reservation is done at e.g, btrfs_buffered_write() and then rel
to update and/or create the metadata items. The metadata reservation is done at e.g, btrfs_buffered_write() and then released according to the estimation changes. Thus, if the number of extent increases massively, the reserved metadata can run out. The increase of the number of extents easily occurs on zoned filesystem if BTRFS_MAX_EXTENT_SIZE > max_zone_append_size. And, it causes the following warning on a small RAM environment with disabling metadata over-commit (in the following patch). [75721.498492] ------------[ cut here ]------------ [75721.505624] BTRFS: block rsv 1 returned -28 [75721.512230] WARNING: CPU: 24 PID: 2327559 at fs/btrfs/block-rsv.c:537 btrfs_use_block_rsv+0x560/0x760
1 returned -28 [75721.512230] WARNING: CPU: 24 PID: 2327559 at fs/btrfs/block-rsv.c:537 btrfs_use_block_rsv+0x560/0x760 [btrfs] [75721.581854] CPU: 24 PID: 2327559 Comm: kworker/u64:10 Kdump: loaded Tainted: G W 5.18.0-rc2-BTRFS-ZNS+ #109 [75721.597200] Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021 [75721.607310] Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] [75721.616209] RIP: 0010:btrfs_use_block_rsv+0x560/0x760 [btrfs] [75721.646649] RSP: 0018:ffffc9000fbdf3e0 EFLAGS: 00010286 [75721.654126] RAX: 0000000000000000 RBX: 0000000000004000 RCX: 0000000000000000 [75721.663524] RDX: 0000000000000004 RSI: 0000000000000008 RDI: fffff52001f7be6e [75721.672921] RBP:
: 0000000000000000 [75721.663524] RDX: 0000000000000004 RSI: 0000000000000008 RDI: fffff52001f7be6e [75721.672921] RBP: ffffc9000fbdf420 R08: 0000000000000001 R09: ffff889f8d1fc6c7 [75721.682493] R10: ffffed13f1a3f8d8 R11: 0000000000000001 R12: ffff88980a3c0e28 [75721.692284] R13: ffff889b66590000 R14: ffff88980a3c0e40 R15: ffff88980a3c0e8a [75721.701878] FS: 0000000000000000(0000) GS:ffff889f8d000000(0000) knlGS:0000000000000000 [75721.712601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [75721.720726] CR2: 000055d12e05c018 CR3: 0000800193594000 CR4: 0000000000350ee0 [75721.730499] Call Trace: [75721.735166] <TASK> [75721.739886] btrfs_alloc_tree_block+0x1e1/0x1100 [btrfs] [75721.747545
75721.730499] Call Trace: [75721.735166] <TASK> [75721.739886] btrfs_alloc_tree_block+0x1e1/0x1100 [btrfs] [75721.747545] ? btrfs_alloc_logged_file_extent+0x550/0x550 [btrfs] [75721.756145] ? btrfs_get_32+0xea/0x2d0 [btrfs] [75721.762852] ? btrfs_get_32+0xea/0x2d0 [btrfs] [75721.769520] ? push_leaf_left+0x420/0x620 [btrfs] [75721.776431] ? memcpy+0x4e/0x60 [75721.781931] split_leaf+0x433/0x12d0 [btrfs] [75721.788392] ? btrfs_get_token_32+0x580/0x580 [btrfs] [75721.795636] ? push_for_double_split.isra.0+0x420/0x420 [btrfs] [75721.803759] ? leaf_space_used+0x15d/0x1a0 [btrfs] [75721.811156] btrfs_search_slot+0x1bc3/0x2790 [btrfs] [75721.818300] ? lock_downgrade+0x7c0/0x7c0 [75721.824411] ? fre
[75721.811156] btrfs_search_slot+0x1bc3/0x2790 [btrfs] [75721.818300] ? lock_downgrade+0x7c0/0x7c0 [75721.824411] ? free_extent_buffer.part.0+0x107/0x200 [btrfs] [75721.832456] ? split_leaf+0x12d0/0x12d0 [btrfs] [75721.839149] ? free_extent_buffer.part.0+0x14f/0x200 [btrfs] [75721.846945] ? free_extent_buffer+0x13/0x20 [btrfs] [75721.853960] ? btrfs_release_path+0x4b/0x190 [btrfs] [75721.861429] btrfs_csum_file_blocks+0x85c/0x1500 [btrfs] [75721.869313] ? rcu_read_lock_sched_held+0x16/0x80 [75721.876085] ? lock_release+0x552/0xf80 [75721.881957] ? btrfs_del_csums+0x8c0/0x8c0 [btrfs] [75721.888886] ? __kasan_check_write+0x14/0x20 [75721.895152] ? do_raw_read_unlock+0x44/0x80 [75721.901323] ?
c0 [btrfs] [75721.888886] ? __kasan_check_write+0x14/0x20 [75721.895152] ? do_raw_read_unlock+0x44/0x80 [75721.901323] ? _raw_write_lock_irq+0x60/0x80 [75721.907983] ? btrfs_global_root+0xb9/0xe0 [btrfs] [75721.915166] ? btrfs_csum_root+0x12b/0x180 [btrfs] [75721.921918] ? btrfs_get_global_root+0x820/0x820 [btrfs] [75721.929166] ? _raw_write_unlock+0x23/0x40 [75721.935116] ? unpin_extent_cache+0x1e3/0x390 [btrfs] [75721.942041] btrfs_finish_ordered_io.isra.0+0xa0c/0x1dc0 [btrfs] [75721.949906] ? try_to_wake_up+0x30/0x14a0 [75721.955700] ? btrfs_unlink_subvol+0xda0/0xda0 [btrfs] [75721.962661] ? rcu ---truncated--- References: - https://git.kernel.org/stable/c/1aa262c1d056551dd1246115af8b7e35
rfs] [75721.962661] ? rcu ---truncated--- References: - https://git.kernel.org/stable/c/1aa262c1d056551dd1246115af8b7e351184deae - https://git.kernel.org/stable/c/6cb4b96df97082a54634ba02196516919cda228c - https://git.kernel.org/stable/c/096e8eb9639b342bc35f9b741cf05e26d0106e92 - https://git.kernel.org/stable/c/f7b12a62f008a3041f42f2426983e59a6a0a3c59
CVE ID: CVE-2022-50091 State: PUBLISHED Published: 2025-06-18T11:02:30.729Z Last Updated: 2025-06-18T11:02:30.729Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: locking/csd_lock: Change csdlock_debug from early_param to __setup The csdlock_debug kernel-boot parameter is parsed by the early_param() function csdlock_debug(). If set, csdlock_debug() invokes static_branch_enable() to enable csd_lock_wait feature, which triggers a panic on arm64 for kernels built with CONFIG_SPARSEMEM=y and CONFIG_SPARSEMEM_VMEMMAP=n. With CONFIG_SPARSEMEM_VMEMMAP=n, __nr_to_section is called in static_key_enable() and returns NULL, resulting in a
P=n. With CONFIG_SPARSEMEM_VMEMMAP=n, __nr_to_section is called in static_key_enable() and returns NULL, resulting in a NULL dereference because mem_section is initialized only later in sparse_init(). This is also a problem for powerpc because early_param() functions are invoked earlier than jump_label_init(), also resulting in static_key_enable() failures. These failures cause the warning "static key 'xxx' used before call to jump_label_init()". Thus, early_param is too early for csd_lock_wait to run static_branch_enable(), so changes it to __setup to fix these. References: - https://git.kernel.org/stable/c/d2cbdbe22b5f190055d2d0ae92e7454479343a30 - https://git.kernel.org/stable/c/05de9e2e3
: - https://git.kernel.org/stable/c/d2cbdbe22b5f190055d2d0ae92e7454479343a30 - https://git.kernel.org/stable/c/05de9e2e33b1625c71aee69e353fe906dd2be88a - https://git.kernel.org/stable/c/b480d1e9a8c11ecc1c99dc01814b28e3103bd0a0 - https://git.kernel.org/stable/c/9c9b26b0df270d4f9246e483a44686fca951a29c
CVE ID: CVE-2022-50092 State: PUBLISHED Published: 2025-06-18T11:02:31.372Z Last Updated: 2025-06-18T11:02:31.372Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dm thin: fix use-after-free crash in dm_sm_register_threshold_callback Fault inject on pool metadata device reports: BUG: KASAN: use-after-free in dm_pool_register_metadata_threshold+0x40/0x80 Read of size 8 at addr ffff8881b9d50068 by task dmsetup/950 CPU: 7 PID: 950 Comm: dmsetup Tainted: G W 5.19.0-rc6 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_address_description.constpro
IIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_address_description.constprop.0.cold+0xeb/0x3f4 kasan_report.cold+0xe6/0x147 dm_pool_register_metadata_threshold+0x40/0x80 pool_ctr+0xa0a/0x1150 dm_table_add_target+0x2c8/0x640 table_load+0x1fd/0x430 ctl_ioctl+0x2c4/0x5a0 dm_ctl_ioctl+0xa/0x10 __x64_sys_ioctl+0xb3/0xd0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 This can be easily reproduced using: echo offline > /sys/block/sda/device/state dd if=/dev/zero of=/dev/mapper/thin bs=4k count=10 dmsetup load pool --table "0 20971520 thin-pool /dev/sda /dev/sdb 128 0 0" If a metadata commit fails, the transaction will be aborted and the
ble "0 20971520 thin-pool /dev/sda /dev/sdb 128 0 0" If a metadata commit fails, the transaction will be aborted and the metadata space maps will be destroyed. If a DM table reload then happens for this failed thin-pool, a use-after-free will occur in dm_sm_register_threshold_callback (called from dm_pool_register_metadata_threshold). Fix this by in dm_pool_register_metadata_threshold() by returning the -EINVAL error if the thin-pool is in fail mode. Also fail pool_ctr() with a new error message: "Error registering metadata threshold". References: - https://git.kernel.org/stable/c/05cef0999b3208b5a6ede1bfac855139e4de55ef - https://git.kernel.org/stable/c/5e2cf705155a1514be3c96ea664a9cd356998
table/c/05cef0999b3208b5a6ede1bfac855139e4de55ef - https://git.kernel.org/stable/c/5e2cf705155a1514be3c96ea664a9cd356998ee7 - https://git.kernel.org/stable/c/f83131a3071a0b61a4d7dca70f95adb3ffad920e - https://git.kernel.org/stable/c/1a199fa9217d28511ff88529238fd9980ea64cf3 - https://git.kernel.org/stable/c/e4dbe24f4bfd8377e7ba79fdcdb7c4d6eb1c6790 - https://git.kernel.org/stable/c/3534e5a5ed2997ca1b00f44a0378a075bd05e8a3
CVE ID: CVE-2022-50093 State: PUBLISHED Published: 2025-06-18T11:02:31.966Z Last Updated: 2025-06-18T11:02:31.966Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: avoid invalid memory access via node_online(NUMA_NO_NODE) KASAN reports: [ 4.668325][ T0] BUG: KASAN: wild-memory-access in dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497) [ 4.676149][ T0] Read of size 8 at addr 1fffffff85115558 by task swapper/0/0 [ 4.683454][ T0] [ 4.685638][ T0] CPU: 0 PID: 0 Comm:
][ T0] Read of size 8 at addr 1fffffff85115558 by task swapper/0/0 [ 4.683454][ T0] [ 4.685638][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc3-00004-g0e862838f290 #1 [ 4.694331][ T0] Hardware name: Supermicro SYS-5018D-FN4T/X10SDV-8C-TLN4F, BIOS 1.1 03/02/2016 [ 4.703196][ T0] Call Trace: [ 4.706334][ T0] <TASK> [ 4.709133][ T0] ? dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497) after converting the type of the first argument (@nr, bit number) of arch_test_bit() from `long` to `unsigned long`[0]. Under certain conditions (for
the first argument (@nr, bit number) of arch_test_bit() from `long` to `unsigned long`[0]. Under certain conditions (for example, when ACPI NUMA is disabled via command line), pxm_to_node() can return %NUMA_NO_NODE (-1). It is valid 'magic' number of NUMA node, but not valid bit number to use in bitops. node_online() eventually descends to test_bit() without checking for the input, assuming it's on caller side (which might be good for perf-critical tasks). There, -1 becomes %ULONG_MAX which leads to an insane array index when calculating bit position in memory. For now, add an explicit check for @node being not %NUMA_NO_NODE before calling test_bit(). The actual logics didn't change here at
an explicit check for @node being not %NUMA_NO_NODE before calling test_bit(). The actual logics didn't change here at all. [0] https://github.com/norov/linux/commit/0e862838f290147ea9c16db852d8d494b552d38d References: - https://git.kernel.org/stable/c/b12304984654d8e58a2b22ff94c4410906d6267f - https://git.kernel.org/stable/c/5659efdadf04b56707d58c1b758df16d2e0eff2c - https://git.kernel.org/stable/c/0b4c0003aeda32a600f95df53b2848da8a5aa3fa - https://git.kernel.org/stable/c/73ce2046e04ad488cecc66757c36cbe1bdf089d4 - https://git.kernel.org/stable/c/c2304c50f4d94f56c2e326f25c9dc8cf2ba6f5fa - https://git.kernel.org/stable/c/b0b0b77ea611e3088e9523e60860f4f41b62b235