Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
_drv+0x183/0x200 drivers/base/bus.c:429 __device_attach+0x359/0x570 drivers/base/dd.c:1015 bus_probe_device+0xba/0x1e0 drivers/base/bus.c:489 device_add+0xb48/0xfd0 drivers/base/core.c:3696 usb_new_device+0xbdd/0x18f0 drivers/usb/core/hub.c:2620 hub_port_connect drivers/usb/core/hub.c:5477 [inline] hub_port_connect_change drivers/usb/core/hub.c:5617 [inline] port_event drivers/usb/core/hub.c:5773 [inline] hub_event+0x2efe/0x5730 drivers/usb/core/hub.c:5855 process_one_work+0x8a9/0x11d0 kernel/workqueue.c:2292 worker_thread+0xa47/0x1200 kernel/workqueue.c:2439 kthread+0x28d/0x320 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> ===============================
0x320 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> ================================================================ Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/93d646911be1e5be20d4f5d6c48359464cef0097 - https://git.kernel.org/stable/c/36a9a2647810e57e704dde59abdf831380ca9102 - https://git.kernel.org/stable/c/791a2d9e87c411aec0b9b2fb735fd15e48af9de9 - https://git.kernel.org/stable/c/9ecb4af39f80cdda3e57825923243ec11e48be6b - https://git.kernel.org/stable/c/0fb15ae3b0a9221be01715dac0335647c79f3362
CVE ID: CVE-2025-37898 State: PUBLISHED Published: 2025-05-20T15:21:34.055Z Last Updated: 2025-05-26T05:23:17.320Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: powerpc64/ftrace: fix module loading without patchable function entries get_stubs_size assumes that there must always be at least one patchable function entry, which is not always the case (modules that export data but no code), otherwise it returns -ENOEXEC and thus the section header sh_size is set to that value. During module_memory_alloc() the size is passed to execmem_alloc() after being page-aligned and thus set to zero which will cause it to fail the allocation
e is passed to execmem_alloc() after being page-aligned and thus set to zero which will cause it to fail the allocation (and thus module loading) as __vmalloc_node_range() checks for zero-sized allocs and returns null: [ 115.466896] module_64: cast_common: doesn't contain __patchable_function_entries. [ 115.469189] ------------[ cut here ]------------ [ 115.469496] WARNING: CPU: 0 PID: 274 at mm/vmalloc.c:3778 __vmalloc_node_range_noprof+0x8b4/0x8f0 ... [ 115.478574] ---[ end trace 0000000000000000 ]--- [ 115.479545] execmem: unable to allocate memory Fix this by removing the check completely, since it is anyway not helpful to propagate this as an error upwards. References: - https://git.ker
he check completely, since it is anyway not helpful to propagate this as an error upwards. References: - https://git.kernel.org/stable/c/358b559afec7806b9d01c2405b490e782c347022 - https://git.kernel.org/stable/c/534f5a8ba27863141e29766467a3e1f61bcb47ac
CVE ID: CVE-2025-37899 State: PUBLISHED Published: 2025-05-20T15:21:34.782Z Last Updated: 2025-05-26T05:23:18.609Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in session logoff The sess->user object can currently be in use by another thread, for example if another connection has sent a session setup request to bind to the session being free'd. The handler for that connection could be in the smb2_sess_setup function which makes use of sess->user. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/d5ec1d79509b3ee01de02c236f096bc050221b7f - https://git.kern
ram Container: References: - https://git.kernel.org/stable/c/d5ec1d79509b3ee01de02c236f096bc050221b7f - https://git.kernel.org/stable/c/02d16046cd11a5c037b28c12ffb818c56dd3ef43 - https://git.kernel.org/stable/c/2fc9feff45d92a92cd5f96487655d5be23fb7e2b
CVE ID: CVE-2025-37900 State: PUBLISHED Published: 2025-05-20T15:21:35.433Z Last Updated: 2025-05-26T05:23:19.890Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iommu: Fix two issues in iommu_copy_struct_from_user() In the review for iommu_copy_struct_to_user() helper, Matt pointed out that a NULL pointer should be rejected prior to dereferencing it: https://lore.kernel.org/all/86881827-8E2D-461C-BDA3-FA8FD14C343C@nvidia.com And Alok pointed out a typo at the same time: https://lore.kernel.org/all/480536af-6830-43ce-a327-adbd13dc3f1d@oracle.com Since both issues were copied from iommu_copy_struct_from_user(), fix them first in
30-43ce-a327-adbd13dc3f1d@oracle.com Since both issues were copied from iommu_copy_struct_from_user(), fix them first in the current header. References: - https://git.kernel.org/stable/c/2e303d010722787dc84d94f68d70fe10dfc1b9ea - https://git.kernel.org/stable/c/967d6f0d9a20a1bf15ee7ed881e2d4e532e22709 - https://git.kernel.org/stable/c/30a3f2f3e4bd6335b727c83c08a982d969752bc1
CVE ID: CVE-2025-37901 State: PUBLISHED Published: 2025-05-20T15:21:36.062Z Last Updated: 2025-11-03T19:57:06.588Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: irqchip/qcom-mpm: Prevent crash when trying to handle non-wake GPIOs On Qualcomm chipsets not all GPIOs are wakeup capable. Those GPIOs do not have a corresponding MPM pin and should not be handled inside the MPM driver. The IRQ domain hierarchy is always applied, so it's required to explicitly disconnect the hierarchy for those. The pinctrl-msm driver marks these with GPIO_NO_WAKE_IRQ. qcom-pdc has a check for this, but irq-qcom-mpm is currently missing the check. Thi
r marks these with GPIO_NO_WAKE_IRQ. qcom-pdc has a check for this, but irq-qcom-mpm is currently missing the check. This is causing crashes when setting up interrupts for non-wake GPIOs: root@rb1:~# gpiomon -c gpiochip1 10 irq: IRQ159: trimming hierarchy from :soc@0:interrupt-controller@f200000-1 Unable to handle kernel paging request at virtual address ffff8000a1dc3820 Hardware name: Qualcomm Technologies, Inc. Robotics RB1 (DT) pc : mpm_set_type+0x80/0xcc lr : mpm_set_type+0x5c/0xcc Call trace: mpm_set_type+0x80/0xcc (P) qcom_mpm_set_type+0x64/0x158 irq_chip_set_type_parent+0x20/0x38 msm_gpio_irq_set_type+0x50/0x530 __irq_set_trigger+0x60/0x184 __setup_irq+0x304/0x6bc request_threaded_irq
ent+0x20/0x38 msm_gpio_irq_set_type+0x50/0x530 __irq_set_trigger+0x60/0x184 __setup_irq+0x304/0x6bc request_threaded_irq+0xc8/0x19c edge_detector_setup+0x260/0x364 linereq_create+0x420/0x5a8 gpio_ioctl+0x2d4/0x6c0 Fix this by copying the check for GPIO_NO_WAKE_IRQ from qcom-pdc.c, so that MPM is removed entirely from the hierarchy for non-wake GPIOs. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/45aced97f01d5ab14c8a2a60f6748f18c501c3f5 - https://git.kernel.org/stable/c/dfbaecf7e38f5e9bfa5e47a1e525ffbb58bab8cf - https://git.kernel.org/stable/c/f102342360950b56959e5fff4a874ea88ae13758 - https://git.kernel.org/stable/c/d5c10448f411a925dd5900578
kernel.org/stable/c/f102342360950b56959e5fff4a874ea88ae13758 - https://git.kernel.org/stable/c/d5c10448f411a925dd59005785cb971f0626e032 - https://git.kernel.org/stable/c/38a05c0b87833f5b188ae43b428b1f792df2b384
CVE ID: CVE-2025-37902 State: REJECTED Published: 2025-05-20T15:21:36.708Z Last Updated: 2025-05-26T10:17:48.887Z Description: No description available.
CVE ID: CVE-2025-37903 State: PUBLISHED Published: 2025-05-20T15:21:37.400Z Last Updated: 2025-11-03T19:57:07.972Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix slab-use-after-free in hdcp The HDCP code in amdgpu_dm_hdcp.c copies pointers to amdgpu_dm_connector objects without incrementing the kref reference counts. When using a USB-C dock, and the dock is unplugged, the corresponding amdgpu_dm_connector objects are freed, creating dangling pointers in the HDCP code. When the dock is plugged back, the dangling pointers are dereferenced, resulting in a slab-use-after-free: [ 66.775837] BUG: KASAN: slab-use-
ged back, the dangling pointers are dereferenced, resulting in a slab-use-after-free: [ 66.775837] BUG: KASAN: slab-use-after-free in event_property_validate+0x42f/0x6c0 [amdgpu] [ 66.776171] Read of size 4 at addr ffff888127804120 by task kworker/0:1/10 [ 66.776179] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.14.0-rc7-00180-g54505f727a38-dirty #233 [ 66.776183] Hardware name: HP HP Pavilion Aero Laptop 13-be0xxx/8916, BIOS F.17 12/18/2024 [ 66.776186] Workqueue: events event_property_validate [amdgpu] [ 66.776494] Call Trace: [ 66.776496] <TASK> [ 66.776497] dump_stack_lvl+0x70/0xa0 [ 66.776504] print_report+0x175/0x555 [ 66.776507] ? __virt_addr_valid+0x243/0x450 [ 66.776510] ? k
_stack_lvl+0x70/0xa0 [ 66.776504] print_report+0x175/0x555 [ 66.776507] ? __virt_addr_valid+0x243/0x450 [ 66.776510] ? kasan_complete_mode_report_info+0x66/0x1c0 [ 66.776515] kasan_report+0xeb/0x1c0 [ 66.776518] ? event_property_validate+0x42f/0x6c0 [amdgpu] [ 66.776819] ? event_property_validate+0x42f/0x6c0 [amdgpu] [ 66.777121] __asan_report_load4_noabort+0x14/0x20 [ 66.777124] event_property_validate+0x42f/0x6c0 [amdgpu] [ 66.777342] ? __lock_acquire+0x6b40/0x6b40 [ 66.777347] ? enable_assr+0x250/0x250 [amdgpu] [ 66.777571] process_one_work+0x86b/0x1510 [ 66.777575] ? pwq_dec_nr_in_flight+0xcf0/0xcf0 [ 66.777578] ? assign_work+0x16b/0x280 [ 66.777580] ? lock_is_held_type+0xa3/0x130 [ 66.7
q_dec_nr_in_flight+0xcf0/0xcf0 [ 66.777578] ? assign_work+0x16b/0x280 [ 66.777580] ? lock_is_held_type+0xa3/0x130 [ 66.777583] worker_thread+0x5c0/0xfa0 [ 66.777587] ? process_one_work+0x1510/0x1510 [ 66.777588] kthread+0x3a2/0x840 [ 66.777591] ? kthread_is_per_cpu+0xd0/0xd0 [ 66.777594] ? trace_hardirqs_on+0x4f/0x60 [ 66.777597] ? _raw_spin_unlock_irq+0x27/0x60 [ 66.777599] ? calculate_sigpending+0x77/0xa0 [ 66.777602] ? kthread_is_per_cpu+0xd0/0xd0 [ 66.777605] ret_from_fork+0x40/0x90 [ 66.777607] ? kthread_is_per_cpu+0xd0/0xd0 [ 66.777609] ret_from_fork_asm+0x11/0x20 [ 66.777614] </TASK> [ 66.777643] Allocated by task 10: [ 66.777646] kasan_save_stack+0x39/0x60 [ 66.777649] kasan_save_tra
6.777614] </TASK> [ 66.777643] Allocated by task 10: [ 66.777646] kasan_save_stack+0x39/0x60 [ 66.777649] kasan_save_track+0x14/0x40 [ 66.777652] kasan_save_alloc_info+0x37/0x50 [ 66.777655] __kasan_kmalloc+0xbb/0xc0 [ 66.777658] __kmalloc_cache_noprof+0x1c8/0x4b0 [ 66.777661] dm_dp_add_mst_connector+0xdd/0x5c0 [amdgpu] [ 66.777880] drm_dp_mst_port_add_connector+0x47e/0x770 [drm_display_helper] [ 66.777892] drm_dp_send_link_address+0x1554/0x2bf0 [drm_display_helper] [ 66.777901] drm_dp_check_and_send_link_address+0x187/0x1f0 [drm_display_helper] [ 66.777909] drm_dp_mst_link_probe_work+0x2b8/0x410 [drm_display_helper] [ 66.777917] process_one_work+0x86b/0x1510 [ 66.777919] worker_thread+0x5c0
_probe_work+0x2b8/0x410 [drm_display_helper] [ 66.777917] process_one_work+0x86b/0x1510 [ 66.777919] worker_thread+0x5c0/0xfa0 [ 66.777922] kthread+0x3a2/0x840 [ 66.777925] ret_from_fork+0x40/0x90 [ 66.777927] ret_from_fork_asm+0x11/0x20 [ 66.777932] Freed by task 1713: [ 66.777935] kasan_save_stack+0x39/0x60 [ 66.777938] kasan_save_track+0x14/0x40 [ 66.777940] kasan_save_free_info+0x3b/0x60 [ 66.777944] __kasan_slab_free+0x52/0x70 [ 66.777946] kfree+0x13f/0x4b0 [ 66.777949] dm_dp_mst_connector_destroy+0xfa/0x150 [amdgpu] [ 66.778179] drm_connector_free+0x7d/0xb0 [ 66.778184] drm_mode_object_put.part.0+0xee/0x160 [ 66.778188] drm_mode_object_put+0x37/0x50 [ 66.778191] drm_atomic_state_defaul
4] drm_mode_object_put.part.0+0xee/0x160 [ 66.778188] drm_mode_object_put+0x37/0x50 [ 66.778191] drm_atomic_state_default_clear+0x220/0xd60 [ 66.778194] __drm_atomic_state_free+0x16e/0x2a0 [ 66.778197] drm_mode_atomic_ioctl+0x15ed/0x2ba0 [ 66.778200] drm_ioctl_kernel+0x17a/0x310 [ 66.778203] drm_ioctl+0x584/0xd10 [ 66.778206] amdgpu_drm_ioctl+0xd2/0x1c0 [amdgpu] [ 66.778375] __x64_sys_ioctl+0x139/0x1a0 [ 66.778378] x64_sys_call+0xee7/0xfb0 [ 66.778381] ---truncated--- Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/e25139c4aa5621f2db8e86688c33546cdd885e42 - https://git.kernel.org/stable/c/bbc66abcd297be67e3d835276e21e6fdc65205a6 - https://git.
5621f2db8e86688c33546cdd885e42 - https://git.kernel.org/stable/c/bbc66abcd297be67e3d835276e21e6fdc65205a6 - https://git.kernel.org/stable/c/dd329f04dda35a66e0c9ed462ba91bd5f2c8be70 - https://git.kernel.org/stable/c/3a782a83d130ceac6c98a87639ddd89640bff486 - https://git.kernel.org/stable/c/be593d9d91c5a3a363d456b9aceb71029aeb3f1d
CVE ID: CVE-2025-37904 State: PUBLISHED Published: 2025-05-20T15:21:38.075Z Last Updated: 2025-05-26T05:23:23.604Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: fix the inode leak in btrfs_iget() [BUG] There is a bug report that a syzbot reproducer can lead to the following busy inode at unmount time: BTRFS info (device loop1): last unmount of filesystem 1680000e-3c1e-4c46-84b6-56bd3909af50 VFS: Busy inodes after unmount of loop1 (btrfs) ------------[ cut here ]------------ kernel BUG at fs/super.c:650! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 48168 Comm: syz-executor Not tainted 6.15.0-rc2-004
! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 48168 Comm: syz-executor Not tainted 6.15.0-rc2-00471-g119009db2674 #2 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:generic_shutdown_super+0x2e9/0x390 fs/super.c:650 Call Trace: <TASK> kill_anon_super+0x3a/0x60 fs/super.c:1237 btrfs_kill_super+0x3b/0x50 fs/btrfs/super.c:2099 deactivate_locked_super+0xbe/0x1a0 fs/super.c:473 deactivate_super fs/super.c:506 [inline] deactivate_super+0xe2/0x100 fs/super.c:502 cleanup_mnt+0x21f/0x440 fs/namespace.c:1435 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mod
fs/namespace.c:1435 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop kernel/entry/common.c:114 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x269/0x290 kernel/entry/common.c:218 do_syscall_64+0xd4/0x250 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> [CAUSE] When btrfs_alloc_path() failed, btrfs_iget() directly returned without releasing the inode already allocated by btrfs_iget_locked(). This results the above busy inode and trigger the kernel BU
eleasing the inode already allocated by btrfs_iget_locked(). This results the above busy inode and trigger the kernel BUG. [FIX] Fix it by calling iget_failed() if btrfs_alloc_path() failed. If we hit error inside btrfs_read_locked_inode(), it will properly call iget_failed(), so nothing to worry about. Although the iget_failed() cleanup inside btrfs_read_locked_inode() is a break of the normal error handling scheme, let's fix the obvious bug and backport first, then rework the error handling later. References: - https://git.kernel.org/stable/c/30a339bece3a44ab0a821477139e84fb86af9761 - https://git.kernel.org/stable/c/48c1d1bb525b1c44b8bdc8e7ec5629cb6c2b9fc4
CVE ID: CVE-2025-37905 State: PUBLISHED Published: 2025-05-20T15:21:38.890Z Last Updated: 2025-11-03T19:57:09.443Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Balance device refcount when destroying devices Using device_find_child() to lookup the proper SCMI device to destroy causes an unbalance in device refcount, since device_find_child() calls an implicit get_device(): this, in turns, inhibits the call of the provided release methods upon devices destruction. As a consequence, one of the structures that is not freed properly upon destruction is the internal struct device_private dev->p populated by the
the structures that is not freed properly upon destruction is the internal struct device_private dev->p populated by the drivers subsystem core. KMemleak detects this situation since loading/unloding some SCMI driver causes related devices to be created/destroyed without calling any device_release method. unreferenced object 0xffff00000f583800 (size 512): comm "insmod", pid 227, jiffies 4294912190 hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 60 36 1d 8a 00 80 ff ff ........`6...... backtrace (crc 114e2eed): kmemleak_alloc+0xbc/0xd8 __kmalloc_cache_noprof+0x2dc/0x398 device_add+0x954/0x12d0 device_register+0x28/0x40 __scmi
d): kmemleak_alloc+0xbc/0xd8 __kmalloc_cache_noprof+0x2dc/0x398 device_add+0x954/0x12d0 device_register+0x28/0x40 __scmi_device_create.part.0+0x1bc/0x380 scmi_device_create+0x2d0/0x390 scmi_create_protocol_devices+0x74/0xf8 scmi_device_request_notifier+0x1f8/0x2a8 notifier_call_chain+0x110/0x3b0 blocking_notifier_call_chain+0x70/0xb0 scmi_driver_register+0x350/0x7f0 0xffff80000a3b3038 do_one_initcall+0x12c/0x730 do_init_module+0x1dc/0x640 load_module+0x4b20/0x5b70 init_module_from_file+0xec/0x158 $ ./scripts/faddr2line ./vmlinux device_add+0x954/0x12d0 device_add+0x954/0x12d0: kmalloc_noprof at include/linux/slab.h:901 (inlined by) kzalloc_noprof at include/linux/slab.h:1037 (inlined by) dev
d0: kmalloc_noprof at include/linux/slab.h:901 (inlined by) kzalloc_noprof at include/linux/slab.h:1037 (inlined by) device_private_init at drivers/base/core.c:3510 (inlined by) device_add at drivers/base/core.c:3561 Balance device refcount by issuing a put_device() on devices found via device_find_child(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/91ff1e9652fb9beb0174267d6bb38243dff211bb - https://git.kernel.org/stable/c/ff4273d47da81b95ed9396110bcbd1b7b7470fe8 - https://git.kernel.org/stable/c/2fbf6c9695ad9f05e7e5c166bf43fac7cb3276b3 - https://git.kernel.org/stable/c/969d8beaa2e374387bf9aa5602ef84fc50bb48d8 - https://git.kernel.org/sta
bf43fac7cb3276b3 - https://git.kernel.org/stable/c/969d8beaa2e374387bf9aa5602ef84fc50bb48d8 - https://git.kernel.org/stable/c/8a8a3547d5c4960da053df49c75bf623827a25da - https://git.kernel.org/stable/c/9ca67840c0ddf3f39407339624cef824a4f27599
CVE ID: CVE-2025-37906 State: PUBLISHED Published: 2025-05-20T15:21:39.633Z Last Updated: 2025-05-26T05:23:26.188Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ublk: fix race between io_uring_cmd_complete_in_task and ublk_cancel_cmd ublk_cancel_cmd() calls io_uring_cmd_done() to complete uring_cmd, but we may have scheduled task work via io_uring_cmd_complete_in_task() for dispatching request, then kernel crash can be triggered. Fix it by not trying to canceling the command if ublk block request is started. References: - https://git.kernel.org/stable/c/fb2eb9ddf556f93fef45201e1f9d2b8674bcc975 - https://git.kernel.org/stable/c
References: - https://git.kernel.org/stable/c/fb2eb9ddf556f93fef45201e1f9d2b8674bcc975 - https://git.kernel.org/stable/c/f40139fde5278d81af3227444fd6e76a76b9506d
CVE ID: CVE-2025-37907 State: PUBLISHED Published: 2025-05-20T15:21:40.482Z Last Updated: 2025-05-26T05:23:27.446Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix locking order in ivpu_job_submit Fix deadlock in job submission and abort handling. When a thread aborts currently executing jobs due to a fault, it first locks the global lock protecting submitted_jobs (#1). After the last job is destroyed, it proceeds to release the related context and locks file_priv (#2). Meanwhile, in the job submission thread, the file_priv lock (#2) is taken first, and then the submitted_jobs lock (#1) is obtained when a job is a
ission thread, the file_priv lock (#2) is taken first, and then the submitted_jobs lock (#1) is obtained when a job is added to the submitted jobs list. CPU0 CPU1 ---- ---- (for example due to a fault) (jobs submissions keep coming) lock(&vdev->submitted_jobs_lock) #1 ivpu_jobs_abort_all() job_destroy() lock(&file_priv->lock) #2 lock(&vdev->submitted_jobs_lock) #1 file_priv_release() lock(&vdev->context_list_lock) lock(&file_priv->lock) #2 This order of locking causes a deadlock. To resolve this issue, change the order of locking in ivpu_job_submit(). References: - https://git.kernel.org/stable/c/079d2622f8c9e0c380149645fff21d35c59ce6ff - https://git.kernel.org/stable/c/b9b70924a272c2d720233
git.kernel.org/stable/c/079d2622f8c9e0c380149645fff21d35c59ce6ff - https://git.kernel.org/stable/c/b9b70924a272c2d72023306bc56f521c056212ee - https://git.kernel.org/stable/c/ab680dc6c78aa035e944ecc8c48a1caab9f39924
CVE ID: CVE-2025-37908 State: PUBLISHED Published: 2025-05-20T15:21:41.121Z Last Updated: 2025-05-26T05:23:28.714Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm, slab: clean up slab->obj_exts always When memory allocation profiling is disabled at runtime or due to an error, shutdown_mem_profiling() is called: slab->obj_exts which previously allocated remains. It won't be cleared by unaccount_slab() because of mem_alloc_profiling_enabled() not true. It's incorrect, slab->obj_exts should always be cleaned up in unaccount_slab() to avoid following error: [...]BUG: Bad page state in process... .. [...]page dumped because: page
in unaccount_slab() to avoid following error: [...]BUG: Bad page state in process... .. [...]page dumped because: page still charged to cgroup [andriy.shevchenko@linux.intel.com: fold need_slab_obj_ext() into its only user] References: - https://git.kernel.org/stable/c/dab2a13059a475b6392550f882276e170fe2fcff - https://git.kernel.org/stable/c/01db0e1a48345aa1937f3bdfc7c7108d03ebcf7e - https://git.kernel.org/stable/c/be8250786ca94952a19ce87f98ad9906448bc9ef
CVE ID: CVE-2025-37909 State: PUBLISHED Published: 2025-05-20T15:21:41.804Z Last Updated: 2025-11-03T19:57:10.900Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: lan743x: Fix memleak issue when GSO enabled Always map the `skb` to the LS descriptor. Previously skb was mapped to EXT descriptor when the number of fragments is zero with GSO enabled. Mapping the skb to EXT descriptor prevents it from being freed, leading to a memory leak Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/093855ce90177488eac772de4eefbb909033ce5f - https://git.kernel.org/stable/c/6c65ee5ad632eb8dcd3a9
git.kernel.org/stable/c/093855ce90177488eac772de4eefbb909033ce5f - https://git.kernel.org/stable/c/6c65ee5ad632eb8dcd3a91cf5dc99b22535f44d9 - https://git.kernel.org/stable/c/df993daa4c968b4b23078eacc248f6502ede8664 - https://git.kernel.org/stable/c/a0e0efbabbbe6a1859bc31bf65237ce91e124b9b - https://git.kernel.org/stable/c/dae1ce27ceaea7e1522025b15252e3cc52802622 - https://git.kernel.org/stable/c/189b05f189cac9fd233ef04d31cb5078c4d09c39 - https://git.kernel.org/stable/c/f42c18e2f14c1b1fdd2a5250069a84bc854c398c - https://git.kernel.org/stable/c/2d52e2e38b85c8b7bc00dca55c2499f46f8c8198
CVE ID: CVE-2025-37910 State: PUBLISHED Published: 2025-05-20T15:21:42.639Z Last Updated: 2025-05-26T05:23:31.339Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ptp: ocp: Fix NULL dereference in Adva board SMA sysfs operations On Adva boards, SMA sysfs store/get operations can call __handle_signal_outputs() or __handle_signal_inputs() while the `irig` and `dcf` pointers are uninitialized, leading to a NULL pointer dereference in __handle_signal() and causing a kernel crash. Adva boards don't use `irig` or `dcf` functionality, so add Adva-specific callbacks `ptp_ocp_sma_adva_set_outputs()` and `ptp_ocp_sma_adva_set_inputs()` th