Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2022-49982 State: PUBLISHED Published: 2025-06-18T11:00:44.285Z Last Updated: 2025-06-18T11:00:44.285Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix memory leak in pvr_probe The error handling code in pvr2_hdw_create forgets to unregister the v4l2 device. When pvr2_hdw_create returns back to pvr2_context_create, it calls pvr2_context_destroy to destroy context, but mp->hdw is NULL, which leads to that pvr2_hdw_destroy directly returns. Fix this by adding v4l2_device_unregister to decrease the refcount of usb interface. References: - https://git.kernel.org/stable/c/2fe46195d2f0d5d09ea65433aefe47a
to decrease the refcount of usb interface. References: - https://git.kernel.org/stable/c/2fe46195d2f0d5d09ea65433aefe47a4d0d0ff4d - https://git.kernel.org/stable/c/ba7dd8a9686a61a34b3a7b922ce721378d4740d0 - https://git.kernel.org/stable/c/491762b3250fb06a0c97b5198656ea48359eaeed - https://git.kernel.org/stable/c/466b67c0543b2ae67814d053f6e29b39be6b33bb - https://git.kernel.org/stable/c/bacb37bdc2a21c8f7fdc83dcc0dea2f4ca1341fb - https://git.kernel.org/stable/c/f2f6e67522916f53ad8ccd4dbe68dcf76e9776e5 - https://git.kernel.org/stable/c/c02d2a91a85c4c4d05826cd1ea74a9b8d42e4280 - https://git.kernel.org/stable/c/945a9a8e448b65bec055d37eba58f711b39f66f0
CVE ID: CVE-2022-49983 State: PUBLISHED Published: 2025-06-18T11:00:45.701Z Last Updated: 2025-06-19T13:10:45.362Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: udmabuf: Set the DMA mask for the udmabuf device (v2) If the DMA mask is not set explicitly, the following warning occurs when the userspace tries to access the dma-buf via the CPU as reported by syzbot here: WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188 __dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Modules linked in: CPU: 0 PID: 3595 Comm: syz-executor249 Not tainted 5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0 Hardware name: Google Google Compute Eng
5 Comm: syz-executor249 Not tainted 5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0 83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45 31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00 RSP: 0018:ffffc90002a07d68 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408 RBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f R10: ffffffff81649d72
f81649e91 RDI: ffff88801b848408 RBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f R10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002 R13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000 FS: 0000555556e30300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264 get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72 begin_cpu_udmabuf
sgtable+0x70/0xf0 kernel/dma/mapping.c:264 get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72 begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126 dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164 dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f62fcf530f9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca
ae RIP: 0033:0x7f62fcf530f9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe3edab9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f62fcf530f9 RDX: 0000000020000200 RSI: 0000000040086200 RDI: 0000000000000006 RBP: 00007f62fcf170e0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f62fcf17170 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> v2: Dont't forget to deregister if DMA mask setup fails. Refere
0000 R14: 0000000000000000 R15: 0000000000000000 </TASK> v2: Dont't forget to deregister if DMA mask setup fails. References: - https://git.kernel.org/stable/c/63d8c1933ed280717f934e2bc2edd869bb66f329 - https://git.kernel.org/stable/c/872875c9ecf8fa2e1d82bb2f2f1963f571aa8959 - https://git.kernel.org/stable/c/e658538c610c6047b3c9f552e73801894d9284b1 - https://git.kernel.org/stable/c/f2f6ea1a8da1317430a84701fc0170449ee88315 - https://git.kernel.org/stable/c/9e9fa6a9198b767b00f48160800128e83a038f9f
CVE ID: CVE-2022-49984 State: PUBLISHED Published: 2025-06-18T11:00:46.543Z Last Updated: 2025-06-18T11:00:46.543Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: HID: steam: Prevent NULL pointer dereference in steam_{recv,send}_report It is possible for a malicious device to forgo submitting a Feature Report. The HID Steam driver presently makes no prevision for this and de-references the 'struct hid_report' pointer obtained from the HID devices without first checking its validity. Let's change that. References: - https://git.kernel.org/stable/c/c20d03b82a2e3ddbb555dad4d4f3374a9763222c - https://git.kernel.org/stable/c/fa2b822d
s: - https://git.kernel.org/stable/c/c20d03b82a2e3ddbb555dad4d4f3374a9763222c - https://git.kernel.org/stable/c/fa2b822d86be5b5ad54fe4fa2daca464e71ff90a - https://git.kernel.org/stable/c/dc815761948ab5b8c94db6cb53c95103588f16ae - https://git.kernel.org/stable/c/989560b6d9e00d99e07bc33067fa1c770994bf4d - https://git.kernel.org/stable/c/dee1e51b54794e90763e70a3c78f27ba4fa930ec - https://git.kernel.org/stable/c/cd11d1a6114bd4bc6450ae59f6e110ec47362126
CVE ID: CVE-2022-49985 State: PUBLISHED Published: 2025-06-18T11:00:47.251Z Last Updated: 2025-06-18T11:00:47.251Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Don't use tnum_range on array range checking for poke descriptors Hsin-Wei reported a KASAN splat triggered by their BPF runtime fuzzer which is based on a customized syzkaller: BUG: KASAN: slab-out-of-bounds in bpf_int_jit_compile+0x1257/0x13f0 Read of size 8 at addr ffff888004e90b58 by task syz-executor.0/1489 CPU: 1 PID: 1489 Comm: syz-executor.0 Not tainted 5.19.0 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call
r.0 Not tainted 5.19.0 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x9c/0xc9 print_address_description.constprop.0+0x1f/0x1f0 ? bpf_int_jit_compile+0x1257/0x13f0 kasan_report.cold+0xeb/0x197 ? kvmalloc_node+0x170/0x200 ? bpf_int_jit_compile+0x1257/0x13f0 bpf_int_jit_compile+0x1257/0x13f0 ? arch_prepare_bpf_dispatcher+0xd0/0xd0 ? rcu_read_lock_sched_held+0x43/0x70 bpf_prog_select_runtime+0x3e8/0x640 ? bpf_obj_name_cpy+0x149/0x1b0 bpf_prog_load+0x102f/0x2220 ? __bpf_prog_put.constprop.0+0x220/0x220 ? find_held_lock+0x2c/0x110 ? __might_fault+0xd6/0x180 ? lock_downgrade+0x6e0/0x6e0 ? lock_is_held_type+0xa6/0x120 ?
220 ? find_held_lock+0x2c/0x110 ? __might_fault+0xd6/0x180 ? lock_downgrade+0x6e0/0x6e0 ? lock_is_held_type+0xa6/0x120 ? __might_fault+0x147/0x180 __sys_bpf+0x137b/0x6070 ? bpf_perf_link_attach+0x530/0x530 ? new_sync_read+0x600/0x600 ? __fget_files+0x255/0x450 ? lock_downgrade+0x6e0/0x6e0 ? fput+0x30/0x1a0 ? ksys_write+0x1a8/0x260 __x64_sys_bpf+0x7a/0xc0 ? syscall_enter_from_user_mode+0x21/0x70 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f917c4e2c2d The problem here is that a range of tnum_range(0, map->max_entries - 1) has limited ability to represent the concrete tight range with the tnum as the set of resulting states from value + mask can result in a sup
to represent the concrete tight range with the tnum as the set of resulting states from value + mask can result in a superset of the actual intended range, and as such a tnum_in(range, reg->var_off) check may yield true when it shouldn't, for example tnum_range(0, 2) would result in 00XX -> v = 0000, m = 0011 such that the intended set of {0, 1, 2} is here represented by a less precise superset of {0, 1, 2, 3}. As the register is known const scalar, really just use the concrete reg->var_off.value for the upper index check. References: - https://git.kernel.org/stable/c/e8979807178434db8ceaa84dfcd44363e71e50bb - https://git.kernel.org/stable/c/4f672112f8665102a5842c170be1713f8ff95919 - https:/
807178434db8ceaa84dfcd44363e71e50bb - https://git.kernel.org/stable/c/4f672112f8665102a5842c170be1713f8ff95919 - https://git.kernel.org/stable/c/a36df92c7ff7ecde2fb362241d0ab024dddd0597 - https://git.kernel.org/stable/c/a657182a5c5150cdfacb6640aad1d2712571a409
CVE ID: CVE-2022-49986 State: PUBLISHED Published: 2025-06-18T11:00:47.985Z Last Updated: 2025-06-18T11:00:47.985Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq storvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as it doesn't need to make forward progress under memory pressure. Marking this workqueue as WQ_MEM_RECLAIM may cause deadlock while flushing a non-WQ_MEM_RECLAIM workqueue. In the current state it causes the following warning: [ 14.506347] ------------[ cut here ]------------ [ 14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remo
[ 14.506347] ------------[ cut here ]------------ [ 14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun is flushing !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn [ 14.506360] WARNING: CPU: 0 PID: 8 at <-snip->kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130 [ 14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu [ 14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022 [ 14.506393] Workqueue: storvsc_error_wq_0 storvsc_remove_lun [ 14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130 <-snip-> [ 14.506408] Call Trace: [ 14.506412] __flush_work
lun [ 14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130 <-snip-> [ 14.506408] Call Trace: [ 14.506412] __flush_work+0xf1/0x1c0 [ 14.506414] __cancel_work_timer+0x12f/0x1b0 [ 14.506417] ? kernfs_put+0xf0/0x190 [ 14.506418] cancel_delayed_work_sync+0x13/0x20 [ 14.506420] disk_block_events+0x78/0x80 [ 14.506421] del_gendisk+0x3d/0x2f0 [ 14.506423] sr_remove+0x28/0x70 [ 14.506427] device_release_driver_internal+0xef/0x1c0 [ 14.506428] device_release_driver+0x12/0x20 [ 14.506429] bus_remove_device+0xe1/0x150 [ 14.506431] device_del+0x167/0x380 [ 14.506432] __scsi_remove_device+0x11d/0x150 [ 14.506433] scsi_remove_device+0x26/0x40 [ 14.506434] storvsc_remove_lun+0x40/0x60 [ 14.506436] process
ice+0x11d/0x150 [ 14.506433] scsi_remove_device+0x26/0x40 [ 14.506434] storvsc_remove_lun+0x40/0x60 [ 14.506436] process_one_work+0x209/0x400 [ 14.506437] worker_thread+0x34/0x400 [ 14.506439] kthread+0x121/0x140 [ 14.506440] ? process_one_work+0x400/0x400 [ 14.506441] ? kthread_park+0x90/0x90 [ 14.506443] ret_from_fork+0x35/0x40 [ 14.506445] ---[ end trace 2d9633159fdc6ee7 ]--- References: - https://git.kernel.org/stable/c/b692c238ddfa61f00d97c4c1f021425d132ba96f - https://git.kernel.org/stable/c/b4c928ace9a123629eeb14ec5d7ee8f73e5ac668 - https://git.kernel.org/stable/c/46fcb0fc884db78a0384be92cc2a51927e6581b8 - https://git.kernel.org/stable/c/cd2a50d0a097a42b6de283377da98ff757505120 - http
fcb0fc884db78a0384be92cc2a51927e6581b8 - https://git.kernel.org/stable/c/cd2a50d0a097a42b6de283377da98ff757505120 - https://git.kernel.org/stable/c/828f57ac75eaccd6607ee4d1468d34e983e32c68 - https://git.kernel.org/stable/c/d957e7ffb2c72410bcc1a514153a46719255a5da
CVE ID: CVE-2022-49987 State: PUBLISHED Published: 2025-06-18T11:00:48.687Z Last Updated: 2025-06-18T11:00:48.687Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: md: call __md_stop_writes in md_stop From the link [1], we can see raid1d was running even after the path raid_dtr -> md_stop -> __md_stop. Let's stop write first in destructor to align with normal md-raid to fix the KASAN issue. [1]. https://lore.kernel.org/linux-raid/CAPhsuW5gc4AakdGNdF8ubpezAuDLFOYUO_sfMZcec6hQFm8nhg@mail.gmail.com/T/#m7f12bf90481c02c6d2da68c64aeed4779b7df74a References: - https://git.kernel.org/stable/c/1678ca35b80a94d474fdc31e2497ce5d7ed52512 - ht
02c6d2da68c64aeed4779b7df74a References: - https://git.kernel.org/stable/c/1678ca35b80a94d474fdc31e2497ce5d7ed52512 - https://git.kernel.org/stable/c/690b5c90fd2d81fd1d2b6110fa36783232f6dce2 - https://git.kernel.org/stable/c/8e7fb19f1a744fd34e982633ced756fee0498ef7 - https://git.kernel.org/stable/c/a5a58fab556bfe618b4c9719eb85712d78c6cb10 - https://git.kernel.org/stable/c/661c01b2181d9413c799127f13143583b69f20fd - https://git.kernel.org/stable/c/f42a9819ba84bed2e609a4dff56af37063dcabdc - https://git.kernel.org/stable/c/0dd84b319352bb8ba64752d4e45396d8b13e6018
CVE ID: CVE-2022-49988 State: REJECTED Published: 2025-06-18T11:00:49.432Z Last Updated: 2025-06-18T14:18:12.024Z Description: No description available.
CVE ID: CVE-2022-49989 State: PUBLISHED Published: 2025-06-18T11:00:50.126Z Last Updated: 2025-06-18T11:00:50.126Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: xen/privcmd: fix error exit of privcmd_ioctl_dm_op() The error exit of privcmd_ioctl_dm_op() is calling unlock_pages() potentially with pages being NULL, leading to a NULL dereference. Additionally lock_pages() doesn't check for pin_user_pages_fast() having been completely successful, resulting in potentially not locking all pages into memory. This could result in sporadic failures when using the related memory in user mode. Fix all of that by calling unlock_pages() al
uld result in sporadic failures when using the related memory in user mode. Fix all of that by calling unlock_pages() always with the real number of pinned pages, which will be zero in case pages being NULL, and by checking the number of pages pinned by pin_user_pages_fast() matching the expected number of pages. References: - https://git.kernel.org/stable/c/6de50db104af0dc921f593fd95c55db86a52ceef - https://git.kernel.org/stable/c/c2b7bae7c90051fd6a679d5dee00400d67ebbf4a - https://git.kernel.org/stable/c/45d47bd9b96e7874b98dbcc7602fe2826c5d62a6 - https://git.kernel.org/stable/c/c5deb27895e017a0267de0a20d140ad5fcc55a54
CVE ID: CVE-2022-49990 State: PUBLISHED Published: 2025-06-18T11:00:51.035Z Last Updated: 2025-06-18T11:00:51.035Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: s390: fix double free of GS and RI CBs on fork() failure The pointers for guarded storage and runtime instrumentation control blocks are stored in the thread_struct of the associated task. These pointers are initially copied on fork() via arch_dup_task_struct() and then cleared via copy_thread() before fork() returns. If fork() happens to fail after the initial task dup and before copy_thread(), the newly allocated task and associated thread_struct memory are freed via
he initial task dup and before copy_thread(), the newly allocated task and associated thread_struct memory are freed via free_task() -> arch_release_task_struct(). This results in a double free of the guarded storage and runtime info structs because the fields in the failed task still refer to memory associated with the source task. This problem can manifest as a BUG_ON() in set_freepointer() (with CONFIG_SLAB_FREELIST_HARDENED enabled) or KASAN splat (if enabled) when running trinity syscall fuzz tests on s390x. To avoid this problem, clear the associated pointer fields in arch_dup_task_struct() immediately after the new task is copied. Note that the RI flag is still cleared in copy_thread(
arch_dup_task_struct() immediately after the new task is copied. Note that the RI flag is still cleared in copy_thread() because it resides in thread stack memory and that is where stack info is copied. References: - https://git.kernel.org/stable/c/25a95303b9e513cd2978aacc385d06e6fec23d07 - https://git.kernel.org/stable/c/cacd522e6652fbc2dc0cc6ae11c4e30782fef14b - https://git.kernel.org/stable/c/297ae7e87a87a001dd3dfeac1cb26a42fd929708 - https://git.kernel.org/stable/c/8195e065abf3df84eb0ad2987e76a40f21d1791c - https://git.kernel.org/stable/c/fbdc482d43eda40a70de4b0155843d5472f6de62 - https://git.kernel.org/stable/c/13cccafe0edcd03bf1c841de8ab8a1c8e34f77d9
CVE ID: CVE-2022-49991 State: PUBLISHED Published: 2025-06-18T11:00:51.745Z Last Updated: 2025-06-18T11:00:51.745Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: avoid corrupting page->mapping in hugetlb_mcopy_atomic_pte In MCOPY_ATOMIC_CONTINUE case with a non-shared VMA, pages in the page cache are installed in the ptes. But hugepage_add_new_anon_rmap is called for them mistakenly because they're not vm_shared. This will corrupt the page->mapping used by page cache code. References: - https://git.kernel.org/stable/c/da60ddd80d09f8371fbba1a238a4b318d13ba698 - https://git.kernel.org/stable/c/3ada1b3e58db255a14ec73a5
.kernel.org/stable/c/da60ddd80d09f8371fbba1a238a4b318d13ba698 - https://git.kernel.org/stable/c/3ada1b3e58db255a14ec73a59d7913e84dc5a8a4 - https://git.kernel.org/stable/c/ab74ef708dc51df7cf2b8a890b9c6990fac5c0c6
CVE ID: CVE-2022-49992 State: PUBLISHED Published: 2025-06-18T11:00:52.581Z Last Updated: 2025-06-18T11:00:52.581Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/mprotect: only reference swap pfn page if type match Yu Zhao reported a bug after the commit "mm/swap: Add swp_offset_pfn() to fetch PFN from swap entry" added a check in swp_offset_pfn() for swap type [1]: kernel BUG at include/linux/swapops.h:117! CPU: 46 PID: 5245 Comm: EventManager_De Tainted: G S O L 6.0.0-dbg-DEV #2 RIP: 0010:pfn_swap_entry_to_page+0x72/0xf0 Code: c6 48 8b 36 48 83 fe ff 74 53 48 01 d1 48 83 c1 08 48 8b 09 f6 c1 01 75 7b 66 90 48 89 c1 48 8b 0
o_page+0x72/0xf0 Code: c6 48 8b 36 48 83 fe ff 74 53 48 01 d1 48 83 c1 08 48 8b 09 f6 c1 01 75 7b 66 90 48 89 c1 48 8b 09 f6 c1 01 74 74 5d c3 eb 9e <0f> 0b 48 ba ff ff ff ff 03 00 00 00 eb ae a9 ff 0f 00 00 75 13 48 RSP: 0018:ffffa59e73fabb80 EFLAGS: 00010282 RAX: 00000000ffffffe8 RBX: 0c00000000000000 RCX: ffffcd5440000000 RDX: 1ffffffffff7a80a RSI: 0000000000000000 RDI: 0c0000000000042b RBP: ffffa59e73fabb80 R08: ffff9965ca6e8bb8 R09: 0000000000000000 R10: ffffffffa5a2f62d R11: 0000030b372e9fff R12: ffff997b79db5738 R13: 000000000000042b R14: 0c0000000000042b R15: 1ffffffffff7a80a FS: 00007f549d1bb700(0000) GS:ffff99d3cf680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0
fffff7a80a FS: 00007f549d1bb700(0000) GS:ffff99d3cf680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000440d035b3180 CR3: 0000002243176004 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> change_pte_range+0x36e/0x880 change_p4d_range+0x2e8/0x670 change_protection_range+0x14e/0x2c0 mprotect_fixup+0x1ee/0x330 do_mprotect_pkey+0x34c/0x440 __x64_sys_mprotect+0x1d/0x30 It triggers because pfn_swap_entry_to_page() could be called upon e.g. a genuine swap entry. Fix it by only calling it when it's a write migration entry where the page*
ld be called upon e.g. a genuine swap entry. Fix it by only calling it when it's a write migration entry where the page* is used. [1] https://lore.kernel.org/lkml/CAOUHufaVC2Za-p8m0aiHw6YkheDcrO-C3wRGixwDS32VTS+k1w@mail.gmail.com/ References: - https://git.kernel.org/stable/c/5fcf81e308d1f4ae95f31690d2a80b7061385ff9 - https://git.kernel.org/stable/c/3d2f78f08cd8388035ac375e731ec1ac1b79b09d
CVE ID: CVE-2022-49993 State: PUBLISHED Published: 2025-06-18T11:00:53.487Z Last Updated: 2025-06-18T11:00:53.487Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: loop: Check for overflow while configuring loop The userspace can configure a loop using an ioctl call, wherein a configuration of type loop_config is passed (see lo_ioctl()'s case on line 1550 of drivers/block/loop.c). This proceeds to call loop_configure() which in turn calls loop_set_status_from_info() (see line 1050 of loop.c), passing &config->info which is of type loop_info64*. This function then sets the appropriate values, like the offset. loop_device has lo_of
fo which is of type loop_info64*. This function then sets the appropriate values, like the offset. loop_device has lo_offset of type loff_t (see line 52 of loop.c), which is typdef-chained to long long, whereas loop_info64 has lo_offset of type __u64 (see line 56 of include/uapi/linux/loop.h). The function directly copies offset from info to the device as follows (See line 980 of loop.c): lo->lo_offset = info->lo_offset; This results in an overflow, which triggers a warning in iomap_iter() due to a call to iomap_iter_done() which has: WARN_ON_ONCE(iter->iomap.offset > iter->pos); Thus, check for negative value during loop_set_status_from_info(). Bug report: https://syzkaller.appspot.com/bug?
>pos); Thus, check for negative value during loop_set_status_from_info(). Bug report: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a29e References: - https://git.kernel.org/stable/c/18e28817cb516b39de6281f6db9b0618b2cc7b42 - https://git.kernel.org/stable/c/adf0112d9b8acb03485624220b4934f69bf13369 - https://git.kernel.org/stable/c/a217715338fd48f72114725aa7a40e484a781ca7 - https://git.kernel.org/stable/c/b40877b8562c5720d0a7fce20729f56b75a3dede - https://git.kernel.org/stable/c/6858933131d0dadac071c4d33335a9ea4b8e76cf - https://git.kernel.org/stable/c/0455bef69028c65065f16bb04635591b2374249b - https://git.kernel.org/stable/c/9be7fa7ead18a48940df7b59d993bbc8b9055c15
le/c/0455bef69028c65065f16bb04635591b2374249b - https://git.kernel.org/stable/c/9be7fa7ead18a48940df7b59d993bbc8b9055c15 - https://git.kernel.org/stable/c/c490a0b5a4f36da3918181a8acdc6991d967c5f3
CVE ID: CVE-2022-49994 State: PUBLISHED Published: 2025-06-18T11:00:54.413Z Last Updated: 2025-06-18T11:00:54.413Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bootmem: remove the vmemmap pages from kmemleak in put_page_bootmem The vmemmap pages is marked by kmemleak when allocated from memblock. Remove it from kmemleak when freeing the page. Otherwise, when we reuse the page, kmemleak may report such an error and then stop working. kmemleak: Cannot insert 0xffff98fb6eab3d40 into the object search tree (overlaps existing) kmemleak: Kernel memory leak detector disabled kmemleak: Object 0xffff98fb6be00000 (size 335544320): kmem
laps existing) kmemleak: Kernel memory leak detector disabled kmemleak: Object 0xffff98fb6be00000 (size 335544320): kmemleak: comm "swapper", pid 0, jiffies 4294892296 kmemleak: min_count = 0 kmemleak: count = 0 kmemleak: flags = 0x1 kmemleak: checksum = 0 kmemleak: backtrace: References: - https://git.kernel.org/stable/c/16a12ee619e39e8112f61b603255c16b73b6264b - https://git.kernel.org/stable/c/9ae15c4ba2be1e5a62503b6d873e84beb5fcbb5a - https://git.kernel.org/stable/c/dd0ff4d12dd284c334f7e9b07f8f335af856ac78