CVSS: 7.1EPSS: 0%CPEs: 4EXPL: 0CVE-2025-40344 – ASoC: Intel: avs: Disable periods-elapsed work when closing PCM
https://notcve.org/view.php?id=CVE-2025-40344
09 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Disable periods-elapsed work when closing PCM avs_dai_fe_shutdown() handles the shutdown procedure for HOST HDAudio stream while period-elapsed work services its IRQs. As the former frees the DAI's private context, these two operations shall be synchronized to avoid slab-use-after-free or worse errors. In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Disable periods-elapsed work when cl... • https://git.kernel.org/stable/c/0dbb186c3510cad4e9f443e801bf2e6ab5770c00 •
CVSS: 7.1EPSS: 0%CPEs: 6EXPL: 0CVE-2025-40343 – nvmet-fc: avoid scheduling association deletion twice
https://notcve.org/view.php?id=CVE-2025-40343
09 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: avoid scheduling association deletion twice When forcefully shutting down a port via the configfs interface, nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() and then nvmet_disable_port(). Both functions will eventually schedule all remaining associations for deletion. The current implementation checks whether an association is about to be removed, but only after the work item has already been scheduled. As a resul... • https://git.kernel.org/stable/c/2f4852db87e25d4e226b25cb6f652fef9504360e •
CVSS: 7.8EPSS: 0%CPEs: 7EXPL: 0CVE-2025-40342 – nvme-fc: use lock accessing port_state and rport state
https://notcve.org/view.php?id=CVE-2025-40342
09 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: nvme-fc: use lock accessing port_state and rport state nvme_fc_unregister_remote removes the remote port on a lport object at any point in time when there is no active association. This races with with the reconnect logic, because nvme_fc_create_association is not taking a lock to check the port_state and atomically increase the active count on the rport. In the Linux kernel, the following vulnerability has been resolved: nvme-fc: use lock ... • https://git.kernel.org/stable/c/de3d91af47bc015031e7721b100a29989f6498a5 •
CVSS: 7.1EPSS: 0%CPEs: 5EXPL: 0CVE-2025-40341 – futex: Don't leak robust_list pointer on exec race
https://notcve.org/view.php?id=CVE-2025-40341
09 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: futex: Don't leak robust_list pointer on exec race sys_get_robust_list() and compat_get_robust_list() use ptrace_may_access() to check if the calling task is allowed to access another task's robust_list pointer. This check is racy against a concurrent exec() in the target process. During exec(), a task may transition from a non-privileged binary to a privileged one (e.g., setuid binary) and its credentials/memory mappings may change. If get... • https://git.kernel.org/stable/c/6511984d1aa1360181bcafb1ca75df7f291ef237 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2025-40340 – drm/xe: Fix oops in xe_gem_fault when running core_hotunplug test.
https://notcve.org/view.php?id=CVE-2025-40340
09 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix oops in xe_gem_fault when running core_hotunplug test. I saw an oops in xe_gem_fault when running the xe-fast-feedback testlist against the realtime kernel without debug options enabled. The panic happens after core_hotunplug unbind-rebind finishes. Presumably what happens is that a process mmaps, unlocks because of the FAULT_FLAG_RETRY_NOWAIT logic, has no process memory left, causing ttm_bo_vm_dummy_page() to return VM_FAULT_N... • https://git.kernel.org/stable/c/99428bd6123d5676209dfb1d7a8f176cc830b665 •
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/47281febebe337586569aa4c5694a7511063a42e •
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/bdaa7ad3a5bb606d7dbd5c8627dc7efcb2392eb9 •