
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-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-38425 – i2c: tegra: check msg length in SMBUS block read
https://notcve.org/view.php?id=CVE-2025-38425
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: i2c: tegra: check msg length in SMBUS block read For SMBUS block read, do not continue to read if the message length passed from the device is '0' or greater than the maximum allowed bytes. • https://git.kernel.org/stable/c/c39d1a9ae4ad66afcecab124d7789722bfe909fa •

CVE-2025-38424 – perf: Fix sample vs do_exit()
https://notcve.org/view.php?id=CVE-2025-38424
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: perf: Fix sample vs do_exit() Baisheng Gao reported an ARM64 crash, which Mark decoded as being a synchronous external abort -- most likely due to trying to access MMIO in bad ways. The crash further shows perf trying to do a user stack sample while in exit_mmap()'s tlb_finish_mmu() -- i.e. while tearing down the address space it is trying to access. It turns out that we stop perf after we tear down the userspace mm; a receipie for disaster... • https://git.kernel.org/stable/c/c5ebcedb566ef17bda7b02686e0d658a7bb42ee7 •

CVE-2025-38420 – wifi: carl9170: do not ping device which has failed to load firmware
https://notcve.org/view.php?id=CVE-2025-38420
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: do not ping device which has failed to load firmware Syzkaller reports [1, 2] crashes caused by an attempts to ping the device which has failed to load firmware. Since such a device doesn't pass 'ieee80211_register_hw()', an internal workqueue managed by 'ieee80211_queue_work()' is not yet created and an attempt to queue work on it causes null-ptr-deref. [1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff [2] ht... • https://git.kernel.org/stable/c/e4a668c59080f862af3ecc28b359533027cbe434 •

CVE-2025-38415 – Squashfs: check return result of sb_min_blocksize
https://notcve.org/view.php?id=CVE-2025-38415
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: Squashfs: check return result of sb_min_blocksize Syzkaller reports an "UBSAN: shift-out-of-bounds in squashfs_bio_read" bug. Syzkaller forks multiple processes which after mounting the Squashfs filesystem, issues an ioctl("/dev/loop0", LOOP_SET_BLOCK_SIZE, 0x8000). Now if this ioctl occurs at the same time another process is in the process of mounting a Squashfs filesystem on /dev/loop0, the failure occurs. When this happens the following ... • https://git.kernel.org/stable/c/0aa666190509ffab81c202c5095a166be23961ac •

CVE-2025-38410 – drm/msm: Fix a fence leak in submit error path
https://notcve.org/view.php?id=CVE-2025-38410
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix a fence leak in submit error path In error paths, we could unref the submit without calling drm_sched_entity_push_job(), so msm_job_free() will never get called. Since drm_sched_job_cleanup() will NULL out the s_fence, we can use that to detect this case. Patchwork: https://patchwork.freedesktop.org/patch/653584/ • https://git.kernel.org/stable/c/0cf6c71d70d8aa39b8fd0e39c9009602a0e0d300 •

CVE-2025-38409 – drm/msm: Fix another leak in the submit error path
https://notcve.org/view.php?id=CVE-2025-38409
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix another leak in the submit error path put_unused_fd() doesn't free the installed file, if we've already done fd_install(). So we need to also free the sync_file. Patchwork: https://patchwork.freedesktop.org/patch/653583/ • https://git.kernel.org/stable/c/0cf6c71d70d8aa39b8fd0e39c9009602a0e0d300 •