
CVE-2025-38328 – jffs2: check jffs2_prealloc_raw_node_refs() result in few other places
https://notcve.org/view.php?id=CVE-2025-38328
10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: jffs2: check jffs2_prealloc_raw_node_refs() result in few other places Fuzzing hit another invalid pointer dereference due to the lack of checking whether jffs2_prealloc_raw_node_refs() completed successfully. Subsequent logic implies that the node refs have been allocated. Handle that. The code is ready for propagating the error upwards. KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 5835 Comm: syz-execu... • https://git.kernel.org/stable/c/2f785402f39b96a077b6e62bf26164bfb8e0c980 •

CVE-2025-38326 – aoe: clean device rq_list in aoedev_downdev()
https://notcve.org/view.php?id=CVE-2025-38326
10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: aoe: clean device rq_list in aoedev_downdev() An aoe device's rq_list contains accepted block requests that are waiting to be transmitted to the aoe target. This queue was added as part of the conversion to blk_mq. However, the queue was not cleaned out when an aoe device is downed which caused blk_mq_freeze_queue() to sleep indefinitely waiting for those requests to complete, causing a hang. This fix cleans out the queue before calling blk... • https://git.kernel.org/stable/c/3582dd291788e9441c3ba9047e55089edb98da5c •

CVE-2025-38324 – mpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu().
https://notcve.org/view.php?id=CVE-2025-38324
10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: mpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu(). As syzbot reported [0], mpls_route_input_rcu() can be called from mpls_getroute(), where is under RTNL. net->mpls.platform_label is only updated under RTNL. Let's use rcu_dereference_rtnl() in mpls_route_input_rcu() to silence the splat. [0]: WARNING: suspicious RCU usage 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 Not tainted ---------------------------- net/mpls/af_mpls.c:84 susp... • https://git.kernel.org/stable/c/0189197f441602acdca3f97750d392a895b778fd •

CVE-2025-38323 – net: atm: add lec_mutex
https://notcve.org/view.php?id=CVE-2025-38323
10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: net: atm: add lec_mutex syzbot found its way in net/atm/lec.c, and found an error path in lecd_attach() could leave a dangling pointer in dev_lec[]. Add a mutex to protect dev_lecp[] uses from lecd_attach(), lec_vcc_attach() and lec_mcast_attach(). Following patch will use this mutex for /proc/net/atm/lec. BUG: KASAN: slab-use-after-free in lecd_attach net/atm/lec.c:751 [inline] BUG: KASAN: slab-use-after-free in lane_ioctl+0x2224/0x23e0 ne... • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 •

CVE-2025-38321 – smb: Log an error when close_all_cached_dirs fails
https://notcve.org/view.php?id=CVE-2025-38321
10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: smb: Log an error when close_all_cached_dirs fails Under low-memory conditions, close_all_cached_dirs() can't move the dentries to a separate list to dput() them once the locks are dropped. This will result in a "Dentry still in use" error, so add an error message that makes it clear this is what happened: [ 495.281119] CIFS: VFS: \\otters.example.com\share Out of memory while dropping dentries [ 495.281595] ------------[ cut here ]--------... • https://git.kernel.org/stable/c/b8ced2b9a23a1a2c1e0ed8d0d02512e51bdf38da •

CVE-2025-38320 – arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth()
https://notcve.org/view.php?id=CVE-2025-38320
10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth() KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth(). Call Trace: [ 97.283505] BUG: KASAN: stack-out-of-bounds in regs_get_kernel_stack_nth+0xa8/0xc8 [ 97.284677] Read of size 8 at addr ffff800089277c10 by task 1.sh/2550 [ 97.285732] [ 97.286067] CPU: 7 PID: 2550 Comm: 1.sh Not tainted 6.6.0+ #11 [ 97.287032] Hardware name: linux,dummy-virt (DT) [ 9... • https://git.kernel.org/stable/c/0a8ea52c3eb157dd65e224fc95b7c9c99fcba9f7 •

CVE-2025-38319 – drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table
https://notcve.org/view.php?id=CVE-2025-38319
10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table The function atomctrl_initialize_mc_reg_table() and atomctrl_initialize_mc_reg_table_v2_2() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve vram_info, it returns NULL which is later dereferenced. In the Linux kernel, the following vulnerability has been resolved: drm/amd/pp: Fix potential NULL p... • https://git.kernel.org/stable/c/b3892e2bb519fe18225d0628f0dd255761f16502 •

CVE-2025-38313 – bus: fsl-mc: fix double-free on mc_dev
https://notcve.org/view.php?id=CVE-2025-38313
10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc: fix double-free on mc_dev The blamed commit tried to simplify how the deallocations are done but, in the process, introduced a double-free on the mc_dev variable. In case the MC device is a DPRC, a new mc_bus is allocated and the mc_dev variable is just a reference to one of its fields. In this circumstance, on the error path only the mc_bus should be freed. This commit introduces back the following checkpatch warning which is ... • https://git.kernel.org/stable/c/a042fbed02904493ae6df26ec836045f5a7d3ce2 •

CVE-2025-38312 – fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod()
https://notcve.org/view.php?id=CVE-2025-38312
10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod() In fb_find_mode_cvt(), iff mode->refresh somehow happens to be 0x80000000, cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It's then passed to fb_cvt_hperiod(), where it's used as a divider -- division by 0 will result in kernel oops. Add a sanity check for cvt.f_refresh to avoid such overflow... Found by Linux Verification Center (linuxtesting.org) with the S... • https://git.kernel.org/stable/c/96fe6a2109db29cd15b90a093c16e6cb4b19371a •

CVE-2025-38310 – seg6: Fix validation of nexthop addresses
https://notcve.org/view.php?id=CVE-2025-38310
10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: seg6: Fix validation of nexthop addresses The kernel currently validates that the length of the provided nexthop address does not exceed the specified length. This can lead to the kernel reading uninitialized memory if user space provided a shorter length than the specified one. Fix by validating that the provided length exactly matches the specified one. In the Linux kernel, the following vulnerability has been resolved: seg6: Fix validati... • https://git.kernel.org/stable/c/d1df6fd8a1d22d37cffa0075ab8ad423ce656777 •