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/5a577de86c4a1c67ca405571d6ef84e65c6897d1 •
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/765f8816d3959ef1f3f7f85e2af748594d091f40 •
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/e2105ba1c262dcaa9573f11844b6e1e1ca762c3f •
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: 2EXPL: 0CVE-2025-40330 – bnxt_en: Shutdown FW DMA in bnxt_shutdown()
https://notcve.org/view.php?id=CVE-2025-40330
09 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Shutdown FW DMA in bnxt_shutdown() The netif_close() call in bnxt_shutdown() only stops packet DMA. There may be FW DMA for trace logging (recently added) that will continue. If we kexec to a new kernel, the DMA will corrupt memory in the new kernel. Add bnxt_hwrm_func_drv_unrgtr() to unregister the driver from the FW. This will stop the FW DMA. In case the call fails, call pcie_flr() to reset the function and stop the DMA. • https://git.kernel.org/stable/c/24d694aec139e9e0a31c60993db79bd8ad575afe •
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]
CVSS: 7.8EPSS: 0%CPEs: 4EXPL: 0CVE-2025-40328 – smb: client: fix potential UAF in smb2_close_cached_fid()
https://notcve.org/view.php?id=CVE-2025-40328
09 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_close_cached_fid() find_or_create_cached_dir() could grab a new reference after kref_put() had seen the refcount drop to zero but before cfid_list_lock is acquired in smb2_close_cached_fid(), leading to use-after-free. Switch to kref_put_lock() so cfid_release() is called with cfid_list_lock held, closing that gap. In the Linux kernel, the following vulnerability has been resolved: smb: client: fix pot... • https://git.kernel.org/stable/c/ebe98f1447bbccf8228335c62d86af02a0ed23f7 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2025-40327 – perf/core: Fix system hang caused by cpu-clock usage
https://notcve.org/view.php?id=CVE-2025-40327
09 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix system hang caused by cpu-clock usage cpu-clock usage by the async-profiler tool can trigger a system hang, which got bisected back to the following commit by Octavia Togami: 18dbcbfabfff ("perf: Fix the POLL_HUP delivery breakage") causes this issue The root cause of the hang is that cpu-clock is a special type of SW event which relies on hrtimers. The __perf_event_overflow() callback is invoked from the hrtimer handler for ... • https://git.kernel.org/stable/c/18dbcbfabfffc4a5d3ea10290c5ad27f22b0d240 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2023-53866 – ASoC: soc-compress: Reposition and add pcm_mutex
https://notcve.org/view.php?id=CVE-2023-53866
09 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: ASoC: soc-compress: Reposition and add pcm_mutex If panic_on_warn is set and compress stream(DPCM) is started, then kernel panic occurred because card->pcm_mutex isn't held appropriately. In the following functions, warning were issued at this line "snd_soc_dpcm_mutex_assert_held". static int dpcm_be_connect(struct snd_soc_pcm_runtime *fe, struct snd_soc_pcm_runtime *be, int stream) { ... snd_soc_dpcm_mutex_assert_held(fe); ... } void dpcm_... • https://git.kernel.org/stable/c/9576b7ccc20365d27c26c494651c89360a85bbdc •
CVSS: 9.3EPSS: 0%CPEs: 7EXPL: 0CVE-2023-53865 – btrfs: fix warning when putting transaction with qgroups enabled after abort
https://notcve.org/view.php?id=CVE-2023-53865
09 Dec 2025 — In the Linux kernel, the following vulnerability has been resolved: btrfs: fix warning when putting transaction with qgroups enabled after abort If we have a transaction abort with qgroups enabled we get a warning triggered when doing the final put on the transaction, like this: [552.6789] ------------[ cut here ]------------ [552.6815] WARNING: CPU: 4 PID: 81745 at fs/btrfs/transaction.c:144 btrfs_put_transaction+0x123/0x130 [btrfs] [552.6817] Modules linked in: btrfs blake2b_generic xor (...) [552.6819] C... • https://git.kernel.org/stable/c/40ea30638d20c92b44107247415842b72c460459 •