CVSS: 7.1EPSS: 0%CPEs: 2EXPL: 0CVE-2025-38447 – mm/rmap: fix potential out-of-bounds page table access during batched unmap
https://notcve.org/view.php?id=CVE-2025-38447
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: mm/rmap: fix potential out-of-bounds page table access during batched unmap As pointed out by David[1], the batched unmap logic in try_to_unmap_one() may read past the end of a PTE table when a large folio's PTE mappings are not fully contained within a single page table. While this scenario might be rare, an issue triggerable from userspace must be fixed regardless of its likelihood. This patch fixes the out-of-bounds access by refactoring... • https://git.kernel.org/stable/c/354dffd29575cdf13154e8fb787322354aa9efc4 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2025-38446 – clk: imx: Fix an out-of-bounds access in dispmix_csr_clk_dev_data
https://notcve.org/view.php?id=CVE-2025-38446
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: clk: imx: Fix an out-of-bounds access in dispmix_csr_clk_dev_data When num_parents is 4, __clk_register() occurs an out-of-bounds when accessing parent_names member. Use ARRAY_SIZE() instead of hardcode number here. BUG: KASAN: global-out-of-bounds in __clk_register+0x1844/0x20d8 Read of size 8 at addr ffff800086988e78 by task kworker/u24:3/59 Hardware name: NXP i.MX95 19X19 board (DT) Workqueue: events_unbound deferred_probe_work_func Call... • https://git.kernel.org/stable/c/5224b189462ff70df328f173b71acfd925092c3c •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2025-38445 – md/raid1: Fix stack memory use after return in raid1_reshape
https://notcve.org/view.php?id=CVE-2025-38445
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: md/raid1: Fix stack memory use after return in raid1_reshape In the raid1_reshape function, newpool is allocated on the stack and assigned to conf->r1bio_pool. This results in conf->r1bio_pool.wait.head pointing to a stack address. Accessing this address later can lead to a kernel panic. Example access path: raid1_reshape() { // newpool is on the stack mempool_t newpool, oldpool; // initialize newpool.wait.head to stack address mempool_init... • https://git.kernel.org/stable/c/afeee514ce7f4cab605beedd03be71ebaf0c5fc8 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2025-38444 – raid10: cleanup memleak at raid10_make_request
https://notcve.org/view.php?id=CVE-2025-38444
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: raid10: cleanup memleak at raid10_make_request If raid10_read_request or raid10_write_request registers a new request and the REQ_NOWAIT flag is set, the code does not free the malloc from the mempool. unreferenced object 0xffff8884802c3200 (size 192): comm "fio", pid 9197, jiffies 4298078271 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 88 41 02 00 00 00 00 00 .........A...... 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............. • https://git.kernel.org/stable/c/39db562b3fedb93978a7e42dd216b306740959f8 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2025-38443 – nbd: fix uaf in nbd_genl_connect() error path
https://notcve.org/view.php?id=CVE-2025-38443
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: nbd: fix uaf in nbd_genl_connect() error path There is a use-after-free issue in nbd: block nbd6: Receive control failed (result -104) block nbd6: shutting down sockets ================================================================== BUG: KASAN: slab-use-after-free in recv_work+0x694/0xa80 drivers/block/nbd.c:1022 Write of size 4 at addr ffff8880295de478 by task kworker/u33:0/67 CPU: 2 UID: 0 PID: 67 Comm: kworker/u33:0 Not tainted 6.15.0... • https://git.kernel.org/stable/c/6497ef8df568afbf5f3e38825a4590ff41611a54 •
CVSS: 7.5EPSS: 0%CPEs: 2EXPL: 0CVE-2025-38442 – block: reject bs > ps block devices when THP is disabled
https://notcve.org/view.php?id=CVE-2025-38442
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: block: reject bs > ps block devices when THP is disabled If THP is disabled and when a block device with logical block size > page size is present, the following null ptr deref panic happens during boot: [ [13.2 mK AOSAN: null-ptr-deref in range [0x0000000000000000-0x0000000000K0 0 0[07] [ 13.017749] RIP: 0010:create_empty_buffers+0x3b/0x380
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2025-38441 – netfilter: flowtable: account for Ethernet header in nf_flow_pppoe_proto()
https://notcve.org/view.php?id=CVE-2025-38441
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: account for Ethernet header in nf_flow_pppoe_proto() syzbot found a potential access to uninit-value in nf_flow_pppoe_proto() Blamed commit forgot the Ethernet header. BUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27 nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27 nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline] nf_hook_slow+0... • https://git.kernel.org/stable/c/d06977b9a4109f8738bb276125eb6a0b772bc433 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2025-38440 – net/mlx5e: Fix race between DIM disable and net_dim()
https://notcve.org/view.php?id=CVE-2025-38440
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix race between DIM disable and net_dim() There's a race between disabling DIM and NAPI callbacks using the dim pointer on the RQ or SQ. If NAPI checks the DIM state bit and sees it still set, it assumes `rq->dim` or `sq->dim` is valid. But if DIM gets disabled right after that check, the pointer might already be set to NULL, leading to a NULL pointer dereference in net_dim(). Fix this by calling `synchronize_net()` before freei... • https://git.kernel.org/stable/c/445a25f6e1a2f6a132b06af6ede4f3c9b5f9af68 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2025-38439 – bnxt_en: Set DMA unmap len correctly for XDP_REDIRECT
https://notcve.org/view.php?id=CVE-2025-38439
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Set DMA unmap len correctly for XDP_REDIRECT When transmitting an XDP_REDIRECT packet, call dma_unmap_len_set() with the proper length instead of 0. This bug triggers this warning on a system with IOMMU enabled: WARNING: CPU: 36 PID: 0 at drivers/iommu/dma-iommu.c:842 __iommu_dma_unmap+0x159/0x170 RIP: 0010:__iommu_dma_unmap+0x159/0x170 Code: a8 00 00 00 00 48 c7 45 b0 00 00 00 00 48 c7 45 c8 00 00 00 00 48 c7 45 a0 ff ff ff ff 4c ... • https://git.kernel.org/stable/c/f18c2b77b2e4eec2313d519ba125bd6a069513cf •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2025-38438 – ASoC: SOF: Intel: hda: Use devm_kstrdup() to avoid memleak.
https://notcve.org/view.php?id=CVE-2025-38438
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: Intel: hda: Use devm_kstrdup() to avoid memleak. sof_pdata->tplg_filename can have address allocated by kstrdup() and can be overwritten. Memory leak was detected with kmemleak: unreferenced object 0xffff88812391ff60 (size 16): comm "kworker/4:1", pid 161, jiffies 4294802931 hex dump (first 16 bytes): 73 6f 66 2d 68 64 61 2d 67 65 6e 65 72 69 63 00 sof-hda-generic. backtrace (crc 4bf1675c): __kmalloc_node_track_caller_noprof+0x49... • https://git.kernel.org/stable/c/68397fda2caa90e99a7c0bcb2cf604e42ef3b91f •