Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2022-49074 State: PUBLISHED Published: 2025-02-26T01:54:38.290Z Last Updated: 2025-05-04T08:29:10.086Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3: Fix GICR_CTLR.RWP polling It turns out that our polling of RWP is totally wrong when checking for it in the redistributors, as we test the *distributor* bit index, whereas it is a different bit number in the RDs... Oopsie boo. This is embarassing. Not only because it is wrong, but also because it took *8 years* to notice the blunder... Just fix the damn thing. References: - https://git.kernel.org/stable/c/c7daf1b4ad809692d5c26f33c02ed8a031066548 - https
Just fix the damn thing. References: - https://git.kernel.org/stable/c/c7daf1b4ad809692d5c26f33c02ed8a031066548 - https://git.kernel.org/stable/c/3c07cc242baf83f0bddbbd9d7945d0bee56d8b57 - https://git.kernel.org/stable/c/ff24114bb08d8b90edf2aff0a4fd0689523e6c17 - https://git.kernel.org/stable/c/7218a789abb3e033f5f3a85636ca50d9ae7b0fc9 - https://git.kernel.org/stable/c/60e1eb4811f53f5f60c788297d978515e7a2637a - https://git.kernel.org/stable/c/6fef3e3179e6ed8fecdd004ede541674ffa7749d - https://git.kernel.org/stable/c/0df6664531a12cdd8fc873f0cac0dcb40243d3e9
CVE ID: CVE-2022-49075 State: PUBLISHED Published: 2025-02-26T01:54:38.757Z Last Updated: 2025-05-04T08:29:11.296Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: fix qgroup reserve overflow the qgroup limit We use extent_changeset->bytes_changed in qgroup_reserve_data() to record how many bytes we set for EXTENT_QGROUP_RESERVED state. Currently the bytes_changed is set as "unsigned int", and it will overflow if we try to fallocate a range larger than 4GiB. The result is we reserve less bytes and eventually break the qgroup limit. Unlike regular buffered/direct write, which we use one changeset for each ordered extent, wh
lly break the qgroup limit. Unlike regular buffered/direct write, which we use one changeset for each ordered extent, which can never be larger than 256M. For fallocate, we use one changeset for the whole range, thus it no longer respects the 256M per extent limit, and caused the problem. The following example test script reproduces the problem: $ cat qgroup-overflow.sh #!/bin/bash DEV=/dev/sdj MNT=/mnt/sdj mkfs.btrfs -f $DEV mount $DEV $MNT # Set qgroup limit to 2GiB. btrfs quota enable $MNT btrfs qgroup limit 2G $MNT # Try to fallocate a 3GiB file. This should fail. echo echo "Try to fallocate a 3GiB file..." fallocate -l 3G $MNT/3G.file # Try to fallocate a 5GiB file. echo echo "Try to fa
echo "Try to fallocate a 3GiB file..." fallocate -l 3G $MNT/3G.file # Try to fallocate a 5GiB file. echo echo "Try to fallocate a 5GiB file..." fallocate -l 5G $MNT/5G.file # See we break the qgroup limit. echo sync btrfs qgroup show -r $MNT umount $MNT When running the test: $ ./qgroup-overflow.sh (...) Try to fallocate a 3GiB file... fallocate: fallocate failed: Disk quota exceeded Try to fallocate a 5GiB file... qgroupid rfer excl max_rfer -------- ---- ---- -------- 0/5 5.00GiB 5.00GiB 2.00GiB Since we have no control of how bytes_changed is used, it's better to set it to u64. References: - https://git.kernel.org/stable/c/0355387ea5b02d353c9415613fab908fac5c52a6 - https://git.kernel.org/
to u64. References: - https://git.kernel.org/stable/c/0355387ea5b02d353c9415613fab908fac5c52a6 - https://git.kernel.org/stable/c/f3d97b22a708bf9e3f3ac2ba232bcefd0b0c136b - https://git.kernel.org/stable/c/44277c50fdba5019ca25bfad1b71e2561b0de11b - https://git.kernel.org/stable/c/82ae73ac963cee877ce34f7c31b2b456b516e96c - https://git.kernel.org/stable/c/4b98799e181b4326a613108cf37acc1f55d21b45 - https://git.kernel.org/stable/c/6bfff81286d4491f02dad7814bae5c77c9ad2320 - https://git.kernel.org/stable/c/7941b74ed49b6db25efbef2256ebef843c11a010 - https://git.kernel.org/stable/c/b642b52d0b50f4d398cb4293f64992d0eed2e2ce
CVE ID: CVE-2022-49076 State: PUBLISHED Published: 2025-02-26T01:54:39.251Z Last Updated: 2025-05-04T12:44:15.733Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Fix use-after-free bug for mm struct Under certain conditions, such as MPI_Abort, the hfi1 cleanup code may represent the last reference held on the task mm. hfi1_mmu_rb_unregister() then drops the last reference and the mm is freed before the final use in hfi1_release_user_pages(). A new task may allocate the mm structure while it is still being used, resulting in problems. One manifestation is corruption of the mmap_sem counter leading to a hang in down_wr
being used, resulting in problems. One manifestation is corruption of the mmap_sem counter leading to a hang in down_write(). Another is corruption of an mm struct that is in use by another task. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/5f54364ff6cfcd14cddf5441c4a490bb28dd69f7 - https://git.kernel.org/stable/c/9ca11bd8222a612de0d2f54d050bfcf61ae2883f - https://git.kernel.org/stable/c/0b7186d657ee55e2cdefae498f07d5c1961e8023 - https://git.kernel.org/stable/c/5a9a1b24ddb510715f8f621263938186579a965c - https://git.kernel.org/stable/c/2bbac98d0930e8161b1957dc0ec99de39ade1b3c
CVE ID: CVE-2022-49077 State: PUBLISHED Published: 2025-02-26T01:54:39.739Z Last Updated: 2025-05-04T08:29:13.921Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mmmremap.c: avoid pointless invalidate_range_start/end on mremap(old_size=0) If an mremap() syscall with old_size=0 ends up in move_page_tables(), it will call invalidate_range_start()/invalidate_range_end() unnecessarily, i.e. with an empty range. This causes a WARN in KVM's mmu_notifier. In the past, empty ranges have been diagnosed to be off-by-one bugs, hence the WARNing. Given the low (so far) number of unique reports, the benefits of detecting more buggy callers
bugs, hence the WARNing. Given the low (so far) number of unique reports, the benefits of detecting more buggy callers seem to outweigh the cost of having to fix cases such as this one, where userspace is doing something silly. In this particular case, an early return from move_page_tables() is enough to fix the issue. References: - https://git.kernel.org/stable/c/a05540f3903bd8295e8c4cd90dd3d416239a115b - https://git.kernel.org/stable/c/eeaf28e2a0128147d687237e59d5407ee1b14693 - https://git.kernel.org/stable/c/e2c328c2a8f9de8b761bd4025b66c63120c55761 - https://git.kernel.org/stable/c/c19d8de4e682ec4b0ea2b04a832cd8cc0be3bb31 - https://git.kernel.org/stable/c/7d659cb1763ff17d1c6ee082fa6feb42
org/stable/c/c19d8de4e682ec4b0ea2b04a832cd8cc0be3bb31 - https://git.kernel.org/stable/c/7d659cb1763ff17d1c6ee082fa6feb4267c7a30b - https://git.kernel.org/stable/c/a04cb99c5d4668fe3f5c0e5b6da1cecd34c3f219 - https://git.kernel.org/stable/c/2358aa84ef6dafcf544a557caaa6b91afb4a0bd2 - https://git.kernel.org/stable/c/04bc13dae4a27b8d030843c85ae452bb2f1d9c1f - https://git.kernel.org/stable/c/01e67e04c28170c47700c2c226d732bbfedb1ad0
CVE ID: CVE-2022-49078 State: PUBLISHED Published: 2025-02-26T01:54:40.207Z Last Updated: 2025-09-03T12:58:36.144Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: lz4: fix LZ4_decompress_safe_partial read out of bound When partialDecoding, it is EOF if we've either filled the output buffer or can't proceed with reading an offset for following match. In some extreme corner cases when compressed data is suitably corrupted, UAF will occur. As reported by KASAN [1], LZ4_decompress_safe_partial may lead to read out of bound problem during decoding. lz4 upstream has fixed it [2] and this issue has been disscussed here [3] before. curr
of bound problem during decoding. lz4 upstream has fixed it [2] and this issue has been disscussed here [3] before. current decompression routine was ported from lz4 v1.8.3, bumping lib/lz4 to v1.9.+ is certainly a huge work to be done later, so, we'd better fix it first. [1] https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/ [2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad# [3] https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/ Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/73953dfa9d50e5c9fe98ee13fd1d3427aa12a0a3 - https://git.kernel.org/stable/c/6adc01a7aa37445dafe8846fa
kernel.org/stable/c/73953dfa9d50e5c9fe98ee13fd1d3427aa12a0a3 - https://git.kernel.org/stable/c/6adc01a7aa37445dafe8846faa0610a86029b253 - https://git.kernel.org/stable/c/9fb8bc6cfc58773ce95414e11c9ccc8fc6ac4927 - https://git.kernel.org/stable/c/e64dbe97c05c769525cbca099ddbd22485630235 - https://git.kernel.org/stable/c/467d5e200ab4486b744fe1776154a43d1aa22d4b - https://git.kernel.org/stable/c/eafc0a02391b7b36617b36c97c4b5d6832cf5e24
CVE ID: CVE-2022-49079 State: PUBLISHED Published: 2025-02-26T01:54:40.697Z Last Updated: 2025-05-04T08:29:16.372Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: traverse devices under chunk_mutex in btrfs_can_activate_zone btrfs_can_activate_zone() can be called with the device_list_mutex already held, which will lead to a deadlock: insert_dev_extents() // Takes device_list_mutex `-> insert_dev_extent() `-> btrfs_insert_empty_item() `-> btrfs_insert_empty_items() `-> btrfs_search_slot() `-> btrfs_cow_block() `-> __btrfs_cow_block() `-> btrfs_alloc_tree_block() `-> btrfs_reserve_extent() `-> find_free_extent() `->
s_cow_block() `-> __btrfs_cow_block() `-> btrfs_alloc_tree_block() `-> btrfs_reserve_extent() `-> find_free_extent() `-> find_free_extent_update_loop() `-> can_allocate_chunk() `-> btrfs_can_activate_zone() // Takes device_list_mutex again Instead of using the RCU on fs_devices->device_list we can use fs_devices->alloc_list, protected by the chunk_mutex to traverse the list of active devices. We are in the chunk allocation thread. The newer chunk allocation happens from the devices in the fs_device->alloc_list protected by the chunk_mutex. btrfs_create_chunk() lockdep_assert_held(&info->chunk_mutex); gather_device_info list_for_each_entry(device, &fs_devices->alloc_list, dev_alloc_list) Also
t_held(&info->chunk_mutex); gather_device_info list_for_each_entry(device, &fs_devices->alloc_list, dev_alloc_list) Also, a device that reappears after the mount won't join the alloc_list yet and, it will be in the dev_list, which we don't want to consider in the context of the chunk alloc. [15.166572] WARNING: possible recursive locking detected [15.167117] 5.17.0-rc6-dennis #79 Not tainted [15.167487] -------------------------------------------- [15.167733] kworker/u8:3/146 is trying to acquire lock: [15.167733] ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: find_free_extent+0x15a/0x14f0 [btrfs] [15.167733] [15.167733] but task is already holding lock: [15.167733] ffff8881
at: find_free_extent+0x15a/0x14f0 [btrfs] [15.167733] [15.167733] but task is already holding lock: [15.167733] ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs] [15.167733] [15.167733] other info that might help us debug this: [15.167733] Possible unsafe locking scenario: [15.167733] [15.171834] CPU0 [15.171834] ---- [15.171834] lock(&fs_devs->device_list_mutex); [15.171834] lock(&fs_devs->device_list_mutex); [15.171834] [15.171834] *** DEADLOCK *** [15.171834] [15.171834] May be due to missing lock nesting notation [15.171834] [15.171834] 5 locks held by kworker/u8:3/146: [15.171834] #0: ffff888100050938 ((wq_completion)ev
g notation [15.171834] [15.171834] 5 locks held by kworker/u8:3/146: [15.171834] #0: ffff888100050938 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0 [15.171834] #1: ffffc9000067be80 ((work_completion)(&fs_info->async_data_reclaim_work)){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0 [15.176244] #2: ffff88810521e620 (sb_internal){.+.+}-{0:0}, at: flush_space+0x335/0x600 [btrfs] [15.176244] #3: ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs] [15.176244] #4: ffff8881152e4b78 (btrfs-dev-00){++++}-{3:3}, at: __btrfs_tree_lock+0x27/0x130 [btrfs] [15.179641] [15.179641] stack backtrace: [15.179641] C
rfs-dev-00){++++}-{3:3}, at: __btrfs_tree_lock+0x27/0x130 [btrfs] [15.179641] [15.179641] stack backtrace: [15.179641] CPU: 1 PID: 146 Comm: kworker/u8:3 Not tainted 5.17.0-rc6-dennis #79 [15.179641] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1.fc35 04/01/2014 [15.179641] Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] [15.179641] Call Trace: [15.179641] <TASK> [15.179641] dump_stack_lvl+0x45/0x59 [15.179641] __lock_acquire.cold+0x217/0x2b2 [15.179641] lock_acquire+0xbf/0x2b0 [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] __mutex_lock+0x8e/0x970 [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] ? find_free_extent+0x15a/0
3838] __mutex_lock+0x8e/0x970 [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] ? lock_is_held_type+0xd7/0x130 [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] ? _raw_spin_unlock+0x24/0x40 [15.183838] ? btrfs_get_alloc_profile+0x106/0x230 [btrfs] [15.187601] btrfs_reserve_extent+0x131/0x260 [btrfs] [15. ---truncated--- References: - https://git.kernel.org/stable/c/09e65ae515af2b24d6dc23af21719a3b41de83e5 - https://git.kernel.org/stable/c/142f822bd945a7be442a2916ec6167cc102c4183 - https://git.kernel.org/stable/c/0b9e66762aa0cda2a9c2d5542d64e04dac528fa6
CVE ID: CVE-2022-49080 State: PUBLISHED Published: 2025-02-26T01:54:41.176Z Last Updated: 2025-05-04T08:29:17.556Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/mempolicy: fix mpol_new leak in shared_policy_replace If mpol_new is allocated but not used in restart loop, mpol_new will be freed via mpol_put before returning to the caller. But refcnt is not initialized yet, so mpol_put could not do the right things and might leak the unused mpol_new. This would happen if mempolicy was updated on the shared shmem file while the sp->lock has been dropped during the memory allocation. This issue could be triggered easily with the
em file while the sp->lock has been dropped during the memory allocation. This issue could be triggered easily with the below code snippet if there are many processes doing the below work at the same time: shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT); shm = shmat(shmid, 0, 0); loop many times { mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0); mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask, maxnode, 0); } References: - https://git.kernel.org/stable/c/8510c2346d9e47a72b7f018a36ef0c39483e53d6 - https://git.kernel.org/stable/c/5e16dc5378abd749a836daa9ee4ab2c8d2668999 - https://git.kernel.org/stable/c/39a32f3c06f6d68a530bf9612afa19f50f12e93d - https:/
c5378abd749a836daa9ee4ab2c8d2668999 - https://git.kernel.org/stable/c/39a32f3c06f6d68a530bf9612afa19f50f12e93d - https://git.kernel.org/stable/c/25f506273b6ae806fd46bfcb6fdaa5b9ec81a05b - https://git.kernel.org/stable/c/f7e183b0a7136b6dc9c7b9b2a85a608a8feba894 - https://git.kernel.org/stable/c/198932a14aeb19a15cf19e51e151d023bc4cd648 - https://git.kernel.org/stable/c/6e00309ac716fa8225f0cbde2cd9c24f0e74ee21 - https://git.kernel.org/stable/c/fe39ac59dbbf893b73b24e3184161d0bd06d6651 - https://git.kernel.org/stable/c/4ad099559b00ac01c3726e5c95dc3108ef47d03e
CVE ID: CVE-2022-49081 State: PUBLISHED Published: 2025-02-26T01:54:41.639Z Last Updated: 2025-05-04T08:29:19.097Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: highmem: fix checks in __kmap_local_sched_{in,out} When CONFIG_DEBUG_KMAP_LOCAL is enabled __kmap_local_sched_{in,out} check that even slots in the tsk->kmap_ctrl.pteval are unmapped. The slots are initialized with 0 value, but the check is done with pte_none. 0 pte however does not necessarily mean that pte_none will return true. e.g. on xtensa it returns false, resulting in the following runtime warnings: WARNING: CPU: 0 PID: 101 at mm/highmem.c:627 __kmap_local_sche
turns false, resulting in the following runtime warnings: WARNING: CPU: 0 PID: 101 at mm/highmem.c:627 __kmap_local_sched_out+0x51/0x108 CPU: 0 PID: 101 Comm: touch Not tainted 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 Call Trace: dump_stack+0xc/0x40 __warn+0x8f/0x174 warn_slowpath_fmt+0x48/0xac __kmap_local_sched_out+0x51/0x108 __schedule+0x71a/0x9c4 preempt_schedule_irq+0xa0/0xe0 common_exception_return+0x5c/0x93 do_wp_page+0x30e/0x330 handle_mm_fault+0xa70/0xc3c do_page_fault+0x1d8/0x3c4 common_exception+0x7f/0x7f WARNING: CPU: 0 PID: 101 at mm/highmem.c:664 __kmap_local_sched_in+0x50/0xe0 CPU: 0 PID: 101 Comm: touch Tainted: G W 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 Call Trace: dump_st
sched_in+0x50/0xe0 CPU: 0 PID: 101 Comm: touch Tainted: G W 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 Call Trace: dump_stack+0xc/0x40 __warn+0x8f/0x174 warn_slowpath_fmt+0x48/0xac __kmap_local_sched_in+0x50/0xe0 finish_task_switch$isra$0+0x1ce/0x2f8 __schedule+0x86e/0x9c4 preempt_schedule_irq+0xa0/0xe0 common_exception_return+0x5c/0x93 do_wp_page+0x30e/0x330 handle_mm_fault+0xa70/0xc3c do_page_fault+0x1d8/0x3c4 common_exception+0x7f/0x7f Fix it by replacing !pte_none(pteval) with pte_val(pteval) != 0. References: - https://git.kernel.org/stable/c/c21d040de6225414547d9bd31cd200f290991c85 - https://git.kernel.org/stable/c/85550b0f5fa5dd3c30469ea702c44444ef242c83 - https://git.kernel.org/stable/
00f290991c85 - https://git.kernel.org/stable/c/85550b0f5fa5dd3c30469ea702c44444ef242c83 - https://git.kernel.org/stable/c/7dd5b3b97716a611fcf67d92fd2370fcb8d50372 - https://git.kernel.org/stable/c/66f133ceab7456c789f70a242991ed1b27ba1c3d
CVE ID: CVE-2022-49082 State: PUBLISHED Published: 2025-02-26T01:54:42.101Z Last Updated: 2025-05-04T08:29:20.299Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix use after free in _scsih_expander_node_remove() The function mpt3sas_transport_port_remove() called in _scsih_expander_node_remove() frees the port field of the sas_expander structure, leading to the following use-after-free splat from KASAN when the ioc_info() call following that function is executed (e.g. when doing rmmod of the driver module): [ 3479.371167] ================================================================== [ 3479.378496] BUG: KAS
river module): [ 3479.371167] ================================================================== [ 3479.378496] BUG: KASAN: use-after-free in _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.386936] Read of size 1 at addr ffff8881c037691c by task rmmod/1531 [ 3479.393524] [ 3479.395035] CPU: 18 PID: 1531 Comm: rmmod Not tainted 5.17.0-rc8+ #1436 [ 3479.401712] Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.1 06/02/2021 [ 3479.409263] Call Trace: [ 3479.411743] <TASK> [ 3479.413875] dump_stack_lvl+0x45/0x59 [ 3479.417582] print_address_description.constprop.0+0x1f/0x120 [ 3479.423389] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.429469] kasan_report.cold+0x83/0
.0+0x1f/0x120 [ 3479.423389] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.429469] kasan_report.cold+0x83/0xdf [ 3479.433438] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.439514] _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.445411] ? _raw_spin_unlock_irqrestore+0x2d/0x40 [ 3479.452032] scsih_remove+0x525/0xc90 [mpt3sas] [ 3479.458212] ? mpt3sas_expander_remove+0x1d0/0x1d0 [mpt3sas] [ 3479.465529] ? down_write+0xde/0x150 [ 3479.470746] ? up_write+0x14d/0x460 [ 3479.475840] ? kernfs_find_ns+0x137/0x310 [ 3479.481438] pci_device_remove+0x65/0x110 [ 3479.487013] __device_release_driver+0x316/0x680 [ 3479.493180] driver_detach+0x1ec/0x2d0 [ 3479.498499] bus_
65/0x110 [ 3479.487013] __device_release_driver+0x316/0x680 [ 3479.493180] driver_detach+0x1ec/0x2d0 [ 3479.498499] bus_remove_driver+0xe7/0x2d0 [ 3479.504081] pci_unregister_driver+0x26/0x250 [ 3479.510033] _mpt3sas_exit+0x2b/0x6cf [mpt3sas] [ 3479.516144] __x64_sys_delete_module+0x2fd/0x510 [ 3479.522315] ? free_module+0xaa0/0xaa0 [ 3479.527593] ? __cond_resched+0x1c/0x90 [ 3479.532951] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 3479.539607] ? syscall_enter_from_user_mode+0x21/0x70 [ 3479.546161] ? trace_hardirqs_on+0x1c/0x110 [ 3479.551828] do_syscall_64+0x35/0x80 [ 3479.556884] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 3479.563402] RIP: 0033:0x7f1fc482483b ... [ 3479.943087] ==========
9.556884] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 3479.563402] RIP: 0033:0x7f1fc482483b ... [ 3479.943087] ================================================================== Fix this by introducing the local variable port_id to store the port ID value before executing mpt3sas_transport_port_remove(). This local variable is then used in the call to ioc_info() instead of dereferencing the freed port structure. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/25c1353dca74ad7cf3fd7ce258fe7c957a147d5e - https://git.kernel.org/stable/c/17d66b1c92bcb41e72271ec60069d3684aaa1c9c - https://git.kernel.org/stable/c/1bb8a7fc64d63ec818e367e1b37676ea2ef2d2
able/c/17d66b1c92bcb41e72271ec60069d3684aaa1c9c - https://git.kernel.org/stable/c/1bb8a7fc64d63ec818e367e1b37676ea2ef2d20c - https://git.kernel.org/stable/c/87d663d40801dffc99a5ad3b0188ad3e2b4d1557
CVE ID: CVE-2022-49083 State: PUBLISHED Published: 2025-02-26T01:54:42.582Z Last Updated: 2025-05-04T08:29:21.393Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iommu/omap: Fix regression in probe for NULL pointer dereference Commit 3f6634d997db ("iommu: Use right way to retrieve iommu_ops") started triggering a NULL pointer dereference for some omap variants: __iommu_probe_device from probe_iommu_group+0x2c/0x38 probe_iommu_group from bus_for_each_dev+0x74/0xbc bus_for_each_dev from bus_iommu_probe+0x34/0x2e8 bus_iommu_probe from bus_set_iommu+0x80/0xc8 bus_set_iommu from omap_iommu_init+0x88/0xcc omap_iommu_init from do_one_
8 bus_iommu_probe from bus_set_iommu+0x80/0xc8 bus_set_iommu from omap_iommu_init+0x88/0xcc omap_iommu_init from do_one_initcall+0x44/0x24 This is caused by omap iommu probe returning 0 instead of ERR_PTR(-ENODEV) as noted by Jason Gunthorpe <jgg@ziepe.ca>. Looks like the regression already happened with an earlier commit 6785eb9105e3 ("iommu/omap: Convert to probe/release_device() call-backs") that changed the function return type and missed converting one place. References: - https://git.kernel.org/stable/c/bd905fed87ce01ac010011bb8f44ed0140116ceb - https://git.kernel.org/stable/c/47e239117bd97c8556f9187af7a9a7938db4e021 - https://git.kernel.org/stable/c/ea518578aa8a9a0280605b53cc33f707e10
/stable/c/47e239117bd97c8556f9187af7a9a7938db4e021 - https://git.kernel.org/stable/c/ea518578aa8a9a0280605b53cc33f707e10c8178 - https://git.kernel.org/stable/c/1d89f2b9eadbcf3ce93c6d7238f68299a1f84968 - https://git.kernel.org/stable/c/71ff461c3f41f6465434b9e980c01782763e7ad8
CVE ID: CVE-2022-49084 State: PUBLISHED Published: 2025-02-26T01:54:43.099Z Last Updated: 2025-05-04T08:29:23.165Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: qede: confirm skb is allocated before using qede_build_skb() assumes build_skb() always works and goes straight to skb_reserve(). However, build_skb() can fail under memory pressure. This results in a kernel panic because the skb to reserve is NULL. Add a check in case build_skb() failed to allocate and return NULL. The NULL return is handled correctly in callers to qede_build_skb(). References: - https://git.kernel.org/stable/c/9648adb1b3ece55c657d3a4f52bfee663b710dfe