CVSS: 9.8EPSS: 0%CPEs: 3EXPL: 0CVE-2025-40339 – drm/amdgpu: fix nullptr err of vm_handle_moved
https://notcve.org/view.php?id=CVE-2025-40339
09 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix nullptr err of vm_handle_moved If a amdgpu_bo_va is fpriv->prt_va, the bo of this one is always NULL. So, such kind of amdgpu_bo_va should be updated separately before amdgpu_vm_handle_moved. In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix nullptr err of vm_handle_moved If a amdgpu_bo_va is fpriv->prt_va, the bo of this one is always NULL. So, such kind of amdgpu_bo_va should be updated se... • https://git.kernel.org/stable/c/d38ceaf99ed015f2a0b9af3499791bd3a3daae21 •
CVSS: 7.8EPSS: 0%CPEs: 2EXPL: 0CVE-2025-40338 – ASoC: Intel: avs: Do not share the name pointer between components
https://notcve.org/view.php?id=CVE-2025-40338
09 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Do not share the name pointer between components By sharing 'name' directly, tearing down components may lead to use-after-free errors. Duplicate the name to avoid that. At the same time, update the order of operations - since commit cee28113db17 ("ASoC: dmaengine_pcm: Allow passing component name via config") the framework does not override component->name if set before invoking the initializer. In the Linux kernel, the f... • https://git.kernel.org/stable/c/128bf29c992988f8b4f3829227339908fde5ec86 •
CVSS: 8.5EPSS: 0%CPEs: 4EXPL: 0CVE-2025-40337 – net: stmmac: Correctly handle Rx checksum offload errors
https://notcve.org/view.php?id=CVE-2025-40337
09 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Correctly handle Rx checksum offload errors The stmmac_rx function would previously set skb->ip_summed to CHECKSUM_UNNECESSARY if hardware checksum offload (CoE) was enabled and the packet was of a known IP ethertype. However, this logic failed to check if the hardware had actually reported a checksum error. The hardware status, indicating a header or payload checksum failure, was being ignored at this stage. This could cause c... • https://git.kernel.org/stable/c/63fbe0e6413279d5ea5842e2423e351ded547683 •
CVSS: 7.8EPSS: 0%CPEs: 2EXPL: 0CVE-2025-40336 – drm/gpusvm: fix hmm_pfn_to_map_order() usage
https://notcve.org/view.php?id=CVE-2025-40336
09 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: fix hmm_pfn_to_map_order() usage Handle the case where the hmm range partially covers a huge page (like 2M), otherwise we can potentially end up doing something nasty like mapping memory which is outside the range, and maybe not even mapped by the mm. Fix is based on the xe userptr code, which in a future patch will directly use gpusvm, so needs alignment here. v2: - Add kernel-doc (Matt B) - s/fls/ilog2/ (Thomas) In the Linux k... • https://git.kernel.org/stable/c/08e9fd78ba1b9e95141181c69cc51795c9888157 •
CVSS: 9.8EPSS: 0%CPEs: 2EXPL: 0CVE-2025-40335 – drm/amdgpu: validate userq input args
https://notcve.org/view.php?id=CVE-2025-40335
09 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate userq input args This will help on validating the userq input args, and rejecting for the invalid userq request at the IOCTLs first place. In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate userq input args This will help on validating the userq input args, and rejecting for the invalid userq request at the IOCTLs first place. • https://git.kernel.org/stable/c/d38ceaf99ed015f2a0b9af3499791bd3a3daae21 •
CVSS: 9.8EPSS: 0%CPEs: 2EXPL: 0CVE-2025-40334 – drm/amdgpu: validate userq buffer virtual address and size
https://notcve.org/view.php?id=CVE-2025-40334
09 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate userq buffer virtual address and size It needs to validate the userq object virtual address to determine whether it is residented in a valid vm mapping. In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate userq buffer virtual address and size It needs to validate the userq object virtual address to determine whether it is residented in a valid vm mapping. • https://git.kernel.org/stable/c/d38ceaf99ed015f2a0b9af3499791bd3a3daae21 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2025-40333 – f2fs: fix infinite loop in __insert_extent_tree()
https://notcve.org/view.php?id=CVE-2025-40333
09 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: f2fs: fix infinite loop in __insert_extent_tree() When we get wrong extent info data, and look up extent_node in rb tree, it will cause infinite loop (CONFIG_F2FS_CHECK_FS=n). Avoiding this by return NULL and print some kernel messages in that case. In the Linux kernel, the following vulnerability has been resolved: f2fs: fix infinite loop in __insert_extent_tree() When we get wrong extent info data, and look up extent_node in rb tree, it w... • https://git.kernel.org/stable/c/98e4da8ca301e062d79ae168c67e56f3c3de3ce4 •
CVSS: 7.1EPSS: 0%CPEs: 3EXPL: 0CVE-2025-40332 – drm/amdkfd: Fix mmap write lock not release
https://notcve.org/view.php?id=CVE-2025-40332
09 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix mmap write lock not release If mmap write lock is taken while draining retry fault, mmap write lock is not released because svm_range_restore_pages calls mmap_read_unlock then returns. This causes deadlock and system hangs later because mmap read or write lock cannot be taken. Downgrade mmap write lock to read lock if draining retry fault fix this bug. In the Linux kernel, the following vulnerability has been resolved: drm/a... • https://git.kernel.org/stable/c/4a488a7ad71401169cecee75dc94bcce642e2c53 •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2025-40331 – sctp: Prevent TOCTOU out-of-bounds write
https://notcve.org/view.php?id=CVE-2025-40331
09 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: sctp: Prevent TOCTOU out-of-bounds write For the following path not holding the sock lock, sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump() make sure not to exceed bounds in case the address list has grown between buffer allocation (time-of-check) and write (time-of-use). In the Linux kernel, the following vulnerability has been resolved: sctp: Prevent TOCTOU out-of-bounds write For the following path not holding the sock lock... • https://git.kernel.org/stable/c/8f840e47f190cbe61a96945c13e9551048d42cef •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2025-40329 – drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb
https://notcve.org/view.php?id=CVE-2025-40329
09 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb The Mesa issue referenced below pointed out a possible deadlock: [ 1231.611031] Possible interrupt unsafe locking scenario: [ 1231.611033] CPU0 CPU1 [ 1231.611034] ---- ---- [ 1231.611035] lock(&xa->xa_lock#17); [ 1231.611038] local_irq_disable(); [ 1231.611039] lock(&fence->lock); [ 1231.611041] lock(&xa->xa_lock#17); [ 1231.611044]