CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-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 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-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 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-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 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2025-38422 – net: lan743x: Modify the EEPROM and OTP size for PCI1xxxx devices
https://notcve.org/view.php?id=CVE-2025-38422
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: net: lan743x: Modify the EEPROM and OTP size for PCI1xxxx devices Maximum OTP and EEPROM size for hearthstone PCI1xxxx devices are 8 Kb and 64 Kb respectively. Adjust max size definitions and return correct EEPROM length based on device. Also prevent out-of-bound read/write. • https://git.kernel.org/stable/c/6b4201d74d0a49af2123abf2c9d142e59566714b •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-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 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-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/5deab0fa6cfd0cd7def17598db15ceb84f950584 •