Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-38663 State: PUBLISHED Published: 2025-08-22T16:02:55.856Z Last Updated: 2025-11-03T17:40:48.469Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject invalid file types when reading inodes To prevent inodes with invalid file types from tripping through the vfs and causing malfunctions or assertion failures, add a missing sanity check when reading an inode from a block device. If the file type is not valid, treat it as a filesystem error. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/dd298c0b889acd3ecaf48b6e840c9ab91882e342 - https://git.kernel.org/sta
ner: References: - https://git.kernel.org/stable/c/dd298c0b889acd3ecaf48b6e840c9ab91882e342 - https://git.kernel.org/stable/c/2cf0c4130bf340be3935d097a3dcbfefdcf65815 - https://git.kernel.org/stable/c/98872a934ea6a95985fb6a3655a78a5f0c114e82 - https://git.kernel.org/stable/c/1a5c204e175a78556b8ef1f7683249fa5197295a - https://git.kernel.org/stable/c/bf585ee198bba4ff25b0d80a0891df4656cb0d08 - https://git.kernel.org/stable/c/79663a15a1c70ca84f86f2dbba07b423fe7d5d4f - https://git.kernel.org/stable/c/42cd46b3a8b1497b9258dc7ac445dbd6beb73e2f - https://git.kernel.org/stable/c/4aead50caf67e01020c8be1945c3201e8a972a27
CVE ID: CVE-2025-38664 State: PUBLISHED Published: 2025-08-22T16:02:56.707Z Last Updated: 2025-11-03T17:40:50.335Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ice: Fix a null pointer dereference in ice_copy_and_init_pkg() Add check for the return value of devm_kmemdup() to prevent potential null pointer dereference. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/35370d3b44efe194fd5ad55bac987e629597d782 - https://git.kernel.org/stable/c/435462f8ab2b9c5340a5414ce02f70117d0cfede - https://git.kernel.org/stable/c/7c5a13c76dd37e9e4f8d48b87376a54f4399ce15 - https://git.kernel.org/s
4ce02f70117d0cfede - https://git.kernel.org/stable/c/7c5a13c76dd37e9e4f8d48b87376a54f4399ce15 - https://git.kernel.org/stable/c/1c30093d58cd3d02d8358e2b1f4a06a0aae0bf5b - https://git.kernel.org/stable/c/3028f2a4e746b499043bbb8ab816f975473a0535 - https://git.kernel.org/stable/c/0fde7dccbf4c8a6d7940ecaf4c3d80a12f405dd7 - https://git.kernel.org/stable/c/6d640a8ea62435a7f6f89869bee4fa99423d07ca - https://git.kernel.org/stable/c/4ff12d82dac119b4b99b5a78b5af3bf2474c0a36
CVE ID: CVE-2025-38665 State: PUBLISHED Published: 2025-08-22T16:02:57.458Z Last Updated: 2025-11-03T17:40:51.309Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_mode Andrei Lalaev reported a NULL pointer deref when a CAN device is restarted from Bus Off and the driver does not implement the struct can_priv::do_set_mode callback. There are 2 code path that call struct can_priv::do_set_mode: - directly by a manual restart from the user space, via can_changelink() - delayed automatic restart after bus off (deactivated by default) To prevent the NULL
user space, via can_changelink() - delayed automatic restart after bus off (deactivated by default) To prevent the NULL pointer deference, refuse a manual restart or configure the automatic restart delay in can_changelink() and report the error via extack to user space. As an additional safety measure let can_restart() return an error if can_priv::do_set_mode is not set instead of dereferencing it unchecked. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/6bbcf37c5114926c99a1d1e6993a5b35689d2599 - https://git.kernel.org/stable/c/cf81a60a973358dea163f6b14062f17831ceb894 - https://git.kernel.org/stable/c/0ca816a96fdcf32644c80cbe7a82c7b6ce6ddda5
le/c/cf81a60a973358dea163f6b14062f17831ceb894 - https://git.kernel.org/stable/c/0ca816a96fdcf32644c80cbe7a82c7b6ce6ddda5 - https://git.kernel.org/stable/c/6acceb46180f9e160d4f0c56fcaf39ba562822ae - https://git.kernel.org/stable/c/c1f3f9797c1f44a762e6f5f72520b2e520537b52
CVE ID: CVE-2025-38666 State: PUBLISHED Published: 2025-08-22T16:02:58.144Z Last Updated: 2025-11-03T17:40:53.180Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: appletalk: Fix use-after-free in AARP proxy probe The AARP proxy‐probe routine (aarp_proxy_probe_network) sends a probe, releases the aarp_lock, sleeps, then re-acquires the lock. During that window an expire timer thread (__aarp_expire_timer) can remove and kfree() the same entry, leading to a use-after-free. race condition: cpu 0 | cpu 1 atalk_sendmsg() | atif_proxy_probe_device() aarp_send_ddp() | aarp_proxy_probe_network() mod_timer() | lock(aarp_lock) // LOCK
sendmsg() | atif_proxy_probe_device() aarp_send_ddp() | aarp_proxy_probe_network() mod_timer() | lock(aarp_lock) // LOCK!! timeout around 200ms | alloc(aarp_entry) and then call | proxies[hash] = aarp_entry aarp_expire_timeout() | aarp_send_probe() | unlock(aarp_lock) // UNLOCK!! lock(aarp_lock) // LOCK!! | msleep(100); __aarp_expire_timer(&proxies[ct]) | free(aarp_entry) | unlock(aarp_lock) // UNLOCK!! | | lock(aarp_lock) // LOCK!! | UAF aarp_entry !! ================================================================== BUG: KASAN: slab-use-after-free in aarp_proxy_probe_network+0x560/0x630 net/appletalk/aarp.c:493 Read of size 4 at addr ffff8880123aa360 by task repro/13278 CPU: 3 UID: 0 PID:
ork+0x560/0x630 net/appletalk/aarp.c:493 Read of size 4 at addr ffff8880123aa360 by task repro/13278 CPU: 3 UID: 0 PID: 13278 Comm: repro Not tainted 6.15.2 #3 PREEMPT(full) Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc1/0x630 mm/kasan/report.c:521 kasan_report+0xca/0x100 mm/kasan/report.c:634 aarp_proxy_probe_network+0x560/0x630 net/appletalk/aarp.c:493 atif_proxy_probe_device net/appletalk/ddp.c:332 [inline] atif_ioctl+0xb58/0x16c0 net/appletalk/ddp.c:857 atalk_ioctl+0x198/0x2f0 net/appletalk/ddp.c:1818 sock_do_ioctl+0xdc/0x260 net/socket.c:1190 sock_ioct
ppletalk/ddp.c:857 atalk_ioctl+0x198/0x2f0 net/appletalk/ddp.c:1818 sock_do_ioctl+0xdc/0x260 net/socket.c:1190 sock_ioctl+0x239/0x6a0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x194/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcb/0x250 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> Allocated: aarp_alloc net/appletalk/aarp.c:382 [inline] aarp_proxy_probe_network+0xd8/0x630 net/appletalk/aarp.c:468 atif_proxy_probe_device net/appletalk/ddp.c:332 [inline] atif_ioctl+0xb58/0x16c0 net/appletalk/ddp.c:857 atalk_ioctl+
68 atif_proxy_probe_device net/appletalk/ddp.c:332 [inline] atif_ioctl+0xb58/0x16c0 net/appletalk/ddp.c:857 atalk_ioctl+0x198/0x2f0 net/appletalk/ddp.c:1818 Freed: kfree+0x148/0x4d0 mm/slub.c:4841 __aarp_expire net/appletalk/aarp.c:90 [inline] __aarp_expire_timer net/appletalk/aarp.c:261 [inline] aarp_expire_timeout+0x480/0x6e0 net/appletalk/aarp.c:317 The buggy address belongs to the object at ffff8880123aa300 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 96 bytes inside of freed 192-byte region [ffff8880123aa300, ffff8880123aa3c0) Memory state around the buggy address: ffff8880123aa200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8880123aa280: 00 0
state around the buggy address: ffff8880123aa200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8880123aa280: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc >ffff8880123aa300: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880123aa380: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ffff8880123aa400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/b35694ffabb2af308a1f725d70f60fd8a47d1f3e - https://git.kernel.org/stable/c/82d19a70ced28b17a38ebf1b6978c6c7db894979 - https://git.kernel.org/stable/c/186942d19c0222617ef61
git.kernel.org/stable/c/82d19a70ced28b17a38ebf1b6978c6c7db894979 - https://git.kernel.org/stable/c/186942d19c0222617ef61f50e1dba91e269a5963 - https://git.kernel.org/stable/c/2a6209e4649d45fd85d4193abc481911858ffc6f - https://git.kernel.org/stable/c/e4f1564c5b699eb89b3040688fd6b4e57922f1f6 - https://git.kernel.org/stable/c/5f02ea0f63dd38c41539ea290fcc1693c73aa8e5 - https://git.kernel.org/stable/c/f90b6bb203f3f38bf2b3d976113d51571df9a482 - https://git.kernel.org/stable/c/6c4a92d07b0850342d3becf2e608f805e972467c
CVE ID: CVE-2025-38667 State: PUBLISHED Published: 2025-08-22T16:02:58.865Z Last Updated: 2025-08-22T16:02:58.865Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iio: fix potential out-of-bound write The buffer is set to 20 characters. If a caller write more characters, count is truncated to the max available space in "simple_write_to_buffer". To protect from OoB access, check that the input size fit into buffer and add a zero terminator after copy to the end of the copied data. References: - https://git.kernel.org/stable/c/81a635b6eccd6fc889f6d07ab9583b705f739ce1 - https://git.kernel.org/stable/c/16285a0931869baa618b1f5d304e1e
l.org/stable/c/81a635b6eccd6fc889f6d07ab9583b705f739ce1 - https://git.kernel.org/stable/c/16285a0931869baa618b1f5d304e1e9d090470a8
CVE ID: CVE-2025-38668 State: PUBLISHED Published: 2025-08-22T16:02:59.680Z Last Updated: 2025-11-03T17:40:55.085Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix NULL dereference on unbind due to stale coupling data Failing to reset coupling_desc.n_coupled after freeing coupled_rdevs can lead to NULL pointer dereference when regulators are accessed post-unbind. This can happen during runtime PM or other regulator operations that rely on coupling metadata. For example, on ridesx4, unbinding the 'reg-dummy' platform device triggers a panic in regulator_lock_recursive() due to stale coupling state. Ensure n_co
the 'reg-dummy' platform device triggers a panic in regulator_lock_recursive() due to stale coupling state. Ensure n_coupled is set to 0 to prevent access to invalid pointers. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/7574892e259bbb16262ebfb4b65a2054a5e03a49 - https://git.kernel.org/stable/c/6c49eac796681e250e34156bafb643930310bd4a - https://git.kernel.org/stable/c/ca9bef9ba1a6be640c87bf802d2e9e696021576a - https://git.kernel.org/stable/c/800a2cfb2df7f96b3fb48910fc595e0215f6b019 - https://git.kernel.org/stable/c/233d3c54c9620e95193923859ea1d0b0f5d748ca - https://git.kernel.org/stable/c/5d4261dbb3335221fd9c6e69f909ba79ee6663a7 - https://
54c9620e95193923859ea1d0b0f5d748ca - https://git.kernel.org/stable/c/5d4261dbb3335221fd9c6e69f909ba79ee6663a7 - https://git.kernel.org/stable/c/d7e59c5fd7a0f5e16e75a30a89ea2c4ab88612b8 - https://git.kernel.org/stable/c/ca46946a482238b0cdea459fb82fc837fb36260e
CVE ID: CVE-2025-38669 State: PUBLISHED Published: 2025-08-22T16:03:00.399Z Last Updated: 2025-08-22T16:03:00.399Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Revert "drm/gem-shmem: Use dma_buf from GEM object instance" This reverts commit 1a148af06000e545e714fe3210af3d77ff903c11. The dma_buf field in struct drm_gem_object is not stable over the object instance's lifetime. The field becomes NULL when user space releases the final GEM handle on the buffer object. This resulted in a NULL-pointer deref. Workarounds in commit 5307dce878d4 ("drm/gem: Acquire references on GEM handles for framebuffers") and commit f6bfc9afc751 ("d
ounds in commit 5307dce878d4 ("drm/gem: Acquire references on GEM handles for framebuffers") and commit f6bfc9afc751 ("drm/framebuffer: Acquire internal references on GEM handles") only solved the problem partially. They especially don't work for buffer objects without a DRM framebuffer associated. Hence, this revert to going back to using .import_attach->dmabuf. v3: - cc stable References: - https://git.kernel.org/stable/c/291a77604858a8b47cf6640a12b76e97f99e00ed - https://git.kernel.org/stable/c/6d496e9569983a0d7a05be6661126d0702cf94f7
CVE ID: CVE-2025-38670 State: PUBLISHED Published: 2025-08-22T16:03:01.242Z Last Updated: 2025-11-03T17:40:56.025Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack() `cpu_switch_to()` and `call_on_irq_stack()` manipulate SP to change to different stacks along with the Shadow Call Stack if it is enabled. Those two stack changes cannot be done atomically and both functions can be interrupted by SErrors or Debug Exceptions which, though unlikely, is very much broken : if interrupted, we can end up with mismatched stacks and Shadow Call Stack leading to clobbered stacks. In
much broken : if interrupted, we can end up with mismatched stacks and Shadow Call Stack leading to clobbered stacks. In `cpu_switch_to()`, it can happen when SP_EL0 points to the new task, but x18 stills points to the old task's SCS. When the interrupt handler tries to save the task's SCS pointer, it will save the old task SCS pointer (x18) into the new task struct (pointed to by SP_EL0), clobbering it. In `call_on_irq_stack()`, it can happen when switching from the task stack to the IRQ stack and when switching back. In both cases, we can be interrupted when the SCS pointer points to the IRQ SCS, but SP points to the task stack. The nested interrupt handler pushes its return addresses on t
er points to the IRQ SCS, but SP points to the task stack. The nested interrupt handler pushes its return addresses on the IRQ SCS. It then detects that SP points to the task stack, calls `call_on_irq_stack()` and clobbers the task SCS pointer with the IRQ SCS pointer, which it will also use ! This leads to tasks returning to addresses on the wrong SCS, or even on the IRQ SCS, triggering kernel panics via CONFIG_VMAP_STACK or FPAC if enabled. This is possible on a default config, but unlikely. However, when enabling CONFIG_ARM64_PSEUDO_NMI, DAIF is unmasked and instead the GIC is responsible for filtering what interrupts the CPU should receive based on priority. Given the goal of emulating N
GIC is responsible for filtering what interrupts the CPU should receive based on priority. Given the goal of emulating NMIs, pseudo-NMIs can be received by the CPU even in `cpu_switch_to()` and `call_on_irq_stack()`, possibly *very* frequently depending on the system configuration and workload, leading to unpredictable kernel panics. Completely mask DAIF in `cpu_switch_to()` and restore it when returning. Do the same in `call_on_irq_stack()`, but restore and mask around the branch. Mask DAIF even if CONFIG_SHADOW_CALL_STACK is not enabled for consistency of behaviour between all configurations. Introduce and use an assembly macro for saving and masking DAIF, as the existing one saves but onl
n all configurations. Introduce and use an assembly macro for saving and masking DAIF, as the existing one saves but only masks IF. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/407047893a64399f2d2390ff35cc6061107d805d - https://git.kernel.org/stable/c/a6b0cb523eaa01efe8a3f76ced493ba60674c6e6 - https://git.kernel.org/stable/c/9433a5f437b0948d6a2d8a02ad7a42ab7ca27a61 - https://git.kernel.org/stable/c/708fd522b86d2a9544c34ec6a86fa3fc23336525 - https://git.kernel.org/stable/c/0f67015d72627bad72da3c2084352e0aa134416b - https://git.kernel.org/stable/c/d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb
CVE ID: CVE-2025-38671 State: PUBLISHED Published: 2025-08-22T16:03:02.151Z Last Updated: 2025-11-03T17:40:57.909Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: i2c: qup: jump out of the loop in case of timeout Original logic only sets the return value but doesn't jump out of the loop if the bus is kept active by a client. This is not expected. A malicious or buggy i2c client can hang the kernel in this case and should be avoided. This is observed during a long time test with a PCA953x GPIO extender. Fix it by changing the logic to not only sets the return value, but also jumps out of the loop and return to the caller with -ET
y changing the logic to not only sets the return value, but also jumps out of the loop and return to the caller with -ETIMEDOUT. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/cbec4406998185e0311ae97dfacc649f9cd79b0b - https://git.kernel.org/stable/c/acfa2948be630ad857535cb36153697f3cbf9ca9 - https://git.kernel.org/stable/c/d05ec13aa3eb868a60dc961b489053a643863ddc - https://git.kernel.org/stable/c/c523bfba46c4b4d7676fb050909533a766698ecd - https://git.kernel.org/stable/c/0d33913fce67a93c1eb83396c3c9d6b411dcab33 - https://git.kernel.org/stable/c/42c4471b30fa203249f476dd42321cd7efb7f6a8 - https://git.kernel.org/stable/c/89459f168b78e5c801dc8b7a
.kernel.org/stable/c/42c4471b30fa203249f476dd42321cd7efb7f6a8 - https://git.kernel.org/stable/c/89459f168b78e5c801dc8b7ad037b62898bc4f57 - https://git.kernel.org/stable/c/a7982a14b3012527a9583d12525cd0dc9f8d8934
CVE ID: CVE-2025-38672 State: PUBLISHED Published: 2025-08-22T16:03:02.852Z Last Updated: 2025-08-22T16:03:02.852Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Revert "drm/gem-dma: Use dma_buf from GEM object instance" This reverts commit e8afa1557f4f963c9a511bd2c6074a941c308685. The dma_buf field in struct drm_gem_object is not stable over the object instance's lifetime. The field becomes NULL when user space releases the final GEM handle on the buffer object. This resulted in a NULL-pointer deref. Workarounds in commit 5307dce878d4 ("drm/gem: Acquire references on GEM handles for framebuffers") and commit f6bfc9afc751 ("drm
nds in commit 5307dce878d4 ("drm/gem: Acquire references on GEM handles for framebuffers") and commit f6bfc9afc751 ("drm/framebuffer: Acquire internal references on GEM handles") only solved the problem partially. They especially don't work for buffer objects without a DRM framebuffer associated. Hence, this revert to going back to using .import_attach->dmabuf. v3: - cc stable References: - https://git.kernel.org/stable/c/e7bdb3104a2f71ec1439d37f8e6e2f201dbcd7cf - https://git.kernel.org/stable/c/1918e79be908b8a2c8757640289bc196c14d928a
CVE ID: CVE-2025-38673 State: PUBLISHED Published: 2025-08-22T16:03:03.594Z Last Updated: 2025-08-22T16:03:03.594Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Revert "drm/gem-framebuffer: Use dma_buf from GEM object instance" This reverts commit cce16fcd7446dcff7480cd9d2b6417075ed81065. The dma_buf field in struct drm_gem_object is not stable over the object instance's lifetime. The field becomes NULL when user space releases the final GEM handle on the buffer object. This resulted in a NULL-pointer deref. Workarounds in commit 5307dce878d4 ("drm/gem: Acquire references on GEM handles for framebuffers") and commit f6bfc9afc7
Workarounds in commit 5307dce878d4 ("drm/gem: Acquire references on GEM handles for framebuffers") and commit f6bfc9afc751 ("drm/framebuffer: Acquire internal references on GEM handles") only solved the problem partially. They especially don't work for buffer objects without a DRM framebuffer associated. Hence, this revert to going back to using .import_attach->dmabuf. v3: - cc stable References: - https://git.kernel.org/stable/c/e31f5a1c2cd38bf977736cdfa79444e19d4005ec - https://git.kernel.org/stable/c/2712ca878b688682ac2ce02aefc413fc76019cd9
CVE ID: CVE-2025-38674 State: PUBLISHED Published: 2025-08-22T16:03:04.418Z Last Updated: 2025-08-22T16:03:04.418Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Revert "drm/prime: Use dma_buf from GEM object instance" This reverts commit f83a9b8c7fd0557b0c50784bfdc1bbe9140c9bf8. The dma_buf field in struct drm_gem_object is not stable over the object instance's lifetime. The field becomes NULL when user space releases the final GEM handle on the buffer object. This resulted in a NULL-pointer deref. Workarounds in commit 5307dce878d4 ("drm/gem: Acquire references on GEM handles for framebuffers") and commit f6bfc9afc751 ("drm/f
s in commit 5307dce878d4 ("drm/gem: Acquire references on GEM handles for framebuffers") and commit f6bfc9afc751 ("drm/framebuffer: Acquire internal references on GEM handles") only solved the problem partially. They especially don't work for buffer objects without a DRM framebuffer associated. Hence, this revert to going back to using .import_attach->dmabuf. v3: - cc stable References: - https://git.kernel.org/stable/c/5f05d83ce689a8930a70dfa73f879604aef8cc03 - https://git.kernel.org/stable/c/fb4ef4a52b79a22ad382bfe77332642d02aef773
CVE ID: CVE-2025-38675 State: PUBLISHED Published: 2025-08-22T16:04:12.688Z Last Updated: 2025-08-22T16:04:12.688Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: xfrm: state: initialize state_ptrs earlier in xfrm_state_find In case of preemption, xfrm_state_look_at will find a different pcpu_id and look up states for that other CPU. If we matched a state for CPU2 in the state_cache while the lookup started on CPU1, we will jump to "found", but the "best" state that we got will be ignored and we will enter the "acquire" block. This block uses state_ptrs, which isn't initialized at this point. Let's initialize state_ptrs just aft
"acquire" block. This block uses state_ptrs, which isn't initialized at this point. Let's initialize state_ptrs just after taking rcu_read_lock. This will also prevent a possible misuse in the future, if someone adjusts this function. References: - https://git.kernel.org/stable/c/6bf2daafc51bcb9272c0fdff2afd38217337d0d3 - https://git.kernel.org/stable/c/463562f9591742be62ddde3b426a0533ed496955 - https://git.kernel.org/stable/c/94d077c331730510d5611b438640a292097341f0
CVE ID: CVE-2025-38676 State: PUBLISHED Published: 2025-08-26T13:07:48.761Z Last Updated: 2025-11-03T17:40:59.770Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Avoid stack buffer overflow from kernel cmdline While the kernel command line is considered trusted in most environments, avoid writing 1 byte past the end of "acpiid" if the "str" argument is maximum length. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/a732502bf3bbe859613b6d7b2b0313b11f0474ac - https://git.kernel.org/stable/c/0ad8509b468fa1058f4f400a1829f29e4ccc4de8 - https://git.kernel.org/stable/c/9ff52d
74ac - https://git.kernel.org/stable/c/0ad8509b468fa1058f4f400a1829f29e4ccc4de8 - https://git.kernel.org/stable/c/9ff52d3af0ef286535749e14e3fe9eceb39a8349 - https://git.kernel.org/stable/c/8f80c633cba144f721d38d9380f23d23ab7db10e - https://git.kernel.org/stable/c/4bdb0f78bddbfa77d3ab458a21dd9cec495d317a - https://git.kernel.org/stable/c/736db11c86f03e717fc4bf771d05efdf10d23acb - https://git.kernel.org/stable/c/8503d0fcb1086a7cfe26df67ca4bd9bd9e99bdec
CVE ID: CVE-2025-38677 State: PUBLISHED Published: 2025-08-30T09:19:02.596Z Last Updated: 2025-11-03T17:41:02.759Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid out-of-boundary access in dnode page As Jiaming Zhang reported: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x1c1/0x2a0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x17e/0x800 mm/kasan/report.c:480 kasan_report+0x147/0x180 mm/kasan/report.c:593 data_blkaddr fs/f2fs/f2fs.h:3053 [inline] f2fs_data_blkaddr fs/f2fs/f2fs.h:3058 [inline] f2fs_get_dnode_of_data+0x1a09/0x1c40 fs/f2fs/node.c:8