CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2025-38414 – wifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850
https://notcve.org/view.php?id=CVE-2025-38414
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850 GCC_GCC_PCIE_HOT_RST is wrongly defined for WCN7850, causing kernel crash on some specific platforms. Since this register is divergent for WCN7850 and QCN9274, move it to register table to allow different definitions. Then correct the register address for WCN7850 to fix this issue. Note IPQ5332 is not affected as it is not PCIe based device. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.... • https://git.kernel.org/stable/c/d889913205cf7ebda905b1e62c5867ed4e39f6c2 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2025-38412 – platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks
https://notcve.org/view.php?id=CVE-2025-38412
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks After retrieving WMI data blocks in sysfs callbacks, check for the validity of them before dereferencing their content. • https://git.kernel.org/stable/c/e8a60aa7404bfef37705da5607c97737073ac38d •
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 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-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/00b3401f692082ddf6342500d1be25560bba46d4 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2025-38408 – genirq/irq_sim: Initialize work context pointers properly
https://notcve.org/view.php?id=CVE-2025-38408
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: genirq/irq_sim: Initialize work context pointers properly Initialize `ops` member's pointers properly by using kzalloc() instead of kmalloc() when allocating the simulation work context. Otherwise the pointers contain random content leading to invalid dereferencing. • https://git.kernel.org/stable/c/19bd7597858dd15802c1d99fcc38e528f469080a •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2025-38407 – riscv: cpu_ops_sbi: Use static array for boot_data
https://notcve.org/view.php?id=CVE-2025-38407
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: riscv: cpu_ops_sbi: Use static array for boot_data Since commit 6b9f29b81b15 ("riscv: Enable pcpu page first chunk allocator"), if NUMA is enabled, the page percpu allocator may be used on very sparse configurations, or when requested on boot with percpu_alloc=page. In that case, percpu data gets put in the vmalloc area. However, sbi_hsm_hart_start() needs the physical address of a sbi_hart_boot_data, and simply assumes that __pa() would wo... • https://git.kernel.org/stable/c/6b9f29b81b155af023da95f560f738f29722b306 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2025-38406 – wifi: ath6kl: remove WARN on bad firmware input
https://notcve.org/view.php?id=CVE-2025-38406
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: remove WARN on bad firmware input If the firmware gives bad input, that's nothing to do with the driver's stack at this point etc., so the WARN_ON() doesn't add any value. Additionally, this is one of the top syzbot reports now. Just print a message, and as an added bonus, print the sizes too. • https://git.kernel.org/stable/c/7a2afdc5af3b82b601f6a2f0d1c90d5f0bc27aeb •
CVSS: 7.1EPSS: 0%CPEs: 4EXPL: 0CVE-2025-38405 – nvmet: fix memory leak of bio integrity
https://notcve.org/view.php?id=CVE-2025-38405
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: nvmet: fix memory leak of bio integrity If nvmet receives commands with metadata there is a continuous memory leak of kmalloc-128 slab or more precisely bio->bi_integrity. Since commit bf4c89fc8797 ("block: don't call bio_uninit from bio_endio") each user of bio_init has to use bio_uninit as well. Otherwise the bio integrity is not getting free. Nvmet uses bio_init for inline bios. Uninit the inline bio to complete deallocation of integrity... • https://git.kernel.org/stable/c/bf4c89fc8797f5c0964a0c3d561fbe7e8483b62f •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2025-38404 – usb: typec: displayport: Fix potential deadlock
https://notcve.org/view.php?id=CVE-2025-38404
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: usb: typec: displayport: Fix potential deadlock The deadlock can occur due to a recursive lock acquisition of `cros_typec_altmode_data::mutex`. The call chain is as follows: 1. cros_typec_altmode_work() acquires the mutex 2. typec_altmode_vdm() -> dp_altmode_vdm() -> 3. typec_altmode_exit() -> cros_typec_altmode_exit() 4. cros_typec_altmode_exit() attempts to acquire the mutex again To prevent this, defer the `typec_altmode_exit()` call by ... • https://git.kernel.org/stable/c/8e8a69b1f8c59f0505f8a1c0fb77191f27b75011 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2025-38403 – vsock/vmci: Clear the vmci transport packet properly when initializing it
https://notcve.org/view.php?id=CVE-2025-38403
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: Clear the vmci transport packet properly when initializing it In vmci_transport_packet_init memset the vmci_transport_packet before populating the fields to avoid any uninitialised data being left in the structure. • https://git.kernel.org/stable/c/d021c344051af91f42c5ba9fdedc176740cbd238 •