
CVE-2025-38449 – drm/gem: Acquire references on GEM handles for framebuffers
https://notcve.org/view.php?id=CVE-2025-38449
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/gem: Acquire references on GEM handles for framebuffers A GEM handle can be released while the GEM buffer object is attached to a DRM framebuffer. This leads to the release of the dma-buf backing the buffer object, if any. [1] Trying to use the framebuffer in further mode-setting operations leads to a segmentation fault. Most easily happens with driver that use shadow planes for vmap-ing the dma-buf during a page flip. An example is sho... • https://git.kernel.org/stable/c/cb4c956a15f8b7f870649454771fc3761f504b5f •

CVE-2025-38448 – usb: gadget: u_serial: Fix race condition in TTY wakeup
https://notcve.org/view.php?id=CVE-2025-38448
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_serial: Fix race condition in TTY wakeup A race condition occurs when gs_start_io() calls either gs_start_rx() or gs_start_tx(), as those functions briefly drop the port_lock for usb_ep_queue(). This allows gs_close() and gserial_disconnect() to clear port.tty and port_usb, respectively. Use the null-safe TTY Port helper function to wake up TTY. Example CPU1: CPU2: gserial_connect() // lock gs_close() // await lock gs_start_r... • https://git.kernel.org/stable/c/35f95fd7f234d2b58803bab6f6ebd6bb988050a2 •

CVE-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 •

CVE-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 •

CVE-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 •

CVE-2025-38437 – ksmbd: fix potential use-after-free in oplock/lease break ack
https://notcve.org/view.php?id=CVE-2025-38437
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix potential use-after-free in oplock/lease break ack If ksmbd_iov_pin_rsp return error, use-after-free can happen by accessing opinfo->state and opinfo_put and ksmbd_fd_put could called twice. • https://git.kernel.org/stable/c/e38ec88a2b42c494601b1213816d75f0b54d9bf0 •

CVE-2025-38436 – drm/scheduler: signal scheduled fence when kill job
https://notcve.org/view.php?id=CVE-2025-38436
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/scheduler: signal scheduled fence when kill job When an entity from application B is killed, drm_sched_entity_kill() removes all jobs belonging to that entity through drm_sched_entity_kill_jobs_work(). If application A's job depends on a scheduled fence from application B's job, and that fence is not properly signaled during the killing process, application A's dependency cannot be cleared. This leads to application A hanging indefinite... • https://git.kernel.org/stable/c/c5734f9bab6f0d40577ad0633af4090a5fda2407 •

CVE-2025-38430 – nfsd: nfsd4_spo_must_allow() must check this is a v4 compound request
https://notcve.org/view.php?id=CVE-2025-38430
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: nfsd: nfsd4_spo_must_allow() must check this is a v4 compound request If the request being processed is not a v4 compound request, then examining the cstate can have undefined results. This patch adds a check that the rpc procedure being executed (rq_procinfo) is the NFSPROC4_COMPOUND procedure. • https://git.kernel.org/stable/c/bf78a2706ce975981eb5167f2d3b609eb5d24c19 •

CVE-2025-38428 – Input: ims-pcu - check record size in ims_pcu_flash_firmware()
https://notcve.org/view.php?id=CVE-2025-38428
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - check record size in ims_pcu_flash_firmware() The "len" variable comes from the firmware and we generally do trust firmware, but it's always better to double check. If the "len" is too large it could result in memory corruption when we do "memcpy(fragment->data, rec->data, len);" • https://git.kernel.org/stable/c/628329d52474323938a03826941e166bc7c8eff4 •

CVE-2025-38426 – drm/amdgpu: Add basic validation for RAS header
https://notcve.org/view.php?id=CVE-2025-38426
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Add basic validation for RAS header If RAS header read from EEPROM is corrupted, it could result in trying to allocate huge memory for reading the records. Add some validation to header fields. • https://git.kernel.org/stable/c/b52f52bc5ba9feb026c0be600f8ac584fd12d187 •