CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2025-38319 – drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table
https://notcve.org/view.php?id=CVE-2025-38319
10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table The function atomctrl_initialize_mc_reg_table() and atomctrl_initialize_mc_reg_table_v2_2() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve vram_info, it returns NULL which is later dereferenced. In the Linux kernel, the following vulnerability has been resolved: drm/amd/pp: Fix potential NULL p... • https://git.kernel.org/stable/c/b3892e2bb519fe18225d0628f0dd255761f16502 •
CVSS: 7.1EPSS: 0%CPEs: 8EXPL: 0CVE-2025-38313 – bus: fsl-mc: fix double-free on mc_dev
https://notcve.org/view.php?id=CVE-2025-38313
10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc: fix double-free on mc_dev The blamed commit tried to simplify how the deallocations are done but, in the process, introduced a double-free on the mc_dev variable. In case the MC device is a DPRC, a new mc_bus is allocated and the mc_dev variable is just a reference to one of its fields. In this circumstance, on the error path only the mc_bus should be freed. This commit introduces back the following checkpatch warning which is ... • https://git.kernel.org/stable/c/a042fbed02904493ae6df26ec836045f5a7d3ce2 •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2025-38312 – fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod()
https://notcve.org/view.php?id=CVE-2025-38312
10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod() In fb_find_mode_cvt(), iff mode->refresh somehow happens to be 0x80000000, cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It's then passed to fb_cvt_hperiod(), where it's used as a divider -- division by 0 will result in kernel oops. Add a sanity check for cvt.f_refresh to avoid such overflow... Found by Linux Verification Center (linuxtesting.org) with the S... • https://git.kernel.org/stable/c/96fe6a2109db29cd15b90a093c16e6cb4b19371a •
CVSS: 7.1EPSS: 0%CPEs: 6EXPL: 0CVE-2025-38310 – seg6: Fix validation of nexthop addresses
https://notcve.org/view.php?id=CVE-2025-38310
10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: seg6: Fix validation of nexthop addresses The kernel currently validates that the length of the provided nexthop address does not exceed the specified length. This can lead to the kernel reading uninitialized memory if user space provided a shorter length than the specified one. Fix by validating that the provided length exactly matches the specified one. In the Linux kernel, the following vulnerability has been resolved: seg6: Fix validati... • https://git.kernel.org/stable/c/d1df6fd8a1d22d37cffa0075ab8ad423ce656777 •
CVSS: 5.6EPSS: 0%CPEs: 6EXPL: 0CVE-2025-38305 – ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use()
https://notcve.org/view.php?id=CVE-2025-38305
10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use() There is no disagreement that we should check both ptp->is_virtual_clock and ptp->n_vclocks to check if the ptp virtual clock is in use. However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks in ptp_vclock_in_use(), we observe a recursive lock in the call trace starting from n_vclocks_store(). ============================================ WARNING: possible recursive lo... • https://git.kernel.org/stable/c/73f37068d540eba5f93ba3a0019bf479d35ebd76 •
CVSS: 6.6EPSS: 0%CPEs: 5EXPL: 0CVE-2025-38300 – crypto: sun8i-ce-cipher - fix error handling in sun8i_ce_cipher_prepare()
https://notcve.org/view.php?id=CVE-2025-38300
10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ce-cipher - fix error handling in sun8i_ce_cipher_prepare() Fix two DMA cleanup issues on the error path in sun8i_ce_cipher_prepare(): 1] If dma_map_sg() fails for areq->dst, the device driver would try to free DMA memory it has not allocated in the first place. To fix this, on the "theend_sgs" error path, call dma unmap only if the corresponding dma map was successful. 2] If the dma_map_single() call for the IV fails, the dev... • https://git.kernel.org/stable/c/06f751b613296cc34b86fc83fccaf30d646eb8bc •
CVSS: 7.1EPSS: 0%CPEs: 9EXPL: 0CVE-2025-38298 – EDAC/skx_common: Fix general protection fault
https://notcve.org/view.php?id=CVE-2025-38298
10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: EDAC/skx_common: Fix general protection fault After loading i10nm_edac (which automatically loads skx_edac_common), if unload only i10nm_edac, then reload it and perform error injection testing, a general protection fault may occur: mce: [Hardware Error]: Machine check events logged Oops: general protection fault ... ... Workqueue: events mce_gen_pool_process RIP: 0010:string+0x53/0xe0 ... Call Trace:
CVSS: 7.1EPSS: 0%CPEs: 7EXPL: 0CVE-2025-38293 – wifi: ath11k: fix node corruption in ar->arvifs list
https://notcve.org/view.php?id=CVE-2025-38293
10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix node corruption in ar->arvifs list In current WLAN recovery code flow, ath11k_core_halt() only reinitializes the "arvifs" list head. This will cause the list node immediately following the list head to become an invalid list node. Because the prev of that node still points to the list head "arvifs", but the next of the list head "arvifs" no longer points to that list node. When a WLAN recovery occurs during the execution o... • https://git.kernel.org/stable/c/d5c65159f2895379e11ca13f62feabe93278985d •
CVSS: 8.5EPSS: 0%CPEs: 8EXPL: 0CVE-2025-38286 – pinctrl: at91: Fix possible out-of-boundary access
https://notcve.org/view.php?id=CVE-2025-38286
10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: pinctrl: at91: Fix possible out-of-boundary access at91_gpio_probe() doesn't check that given OF alias is not available or something went wrong when trying to get it. This might have consequences when accessing gpio_chips array with that value as an index. Note, that BUG() can be compiled out and hence won't actually perform the required checks. In the Linux kernel, the following vulnerability has been resolved: pinctrl: at91: Fix possible ... • https://git.kernel.org/stable/c/6732ae5cb47c4f9a72727585956f2a5e069d1637 •
CVSS: 7.1EPSS: 0%CPEs: 10EXPL: 0CVE-2025-38285 – bpf: Fix WARN() in get_bpf_raw_tp_regs
https://notcve.org/view.php?id=CVE-2025-38285
10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: bpf: Fix WARN() in get_bpf_raw_tp_regs syzkaller reported an issue: WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 Modules linked in: CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:get_bpf_raw_... • https://git.kernel.org/stable/c/9594dc3c7e71b9f52bee1d7852eb3d4e3aea9e99 •