Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
tes on the current task. If current has TIF_IO_BITMAP set, but no bitmap installed, tss_update_io_bitmap() crashes with a NULL pointer dereference. There are two issues, which lead to that problem: 1) io_bitmap_exit() should not invoke task_update_io_bitmap() when the task, which is cleaned up, is not the current task. That's a clear indicator for a cleanup after a failed fork(). 2) A task should not have TIF_IO_BITMAP set and neither a bitmap installed nor IOPL emulation level 3 activated. This happens when a kernel thread is created in the context of a user space thread, which has TIF_IO_BITMAP set as the thread flags are copied and the IO bitmap pointer is cleared. Other than in the faile
which has TIF_IO_BITMAP set as the thread flags are copied and the IO bitmap pointer is cleared. Other than in the failed fork() case this has no impact because kernel threads including IO workers never return to user space and therefore never invoke tss_update_io_bitmap(). Cure this by adding the missing cleanups and checks: 1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if the to be cleaned up task is not the current task. 2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user space forks it is set later, when the IO bitmap is inherited in io_bitmap_share(). For paranoia sake, add a warning into tss_update_io_bitmap() to catch the case, when that code is invoked w
map_share(). For paranoia sake, add a warning into tss_update_io_bitmap() to catch the case, when that code is invoked with inconsistent state. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/d64b7b05a827f98d068f412969eef65489b0cf03 - https://git.kernel.org/stable/c/2dace5e016c991424a3dc6e83b1ae5dca8992d08 - https://git.kernel.org/stable/c/aa5ce1485562f20235b4c759eee5ab0c41d2c220 - https://git.kernel.org/stable/c/2cfcbe1554c119402e7382de974c26b0549899fe - https://git.kernel.org/stable/c/b3b3b6366dc8eb5b22edba9adc4bff3cdacfd64c - https://git.kernel.org/stable/c/73cfcc8445585b8af7e18be3c9246b851fdf336c - https://git.kernel.org/stable/c/8b68e9787
c - https://git.kernel.org/stable/c/73cfcc8445585b8af7e18be3c9246b851fdf336c - https://git.kernel.org/stable/c/8b68e978718f14fdcb080c2a7791c52a0d09bc6d
CVE ID: CVE-2025-38101 State: PUBLISHED Published: 2025-07-03T08:35:10.844Z Last Updated: 2025-07-28T04:12:15.362Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix buffer locking in ring_buffer_subbuf_order_set() Enlarge the critical section in ring_buffer_subbuf_order_set() to ensure that error handling takes place with per-buffer mutex held, thus preventing list corruption and other concurrency-related issues. References: - https://git.kernel.org/stable/c/e09c0600beea469b3ebf974464e526a02d59ad62 - https://git.kernel.org/stable/c/0fc9a295cd8e59c3636e97395e7c74a9c89fee42 - https://git.kernel.org/stable/c/40ee2afa
62 - https://git.kernel.org/stable/c/0fc9a295cd8e59c3636e97395e7c74a9c89fee42 - https://git.kernel.org/stable/c/40ee2afafc1d9fe3aa44a6fbe440d78a5c96a72e
CVE ID: CVE-2025-38102 State: PUBLISHED Published: 2025-07-03T08:35:12.255Z Last Updated: 2025-11-03T17:34:05.919Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify During our test, it is found that a warning can be trigger in try_grab_folio as follow: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130 Modules linked in: CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef) RIP: 0010:try_grab_folio+0x106/0x130 Call Trace: <TASK> follow_huge_pmd+0x240/0x8e0 follow_pmd_mask.constp
REEMPT(undef) RIP: 0010:try_grab_folio+0x106/0x130 Call Trace: <TASK> follow_huge_pmd+0x240/0x8e0 follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0 follow_pud_mask.constprop.0.isra.0+0x14a/0x170 follow_page_mask+0x1c2/0x1f0 __get_user_pages+0x176/0x950 __gup_longterm_locked+0x15b/0x1060 ? gup_fast+0x120/0x1f0 gup_fast_fallback+0x17e/0x230 get_user_pages_fast+0x5f/0x80 vmci_host_unlocked_ioctl+0x21c/0xf80 RIP: 0033:0x54d2cd ---[ end trace 0000000000000000 ]--- Digging into the source, context->notify_page may init by get_user_pages_fast and can be seen in vmci_ctx_unset_notify which will try to put_page. However get_user_pages_fast is not finished here and lead to following try_grab_folio warnin
which will try to put_page. However get_user_pages_fast is not finished here and lead to following try_grab_folio warning. The race condition is shown as follow: cpu0 cpu1 vmci_host_do_set_notify vmci_host_setup_notify get_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page); lockless_pages_from_mm gup_pgd_range gup_huge_pmd // update &context->notify_page vmci_host_do_set_notify vmci_ctx_unset_notify notify_page = context->notify_page; if (notify_page) put_page(notify_page); // page is freed __gup_longterm_locked __get_user_pages follow_trans_huge_pmd try_grab_folio // warn here To slove this, use local variable page to make notify_page can be seen after finish get_user_pages_fast. Ad
// warn here To slove this, use local variable page to make notify_page can be seen after finish get_user_pages_fast. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/74095bbbb19ca74a0368d857603a2438c88ca86c - https://git.kernel.org/stable/c/468aec888f838ce5174b96e0cb4396790d6f60ca - https://git.kernel.org/stable/c/b4209e4b778e4e57d0636e1c9fc07a924dbc6043 - https://git.kernel.org/stable/c/58a90db70aa6616411e5f69d1982d9b1dd97d774 - https://git.kernel.org/stable/c/6e3af836805ed1d7a699f76ec798626198917aa4 - https://git.kernel.org/stable/c/00ddc7dad55b7bbb78df80d6e174d0c4764dea0c - https://git.kernel.org/stable/c/75b5313c80c39a26d27cbb602f968a05576
/stable/c/00ddc7dad55b7bbb78df80d6e174d0c4764dea0c - https://git.kernel.org/stable/c/75b5313c80c39a26d27cbb602f968a05576c36f9 - https://git.kernel.org/stable/c/1bd6406fb5f36c2bb1e96e27d4c3e9f4d09edde4
CVE ID: CVE-2025-38103 State: PUBLISHED Published: 2025-07-03T08:35:13.941Z Last Updated: 2025-11-03T17:34:07.793Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse() Update struct hid_descriptor to better reflect the mandatory and optional parts of the HID Descriptor as per USB HID 1.11 specification. Note: the kernel currently does not parse any optional HID class descriptors, only the mandatory report descriptor. Update all references to member element desc[0] to rpt_desc. Add test to verify bLength and bNumDescriptors values are valid. Replace the for loop with
element desc[0] to rpt_desc. Add test to verify bLength and bNumDescriptors values are valid. Replace the for loop with direct access to the mandatory HID class descriptor member for the report descriptor. This eliminates the possibility of getting an out-of-bounds fault. Add a warning message if the HID descriptor contains any unsupported optional HID class descriptors. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/7a6d6b68db128da2078ccd9a751dfa3f75c9cf5b - https://git.kernel.org/stable/c/41827a2dbdd7880df9881506dee13bc88d4230bb - https://git.kernel.org/stable/c/1df80d748f984290c895e843401824215dcfbfb0 - https://git.kernel.org/stable/c/a8f
d4230bb - https://git.kernel.org/stable/c/1df80d748f984290c895e843401824215dcfbfb0 - https://git.kernel.org/stable/c/a8f842534807985d3a676006d140541b87044345 - https://git.kernel.org/stable/c/4fa7831cf0ac71a0a345369d1a6084f2b096e55e - https://git.kernel.org/stable/c/74388368927e9c52a69524af5bbd6c55eb4690de - https://git.kernel.org/stable/c/485e1b741eb838cbe1d6b0e81e5ab62ae6c095cf - https://git.kernel.org/stable/c/fe7f7ac8e0c708446ff017453add769ffc15deed
CVE ID: CVE-2025-38104 State: PUBLISHED Published: 2025-04-18T07:01:31.091Z Last Updated: 2025-07-17T16:55:36.648Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Replace Mutex with Spinlock for RLCG register access to avoid Priority Inversion in SRIOV RLCG Register Access is a way for virtual functions to safely access GPU registers in a virtualized environment., including TLB flushes and register reads. When multiple threads or VFs try to access the same registers simultaneously, it can lead to race conditions. By using the RLCG interface, the driver can serialize access to the registers. This means that only one t
ce conditions. By using the RLCG interface, the driver can serialize access to the registers. This means that only one thread can access the registers at a time, preventing conflicts and ensuring that operations are performed correctly. Additionally, when a low-priority task holds a mutex that a high-priority task needs, ie., If a thread holding a spinlock tries to acquire a mutex, it can lead to priority inversion. register access in amdgpu_virt_rlcg_reg_rw especially in a fast code path is critical. The call stack shows that the function amdgpu_virt_rlcg_reg_rw is being called, which attempts to acquire the mutex. This function is invoked from amdgpu_sriov_wreg, which in turn is called fro
alled, which attempts to acquire the mutex. This function is invoked from amdgpu_sriov_wreg, which in turn is called from gmc_v11_0_flush_gpu_tlb. The [ BUG: Invalid wait context ] indicates that a thread is trying to acquire a mutex while it is in a context that does not allow it to sleep (like holding a spinlock). Fixes the below: [ 253.013423] ============================= [ 253.013434] [ BUG: Invalid wait context ] [ 253.013446] 6.12.0-amdstaging-drm-next-lol-050225 #14 Tainted: G U OE [ 253.013464] ----------------------------- [ 253.013475] kworker/0:1/10 is trying to lock: [ 253.013487] ffff9f30542e3cf8 (&adev->virt.rlcg_reg_lock){+.+.}-{3:3}, at: amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [a
lock: [ 253.013487] ffff9f30542e3cf8 (&adev->virt.rlcg_reg_lock){+.+.}-{3:3}, at: amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.013815] other info that might help us debug this: [ 253.013827] context-{4:4} [ 253.013835] 3 locks held by kworker/0:1/10: [ 253.013847] #0: ffff9f3040050f58 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x3f5/0x680 [ 253.013877] #1: ffffb789c008be40 ((work_completion)(&wfc.work)){+.+.}-{0:0}, at: process_one_work+0x1d6/0x680 [ 253.013905] #2: ffff9f3054281838 (&adev->gmc.invalidate_lock){+.+.}-{2:2}, at: gmc_v11_0_flush_gpu_tlb+0x198/0x4f0 [amdgpu] [ 253.014154] stack backtrace: [ 253.014164] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Tainted: G U OE
x198/0x4f0 [amdgpu] [ 253.014154] stack backtrace: [ 253.014164] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Tainted: G U OE 6.12.0-amdstaging-drm-next-lol-050225 #14 [ 253.014189] Tainted: [U]=USER, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [ 253.014203] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/18/2024 [ 253.014224] Workqueue: events work_for_cpu_fn [ 253.014241] Call Trace: [ 253.014250] <TASK> [ 253.014260] dump_stack_lvl+0x9b/0xf0 [ 253.014275] dump_stack+0x10/0x20 [ 253.014287] __lock_acquire+0xa47/0x2810 [ 253.014303] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.014321] lock_acquire+0xd1/0x300 [ 253.014333] ? amdgpu_virt_rlcg_reg_rw+0
3] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.014321] lock_acquire+0xd1/0x300 [ 253.014333] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.014562] ? __lock_acquire+0xa6b/0x2810 [ 253.014578] __mutex_lock+0x85/0xe20 [ 253.014591] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.014782] ? sched_clock_noinstr+0x9/0x10 [ 253.014795] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.014808] ? local_clock_noinstr+0xe/0xc0 [ 253.014822] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.015012] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.015029] mutex_lock_nested+0x1b/0x30 [ 253.015044] ? mutex_lock_nested+0x1b/0x30 [ 253.015057] amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.015249] amdgpu_
53.015044] ? mutex_lock_nested+0x1b/0x30 [ 253.015057] amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu] [ 253.015249] amdgpu_sriov_wreg+0xc5/0xd0 [amdgpu] [ 253.015435] gmc_v11_0_flush_gpu_tlb+0x44b/0x4f0 [amdgpu] [ 253.015667] gfx_v11_0_hw_init+0x499/0x29c0 [amdgpu] [ 253.015901] ? __pfx_smu_v13_0_update_pcie_parameters+0x10/0x10 [amdgpu] [ 253.016159] ? srso_alias_return_thunk+0x5/0xfbef5 [ 253.016173] ? smu_hw_init+0x18d/0x300 [amdgpu] [ 253.016403] amdgpu_device_init+0x29ad/0x36a0 [amdgpu] [ 253.016614] amdgpu_driver_load_kms+0x1a/0xc0 [amdgpu] [ 253.0170 ---truncated--- References: - https://git.kernel.org/stable/c/07ed75bfa7ede8bfcfa303fd6efc85db1c8684c7 - https://git.kernel.org/stable/c/1c
erences: - https://git.kernel.org/stable/c/07ed75bfa7ede8bfcfa303fd6efc85db1c8684c7 - https://git.kernel.org/stable/c/1c0378830e42c98acd69e0289882c8637d92f285 - https://git.kernel.org/stable/c/5c1741a0c176ae11675a64cb7f2dd21d72db6b91 - https://git.kernel.org/stable/c/dc0297f3198bd60108ccbd167ee5d9fa4af31ed0
CVE ID: CVE-2025-38105 State: PUBLISHED Published: 2025-07-03T08:35:15.301Z Last Updated: 2025-10-12T11:12:51.099Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Kill timer properly at removal The USB-audio MIDI code initializes the timer, but in a rare case, the driver might be freed without the disconnect call. This leaves the timer in an active state while the assigned object is released via snd_usbmidi_free(), which ends up with a kernel warning when the debug configuration is enabled, as spotted by fuzzer. For avoiding the problem, put timer_shutdown_sync() at snd_usbmidi_free(), so that the timer can be k
spotted by fuzzer. For avoiding the problem, put timer_shutdown_sync() at snd_usbmidi_free(), so that the timer can be killed properly. While we're at it, replace the existing timer_delete_sync() at the disconnect callback with timer_shutdown_sync(), too. References: - https://git.kernel.org/stable/c/647410a7da46067953a53c0d03f8680eff570959 - https://git.kernel.org/stable/c/c611b9e55174e439dcd85a72969b43a95f3827a4 - https://git.kernel.org/stable/c/62066758d2ae169278e5d6aea5995b1b6f6ddeb5 - https://git.kernel.org/stable/c/0718a78f6a9f04b88d0dc9616cc216b31c5f3cf1
CVE ID: CVE-2025-38106 State: PUBLISHED Published: 2025-07-03T08:35:16.215Z Last Updated: 2025-07-28T04:12:21.273Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: io_uring: fix use-after-free of sq->thread in __io_uring_show_fdinfo() syzbot reports: BUG: KASAN: slab-use-after-free in getrusage+0x1109/0x1a60 Read of size 8 at addr ffff88810de2d2c8 by task a.out/304 CPU: 0 UID: 0 PID: 304 Comm: a.out Not tainted 6.16.0-rc1 #1 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_report+0xd0/0x670 ? __pfx__raw_spin_lock_
3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_report+0xd0/0x670 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? getrusage+0x1109/0x1a60 kasan_report+0xce/0x100 ? getrusage+0x1109/0x1a60 getrusage+0x1109/0x1a60 ? __pfx_getrusage+0x10/0x10 __io_uring_show_fdinfo+0x9fe/0x1790 ? ksys_read+0xf7/0x1c0 ? do_syscall_64+0xa4/0x260 ? vsnprintf+0x591/0x1100 ? __pfx___io_uring_show_fdinfo+0x10/0x10 ? __pfx_vsnprintf+0x10/0x10 ? mutex_trylock+0xcf/0x130 ? __pfx_mutex_trylock+0x10/0x10 ? __pfx_show_fd_locks+0x10/0x10 ? io_uring_show_fdinfo+0x57/0x80 io_uring_show_fdinfo+0x57/0x80 seq_show+0x38c/0x690 seq_read_iter+0x3f7/0x1180 ? inode_set_ctime_current+0x160/0x4b0 seq_read+0x27
how_fdinfo+0x57/0x80 seq_show+0x38c/0x690 seq_read_iter+0x3f7/0x1180 ? inode_set_ctime_current+0x160/0x4b0 seq_read+0x271/0x3e0 ? __pfx_seq_read+0x10/0x10 ? __pfx__raw_spin_lock+0x10/0x10 ? __mark_inode_dirty+0x402/0x810 ? selinux_file_permission+0x368/0x500 ? file_update_time+0x10f/0x160 vfs_read+0x177/0xa40 ? __pfx___handle_mm_fault+0x10/0x10 ? __pfx_vfs_read+0x10/0x10 ? mutex_lock+0x81/0xe0 ? __pfx_mutex_lock+0x10/0x10 ? fdget_pos+0x24d/0x4b0 ksys_read+0xf7/0x1c0 ? __pfx_ksys_read+0x10/0x10 ? do_user_addr_fault+0x43b/0x9c0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f0f74170fc9 Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48
hwframe+0x77/0x7f RIP: 0033:0x7f0f74170fc9 Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 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 8b 8 RSP: 002b:00007fffece049e8 EFLAGS: 00000206 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0f74170fc9 RDX: 0000000000001000 RSI: 00007fffece049f0 RDI: 0000000000000004 RBP: 00007fffece05ad0 R08: 0000000000000000 R09: 00007fffece04d90 R10: 0000000000000000 R11: 0000000000000206 R12: 00005651720a1100 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Allocated by task 298: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __
0000000000 R15: 0000000000000000 </TASK> Allocated by task 298: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_node_noprof+0xe8/0x330 copy_process+0x376/0x5e00 create_io_thread+0xab/0xf0 io_sq_offload_create+0x9ed/0xf20 io_uring_setup+0x12b0/0x1cc0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 22: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0xc4/0x360 rcu_core+0x5ff/0x19f0 handle_softirqs+0x18c/0x530 run_ksoftirqd+0x20/0x30 smpboot_thread_fn+0x287/0x6c0 kthread+0x30d/0x630 ret_from_fork+0xef/0x1a0 ret_from_fork_asm+0x1a/0x
ksoftirqd+0x20/0x30 smpboot_thread_fn+0x287/0x6c0 kthread+0x30d/0x630 ret_from_fork+0xef/0x1a0 ret_from_fork_asm+0x1a/0x30 Last potentially related work creation: kasan_save_stack+0x33/0x60 kasan_record_aux_stack+0x8c/0xa0 __call_rcu_common.constprop.0+0x68/0x940 __schedule+0xff2/0x2930 __cond_resched+0x4c/0x80 mutex_lock+0x5c/0xe0 io_uring_del_tctx_node+0xe1/0x2b0 io_uring_clean_tctx+0xb7/0x160 io_uring_cancel_generic+0x34e/0x760 do_exit+0x240/0x2350 do_group_exit+0xab/0x220 __x64_sys_exit_group+0x39/0x40 x64_sys_call+0x1243/0x1840 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ffff88810de2cb00 which belongs to the cache task_str
_after_hwframe+0x77/0x7f The buggy address belongs to the object at ffff88810de2cb00 which belongs to the cache task_struct of size 3712 The buggy address is located 1992 bytes inside of freed 3712-byte region [ffff88810de2cb00, ffff88810de2d980) which is caused by the task_struct pointed to by sq->thread being released while it is being used in the function __io_uring_show_fdinfo(). Holding ctx->uring_lock does not prevent ehre relase or exit of sq->thread. Fix this by assigning and looking up ->thread under RCU, and grabbing a reference to the task_struct. This e ---truncated--- References: - https://git.kernel.org/stable/c/af8c13f9ee040b9a287ba246cf0055f7c77b7cc8 - https://git.kernel.org/
ated--- References: - https://git.kernel.org/stable/c/af8c13f9ee040b9a287ba246cf0055f7c77b7cc8 - https://git.kernel.org/stable/c/d0932758a0a77b38ba1b39564f3b7aba12407061 - https://git.kernel.org/stable/c/ac0b8b327a5677dc6fecdf353d808161525b1ff0
CVE ID: CVE-2025-38107 State: PUBLISHED Published: 2025-07-03T08:35:17.487Z Last Updated: 2025-11-03T17:34:09.673Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net_sched: ets: fix a race in ets_qdisc_change() Gerrard Tai reported a race condition in ETS, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, bec
to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/eb7b74e9754e1ba2088f914ad1f57a778b11894b - https://git.kernel.org/stable/c/0b479d0aa488cb478eb2e1d8868be946ac8afb4f - https://git.kernel.org/stable/c/347867cb424edae5fec1622712c8dd0a2c42918f - https://git.kernel.org/stable/c/0383b25488a545be168744336847549d4a2d3d6c - https://git.kernel.org/stable/c/073f64c03516bcfaf790f8edc772e0cfb8a84ec3 - https://git.kernel.org/stable/c/fed94bd51d62d2e0e006aa61480e94e5cd
g/stable/c/073f64c03516bcfaf790f8edc772e0cfb8a84ec3 - https://git.kernel.org/stable/c/fed94bd51d62d2e0e006aa61480e94e5cd0582b0 - https://git.kernel.org/stable/c/d92adacdd8c2960be856e0b82acc5b7c5395fddb
CVE ID: CVE-2025-38108 State: PUBLISHED Published: 2025-07-03T08:35:18.523Z Last Updated: 2025-11-03T17:34:11.552Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net_sched: red: fix a race in __red_change() Gerrard Tai reported a race condition in RED, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because
nderflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/2790c4ec481be45a80948d059cd7c9a06bc37493 - https://git.kernel.org/stable/c/a1bf6a4e9264a685b0e642994031f9c5aad72414 - https://git.kernel.org/stable/c/110a47efcf23438ff8d31dbd9c854fae2a48bf98 - https://git.kernel.org/stable/c/f569984417a4e12c67366e69bdcb752970de921d - https://git.kernel.org/stable/c/2a71924ca4af59ffc00f0444732b6cd54b153d0e - https://git.kernel.org/stable/c/4b755305b2b0618e857fdadb499365b5f2e478
able/c/2a71924ca4af59ffc00f0444732b6cd54b153d0e - https://git.kernel.org/stable/c/4b755305b2b0618e857fdadb499365b5f2e478d1 - https://git.kernel.org/stable/c/444ad445df5496a785705019268a8a84b84484bb - https://git.kernel.org/stable/c/85a3e0ede38450ea3053b8c45d28cf55208409b8
CVE ID: CVE-2025-38109 State: PUBLISHED Published: 2025-07-03T08:35:19.240Z Last Updated: 2025-07-28T04:12:25.395Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix ECVF vports unload on shutdown flow Fix shutdown flow UAF when a virtual function is created on the embedded chip (ECVF) of a BlueField device. In such case the vport acl ingress table is not properly destroyed. ECVF functionality is independent of ecpf_vport_exists capability and thus functions mlx5_eswitch_(enable|disable)_pf_vf_vports() should not test it when enabling/disabling ECVF vports. kernel log: [] refcount_t: underflow; use-after-free. [] WARN
() should not test it when enabling/disabling ECVF vports. kernel log: [] refcount_t: underflow; use-after-free. [] WARNING: CPU: 3 PID: 1 at lib/refcount.c:28 refcount_warn_saturate+0x124/0x220 ---------------- [] Call trace: [] refcount_warn_saturate+0x124/0x220 [] tree_put_node+0x164/0x1e0 [mlx5_core] [] mlx5_destroy_flow_table+0x98/0x2c0 [mlx5_core] [] esw_acl_ingress_table_destroy+0x28/0x40 [mlx5_core] [] esw_acl_ingress_lgcy_cleanup+0x80/0xf4 [mlx5_core] [] esw_legacy_vport_acl_cleanup+0x44/0x60 [mlx5_core] [] esw_vport_cleanup+0x64/0x90 [mlx5_core] [] mlx5_esw_vport_disable+0xc0/0x1d0 [mlx5_core] [] mlx5_eswitch_unload_ec_vf_vports+0xcc/0x150 [mlx5_core] [] mlx5_eswitch_disable_sriov+