Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
ntainer's netns, __xfrm_policy_check drops the packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM policy can't be found that matches the (host-side) XFRM state used for decryption. This patch fixes this by scrubbing the packet when using bpf_redirect_peer, as is done on typical netns switches via veth devices except skb->mark and skb->tstamp are not zeroed. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/de1067cc8cf0e8c11ae20cbe5c467aef19d04ded - https://git.kernel.org/stable/c/355b0526336c0bf2bf7feaca033568ede524f763 - https://git.kernel.org/stable/c/b37e54259cab4f78b53953d6f6268b85f07bef3e - https://git.kernel.org/stable/c/9e
e524f763 - https://git.kernel.org/stable/c/b37e54259cab4f78b53953d6f6268b85f07bef3e - https://git.kernel.org/stable/c/9e15ef33ba39fb6d9d1f51445957f16983a9437a - https://git.kernel.org/stable/c/c4327229948879814229b46aa26a750718888503
CVE ID: CVE-2025-37960 State: PUBLISHED Published: 2025-05-20T16:01:53.264Z Last Updated: 2025-05-26T05:24:36.480Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: memblock: Accept allocated memory before use in memblock_double_array() When increasing the array size in memblock_double_array() and the slab is not yet available, a call to memblock_find_in_range() is used to reserve/allocate memory. However, the range returned may not have been accepted, which can result in a crash when booting an SNP guest: RIP: 0010:memcpy_orig+0x68/0x130 Code: ... RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006 RAX: ff11001ff83e5000 RBX: 000000000000
010:memcpy_orig+0x68/0x130 Code: ... RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006 RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000 RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00 RBP: 0000000000002000 R08: 0000000000000000 R09: 0000000000002000 R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78 R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00 memblock_double_array+0xff/0x310 memblock_add_range+0x1fb/0x2f0 memblock_reserve+0x4f/0xa0 memblock_alloc_range_nid+0xac/0x130 memblock_alloc_internal+0x53/0xc0 memblock_alloc_try_nid+0x3d/0xa0 swiotlb_init_remap+0x149/0x2f0 mem_init+0xb/0xb0 mm_core_init+0x8f/0x350 start_kernel+0x17e/0x5
_alloc_try_nid+0x3d/0xa0 swiotlb_init_remap+0x149/0x2f0 mem_init+0xb/0xb0 mm_core_init+0x8f/0x350 start_kernel+0x17e/0x5d0 x86_64_start_reservations+0x14/0x30 x86_64_start_kernel+0x92/0xa0 secondary_startup_64_no_verify+0x194/0x19b Mitigate this by calling accept_memory() on the memory range returned before the slab is available. Prior to v6.12, the accept_memory() interface used a 'start' and 'end' parameter instead of 'start' and 'size', therefore the accept_memory() call must be adjusted to specify 'start + size' for 'end' when applying to kernels prior to v6.12. References: - https://git.kernel.org/stable/c/7bcd29181bab8d508d2adfdbb132de8b1e088698 - https://git.kernel.org/stable/c/d66a22
ces: - https://git.kernel.org/stable/c/7bcd29181bab8d508d2adfdbb132de8b1e088698 - https://git.kernel.org/stable/c/d66a22f6a432a9dd376c9b365d7dc89bd416909c - https://git.kernel.org/stable/c/aa513e69e011a2b19fa22ce62ce35effbd5e0c81 - https://git.kernel.org/stable/c/da8bf5daa5e55a6af2b285ecda460d6454712ff4
CVE ID: CVE-2025-37961 State: PUBLISHED Published: 2025-05-20T16:01:53.940Z Last Updated: 2025-11-03T19:57:45.651Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ipvs: fix uninit-value for saddr in do_output_route4 syzbot reports for uninit-value for the saddr argument [1]. commit 4754957f04f5 ("ipvs: do not use random local source address for tunnels") already implies that the input value of saddr should be ignored but the code is still reading it which can prevent to connect the route. Fix it by changing the argument to ret_saddr. [1] BUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147
argument to ret_saddr. [1] BUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_
p_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ff
compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e Uninit was created at: slab_post_alloc_hook mm/slub.c:4167 [inline] slab_alloc_node mm/slub.c:4210 [inline] __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367 kmalloc_noprof include/linux/slab.h:905 [inline] ip_vs_dest_dst_alloc net/
alloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367 kmalloc_noprof include/linux/slab.h:905 [inline] ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline] __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/
t net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/
mpat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e CPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef) Hardware name: Google Google Compute Engi ---truncated--- Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org
gle Compute Engi ---truncated--- Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/7d0032112a0380d0b8d7c9005f621928a9b9fc76 - https://git.kernel.org/stable/c/adbc8cc1162951cb152ed7f147d5fbd35ce3e62f - https://git.kernel.org/stable/c/0160ac84fb03a0bd8dce8a42cb25bfaeedd110f4 - https://git.kernel.org/stable/c/a3a1b784791a3cbfc6e05c4d8a3c321ac5136e25 - https://git.kernel.org/stable/c/e34090d7214e0516eb8722aee295cb2507317c07
CVE ID: CVE-2025-37962 State: PUBLISHED Published: 2025-05-20T16:01:54.612Z Last Updated: 2025-11-03T19:57:47.028Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix memory leak in parse_lease_state() The previous patch that added bounds check for create lease context introduced a memory leak. When the bounds check fails, the function returns NULL without freeing the previously allocated lease_ctx_info structure. This patch fixes the issue by adding kfree(lreq) before returning NULL in both boundary check cases. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/facf22c1a394c
ck cases. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/facf22c1a394c1e023dab5daf9a494f722771e1c - https://git.kernel.org/stable/c/af9e2d4732a548db8f6f5a90c2c20a789a3d7240 - https://git.kernel.org/stable/c/2148d34371b06dac696c0497a98a6bf905a51650 - https://git.kernel.org/stable/c/829e19ef741d9e9932abdc3bee5466195e0852cf - https://git.kernel.org/stable/c/eb4447bcce915b43b691123118893fca4f372a8f
CVE ID: CVE-2025-37963 State: PUBLISHED Published: 2025-05-20T16:01:55.322Z Last Updated: 2025-11-03T19:57:48.402Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users Support for eBPF programs loaded by unprivileged users is typically disabled. This means only cBPF programs need to be mitigated for BHB. In addition, only mitigate cBPF programs that were loaded by an unprivileged user. Privileged users can also load the same program via eBPF, making the mitigation pointless. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stab
g the mitigation pointless. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/038866e01ea5e5a3d948898ac216e531e7848669 - https://git.kernel.org/stable/c/df53d418709205450a02bb4d71cbfb4ff86f2c1e - https://git.kernel.org/stable/c/6e52d043f7dbf1839a24a3fab2b12b0d3839de7a - https://git.kernel.org/stable/c/80251f62028f1ab2e09be5ca3123f84e8b00389a - https://git.kernel.org/stable/c/e5f5100f1c64ac6c72671b2cf6b46542fce93706 - https://git.kernel.org/stable/c/477481c4348268136227348984b6699d6370b685 - https://git.kernel.org/stable/c/f300769ead032513a68e4a02e806393402e626f8
CVE ID: CVE-2025-37964 State: PUBLISHED Published: 2025-05-20T16:01:56.013Z Last Updated: 2025-11-03T19:57:49.771Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so
story === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: // Turn on IPIs for this CPU/mm combination, but only // if should_flush_tlb() agrees: cpumask_set_cpu(cpu, mm_cpumask(next)); next_tlb_gen = atomic64_read(&next->context.tlb_gen); choose_new_asid(next, next_
pumask_set_cpu(cpu, mm_cpumask(next)); next_tlb_gen = atomic64_read(&next->context.tlb_gen); choose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); load_new_mm_cr3(need_flush); // ^ After 'need_flush' is set to false, IPIs *MUST* // be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); // ^ Not until this point does should_flush_tlb() // become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy "just about to write CR3" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for
, the fuzzy "just about to write CR3" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written. Additional Anal
mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/12f703811af043d32b1c8a30001b2fa04d5cd0ac - https://git.kernel.org/stable/c/02ad4ce144bd27f71f583f667fdf3b3ba0753477 - https://git.kernel.org/stable/c/d41072906abec8bb8e01ed16afefbaa558908c89 - https://git.kernel.org/stable/c/d87392094f96e162fa5fa5a8640d70cc0952806f - https://git.kernel.org/stable/c/399ec9ca8fc4999e676ff89a90184ec40031cf59 - https://git.kernel.org/stable/c/fea4e317f9e7e1f449ce90dedc27a2d2a95bee5a
CVE ID: CVE-2025-37965 State: PUBLISHED Published: 2025-05-20T16:47:14.179Z Last Updated: 2025-05-26T05:24:42.880Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix invalid context error in dml helper [Why] "BUG: sleeping function called from invalid context" error. after: "drm/amd/display: Protect FPU in dml2_validate()/dml21_validate()" The populate_dml_plane_cfg_from_plane_state() uses the GFP_KERNEL flag for memory allocation, which shouldn't be used in atomic contexts. The allocation is needed only for using another helper function get_scaler_data_for_plane(). [How] Modify helpers to pass a pointer to sca
needed only for using another helper function get_scaler_data_for_plane(). [How] Modify helpers to pass a pointer to scaler_data within existing context, eliminating the need for dynamic memory allocation/deallocation and copying. (cherry picked from commit bd3e84bc98f81b44f2c43936bdadc3241d654259) References: - https://git.kernel.org/stable/c/d8c4afe78385cd355e4d80299d785379d6e874df - https://git.kernel.org/stable/c/b371f8f6d89ec8dfea796e00a44a57c44fc8fcc0 - https://git.kernel.org/stable/c/9984db63742099ee3f3cff35cf71306d10e64356
CVE ID: CVE-2025-37966 State: PUBLISHED Published: 2025-05-20T16:47:14.815Z Last Updated: 2025-05-26T05:24:44.150Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: riscv: Fix kernel crash due to PR_SET_TAGGED_ADDR_CTRL When userspace does PR_SET_TAGGED_ADDR_CTRL, but Supm extension is not available, the kernel crashes: Oops - illegal instruction [#1] [snip] epc : set_tagged_addr_ctrl+0x112/0x15a ra : set_tagged_addr_ctrl+0x74/0x15a epc : ffffffff80011ace ra : ffffffff80011a30 sp : ffffffc60039be10 [snip] status: 0000000200000120 badaddr: 0000000010a79073 cause: 0000000000000002 set_tagged_addr_ctrl+0x112/0x15a __riscv_sys_prctl+0
0000000200000120 badaddr: 0000000010a79073 cause: 0000000000000002 set_tagged_addr_ctrl+0x112/0x15a __riscv_sys_prctl+0x352/0x73c do_trap_ecall_u+0x17c/0x20c andle_exception+0x150/0x15c Fix it by checking if Supm is available. References: - https://git.kernel.org/stable/c/4b595a2f5656cd45d534ed2160c94f7662adefe5 - https://git.kernel.org/stable/c/ae08d55807c099357c047dba17624b09414635dd
CVE ID: CVE-2025-37967 State: PUBLISHED Published: 2025-05-20T16:47:15.473Z Last Updated: 2025-11-03T19:57:51.142Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix deadlock This patch introduces the ucsi_con_mutex_lock / ucsi_con_mutex_unlock functions to the UCSI driver. ucsi_con_mutex_lock ensures the connector mutex is only locked if a connection is established and the partner pointer is valid. This resolves a deadlock scenario where ucsi_displayport_remove_partner holds con->mutex waiting for dp_altmode_work to complete while dp_altmode_work attempts to acquire it. Additional Analyst Notes:
->mutex waiting for dp_altmode_work to complete while dp_altmode_work attempts to acquire it. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/f4bd982563c2fd41ec9ca6c517c392d759db801c - https://git.kernel.org/stable/c/f32451ca4cb7dc53f2a0e2e66b84d34162747eb7 - https://git.kernel.org/stable/c/962ce9028ca6eb450d5c205238a3ee27de9d214d - https://git.kernel.org/stable/c/5924b324468845fc795bd76f588f51d7ab4f202d - https://git.kernel.org/stable/c/61fc1a8e1e10cc784cab5829930838aaf1d37af5 - https://git.kernel.org/stable/c/364618c89d4c57c85e5fc51a2446cd939bf57802
CVE ID: CVE-2025-37968 State: PUBLISHED Published: 2025-05-20T16:47:16.051Z Last Updated: 2025-11-03T17:32:49.287Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iio: light: opt3001: fix deadlock due to concurrent flag access The threaded IRQ function in this driver is reading the flag twice: once to lock a mutex and once to unlock it. Even though the code setting the flag is designed to prevent it, there are subtle cases where the flag could be true at the mutex_lock stage and false at the mutex_unlock stage. This results in the mutex not being unlocked, resulting in a deadlock. Fix it by making the opt3001_irq() code generall
This results in the mutex not being unlocked, resulting in a deadlock. Fix it by making the opt3001_irq() code generally more robust, reading the flag into a variable and using the variable value at both stages. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/a9c56ccb7cddfca754291fb24b108a5350a5fbe9 - https://git.kernel.org/stable/c/957e8be112636d9bc692917286e81e54bd87decc - https://git.kernel.org/stable/c/1d7def97e7eb65865ccc01bbdf4eb9e6bbe8a5b5 - https://git.kernel.org/stable/c/748ebd8e61d0bc182c331b8df3887af7285c8a8f - https://git.kernel.org/stable/c/e791bf216c9e236b34dabf514ec0ede140cca719 - https://git.kernel.org/stable/c/7ca84f6a22d50bf
tps://git.kernel.org/stable/c/e791bf216c9e236b34dabf514ec0ede140cca719 - https://git.kernel.org/stable/c/7ca84f6a22d50bf8b31efe9eb05f9859947266d7 - https://git.kernel.org/stable/c/2c95c8f0959d0a72575eabf2ff888f47ed6d8b77 - https://git.kernel.org/stable/c/f063a28002e3350088b4577c5640882bf4ea17ea
CVE ID: CVE-2025-37969 State: PUBLISHED Published: 2025-05-20T16:47:16.641Z Last Updated: 2025-11-03T19:57:52.556Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifo Prevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/4db7d923a8c298788181b796f71adf6ca499f966 - https://git.kernel.org/stable/c/76727a1d81afde77d21ea8feaeb12d34605be6f4 - https://git.kernel.org/stable/c/35b8c0a284983
https://git.kernel.org/stable/c/76727a1d81afde77d21ea8feaeb12d34605be6f4 - https://git.kernel.org/stable/c/35b8c0a284983b71d92d082c54b7eb655ed4194f - https://git.kernel.org/stable/c/16857370b3a30663515956b3bd27f3def6a2cf06 - https://git.kernel.org/stable/c/9ce662851380fe2018e36e15c0bdcb1ad177ed95 - https://git.kernel.org/stable/c/dadf9116108315f2eb14c7415c7805f392c476b4 - https://git.kernel.org/stable/c/9ddb4cf2192c213e4dba1733bbcdc94cf6d85bf7 - https://git.kernel.org/stable/c/8114ef86e2058e2554111b793596f17bee23fa15
CVE ID: CVE-2025-37970 State: PUBLISHED Published: 2025-05-20T16:47:17.256Z Last Updated: 2025-11-03T19:57:53.930Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo Prevent st_lsm6dsx_read_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/f06a1a1954527cc4ed086d926c81ff236b2adde9 - https://git.kernel.org/stable/c/84e39f628a3a3333add99076e4d6c8b42b12d3a0 - https://git.kernel.org/stable/c/f3cf233c946531a92fe651ff2bd
rnel.org/stable/c/84e39f628a3a3333add99076e4d6c8b42b12d3a0 - https://git.kernel.org/stable/c/f3cf233c946531a92fe651ff2bd15ebbe60630a7 - https://git.kernel.org/stable/c/6c4a5000618a8c44200d455c92e2f2a4db264717 - https://git.kernel.org/stable/c/da33c4167b9cc1266a97215114cb74679f881d0c - https://git.kernel.org/stable/c/a1cad8a3bca41dead9980615d35efc7bff1fd534 - https://git.kernel.org/stable/c/3bb6c02d6fe8347ce1785016d135ff539c20043c - https://git.kernel.org/stable/c/159ca7f18129834b6f4c7eae67de48e96c752fc9
CVE ID: CVE-2025-37971 State: PUBLISHED Published: 2025-05-20T16:47:17.879Z Last Updated: 2025-05-26T05:24:50.702Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: staging: bcm2835-camera: Initialise dev in v4l2_dev Commit 42a2f6664e18 ("staging: vc04_services: Move global g_state to vchiq_state") changed mmal_init to pass dev->v4l2_dev.dev to vchiq_mmal_init, however nothing iniitialised dev->v4l2_dev, so we got a NULL pointer dereference. Set dev->v4l2_dev.dev during bcm2835_mmal_probe. The device pointer could be passed into v4l2_device_register to set it, however that also has other effects that would need additional changes.
d be passed into v4l2_device_register to set it, however that also has other effects that would need additional changes. References: - https://git.kernel.org/stable/c/06753f49336ab161ea0e249a0720125b81b7b31b - https://git.kernel.org/stable/c/b70bdd4923e8b8edbacde2af83ca337bb7005261 - https://git.kernel.org/stable/c/98698ca0e58734bc5c1c24e5bbc7429f981cd186
CVE ID: CVE-2025-37972 State: PUBLISHED Published: 2025-05-20T16:47:18.481Z Last Updated: 2025-11-03T19:57:55.332Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Input: mtk-pmic-keys - fix possible null pointer dereference In mtk_pmic_keys_probe, the regs parameter is only set if the button is parsed in the device tree. However, on hardware where the button is left floating, that node will most likely be removed not to enable that input. In that case the code will try to dereference a null pointer. Let's use the regs struct instead as it is defined for all supported platforms. Note that it is ok setting the key reg even if that