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: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2025-38304 – Bluetooth: Fix NULL pointer deference on eir_get_service_data
https://notcve.org/view.php?id=CVE-2025-38304
10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix NULL pointer deference on eir_get_service_data The len parameter is considered optional so it can be NULL so it cannot be used for skipping to next entry of EIR_SERVICE_DATA. In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix NULL pointer deference on eir_get_service_data The len parameter is considered optional so it can be NULL so it cannot be used for skipping to next entry of EIR_SERVICE_DA... • https://git.kernel.org/stable/c/8f9ae5b3ae80f168a6224529e3787f4fb27f299a •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2025-38303 – Bluetooth: eir: Fix possible crashes on eir_create_adv_data
https://notcve.org/view.php?id=CVE-2025-38303
10 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: eir: Fix possible crashes on eir_create_adv_data eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER without checking if that would fit. In the Linux kernel, the following vulnerability has been resolved: Bluetooth: eir: Fix possible crashes on eir_create_adv_data eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER without checking if that would fit. • https://git.kernel.org/stable/c/01ce70b0a274bd76a5a311fb90d4d446d9bdfea1 •
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 •