CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2025-38363 – drm/tegra: Fix a possible null pointer dereference
https://notcve.org/view.php?id=CVE-2025-38363
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix a possible null pointer dereference In tegra_crtc_reset(), new memory is allocated with kzalloc(), but no check is performed. Before calling __drm_atomic_helper_crtc_reset, state should be checked to prevent possible null pointer dereference. • https://git.kernel.org/stable/c/b7e0b04ae450a0f2f73c376c3057fb05d798e33c •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2025-38362 – drm/amd/display: Add null pointer check for get_first_active_display()
https://notcve.org/view.php?id=CVE-2025-38362
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null pointer check for get_first_active_display() The function mod_hdcp_hdcp1_enable_encryption() calls the function get_first_active_display(), but does not check its return value. The return value is a null pointer if the display list is empty. This will lead to a null pointer dereference in mod_hdcp_hdcp2_enable_encryption(). Add a null pointer check for get_first_active_display() and return MOD_HDCP_STATUS_DISPLAY_N... • https://git.kernel.org/stable/c/2deade5ede56581722c0d7672f28b09548dc0fc4 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2025-38361 – drm/amd/display: Check dce_hwseq before dereferencing it
https://notcve.org/view.php?id=CVE-2025-38361
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check dce_hwseq before dereferencing it [WHAT] hws was checked for null earlier in dce110_blank_stream, indicating hws can be null, and should be checked whenever it is used. (cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad) • https://git.kernel.org/stable/c/e881b82f5d3d8d54d168cd276169f0fee01bf0e7 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2025-38360 – drm/amd/display: Add more checks for DSC / HUBP ONO guarantees
https://notcve.org/view.php?id=CVE-2025-38360
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add more checks for DSC / HUBP ONO guarantees [WHY] For non-zero DSC instances it's possible that the HUBP domain required to drive it for sequential ONO ASICs isn't met, potentially causing the logic to the tile to enter an undefined state leading to a system hang. [HOW] Add more checks to ensure that the HUBP domain matching the DSC instance is appropriately powered. (cherry picked from commit da63df07112e5a9857a8d2aaa042... • https://git.kernel.org/stable/c/646442758910d13f9afc57f38bc0a537c3575390 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2025-38359 – s390/mm: Fix in_atomic() handling in do_secure_storage_access()
https://notcve.org/view.php?id=CVE-2025-38359
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: s390/mm: Fix in_atomic() handling in do_secure_storage_access() Kernel user spaces accesses to not exported pages in atomic context incorrectly try to resolve the page fault. With debug options enabled call traces like this can be seen: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1523 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 419074, name: qemu-system-s39 preempt_count: 1, expected: 0 RCU nest d... • https://git.kernel.org/stable/c/d2e317dfd2d1fe416c77315d17c5d57dbe374915 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2025-38356 – drm/xe/guc: Explicitly exit CT safe mode on unwind
https://notcve.org/view.php?id=CVE-2025-38356
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Explicitly exit CT safe mode on unwind During driver probe we might be briefly using CT safe mode, which is based on a delayed work, but usually we are able to stop this once we have IRQ fully operational. However, if we abort the probe quite early then during unwind we might try to destroy the workqueue while there is still a pending delayed work that attempts to restart itself which triggers a WARN. This was recently observed ... • https://git.kernel.org/stable/c/09b286950f2911615694f4a1ff491efe9ed5eeba •
CVSS: 7.1EPSS: 0%CPEs: 3EXPL: 0CVE-2025-38355 – drm/xe: Process deferred GGTT node removals on device unwind
https://notcve.org/view.php?id=CVE-2025-38355
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/xe: Process deferred GGTT node removals on device unwind While we are indirectly draining our dedicated workqueue ggtt->wq that we use to complete asynchronous removal of some GGTT nodes, this happends as part of the managed-drm unwinding (ggtt_fini_early), which could be later then manage-device unwinding, where we could already unmap our MMIO/GMS mapping (mmio_fini). This was recently observed during unsuccessful VF initialization: [ ... • https://git.kernel.org/stable/c/919bb54e989c1edef87e9797be125c94c450fc65 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2025-38354 – drm/msm/gpu: Fix crash when throttling GPU immediately during boot
https://notcve.org/view.php?id=CVE-2025-38354
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/msm/gpu: Fix crash when throttling GPU immediately during boot There is a small chance that the GPU is already hot during boot. In that case, the call to of_devfreq_cooling_register() will immediately try to apply devfreq cooling, as seen in the following crash: Unable to handle kernel paging request at virtual address 0000000000014110 pc : a6xx_gpu_busy+0x1c/0x58 [msm] lr : msm_devfreq_get_dev_status+0xbc/0x140 [msm] Call trace: a6xx_g... • https://git.kernel.org/stable/c/6694482a70e9536efbf2ac233cbf0c302d6e2dae •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2025-38353 – drm/xe: Fix taking invalid lock on wedge
https://notcve.org/view.php?id=CVE-2025-38353
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix taking invalid lock on wedge If device wedges on e.g. GuC upload, the submission is not yet enabled and the state is not even initialized. Protect the wedge call so it does nothing in this case. It fixes the following splat: [] xe 0000:bf:00.0: [drm] device wedged, needs recovery [] ------------[ cut here ]------------ [] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [] WARNING: CPU: 48 PID: 312 at kernel/locking/mutex.c:564 __mutex_... • https://git.kernel.org/stable/c/a6d81b2d7037ef36163ad16459ed3fd17cb1b596 •
CVSS: 4.7EPSS: 0%CPEs: 8EXPL: 0CVE-2025-38352 – posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del()
https://notcve.org/view.php?id=CVE-2025-38352
22 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del() If an exiting non-autoreaping task has already passed exit_notify() and calls handle_posix_cpu_timers() from IRQ, it can be reaped by its parent or debugger right after unlock_task_sighand(). If a concurrent posix_cpu_timer_del() runs at that moment, it won't be able to detect timer->it.cpu.firing != 0: cpu_timer_task_rcu() and/or lock_task_sighand() will... • https://git.kernel.org/stable/c/0bdd2ed4138ec04e09b4f8165981efc99e439f55 •