CVE Vulnerability Catalog
Translated CVE descriptions from NVD NIST - in English
Browse vulnerabilities by packageCISA KEV catalog updated: (v2026.11.06)
Weekly CVE digest
One email a week with newly published vulnerabilities worth knowing about. No account needed.
This digest covers new vulnerabilities in general, not your servers. If you want to know which of them actually run in your infrastructure, that is what Secvalis does: it scans your machines and reports only what concerns them.
In the Linux kernel, the kfd_dev_mapping function (drm/amdkfd driver) had two bugs: a use-after-free leading to an i_mmap_rwsem deadlock, and a multi-container gap where VMAs from later /dev/kfd openers were never unmapped. Both manifest under SRIOV with multiple containers and can cause a hard hang or leave stale doorbell/MMIO mappings. The fix creates a private pseudo-filesystem and redirects all openers to a single anonymous inode.
In the Linux kernel, the amdgpu_debugfs_test_ib_show() function in the drm/amdgpu driver calls pm_runtime_get_sync() and then attempts to acquire the reset domain semaphore via down_write_killable(). If the lock acquisition is interrupted, the function returns without releasing the runtime PM reference, leaking it and keeping the GPU awake.
In the Linux kernel, the drm/nouveau/dmem module's nouveau_dmem_chunk_alloc() registers a region of DMEM_CHUNK_SIZE * NR_CHUNKS, but the backing VRAM buffer object remains DMEM_CHUNK_SIZE. As a result, pages beyond the first chunk resolve to VRAM outside the buffer, causing invalid memory access.
A use-after-free vulnerability exists in the Linux kernel's drm/nouveau/uvmm module. The nouveau_uvmm_sm() function calls op_map(), which passes bo->resource through nouveau_mem() to nouveau_uvma_map(), and nouveau_uvmm_vmm_map() then reads mem->mem.type. When the BO remains in TTM_PL_SYSTEM, bo->resource points only to a struct ttm_resource, so reading mem->mem.type goes past the end of the resource, triggering a KASAN slab-use-after-free.
In the Linux kernel, the nv1a_ram_new() function in the drm/nouveau driver calls pci_get_domain_bus_and_slot(), which takes a reference to the PCI device, but this reference is never released after reading the memory size from its config space.
A double-free vulnerability exists in the nouveau driver of the Linux kernel within the nvif_vmm_dtor function. When nouveau_cli_init() fails, nouveau_cli_fini() is called twice, and since vmm->page is not cleared after being freed, the second call causes a double-free.
In the Linux kernel, the validate_init() function in the drm/nouveau driver, on ttm_bo_reserve() failure or "vma not found" error paths, breaks the loop without adding the looked-up object to any validate list, so the reference taken by drm_gem_object_lookup() is never released.
In the Linux kernel, the nouveau_connector_detect() function in the drm/nouveau driver, if nvif_outp_edid_get() fails, returns early without dropping the runtime PM reference taken at the start of the function, keeping the device powered on.
In the Linux kernel, struct nouveau_sched embeds a drm_gpu_scheduler, and nouveau_sched_destroy() frees it with kfree() after drm_sched_fini(). Because fences exported to userspace via drm_syncobj/sync_file still point to the freed memory, a later get_timeline_name() call causes a use-after-free (KASAN slab-use-after-free read).
In the Linux kernel's drm/nouveau driver, nouveau_bo_pin_locked() increments the buffer's pin count even when a re-pin request fails with -EBUSY due to incompatible memory domains. The extra pin count is never decremented by a matching unpin, triggering the WARN_ON_ONCE(bo->pin_count) warning in ttm_bo_release(). The issue was found while fuzzing the nouveau driver with a modified Syzkaller.
In the Linux kernel, xe_vm_close_and_put() destroyed vm->pt_root (via xe_vm_pt_destroy()) before processing contested VMAs that were still linked to their buffer objects. If a concurrent thread evicts one of those shared buffers, xe_bo_trigger_rebind() walks the BO's VMAs and calls xe_pt_zap_ptes(), where dereferencing pt->level causes a NULL pointer dereference because vm->pt_root[tile->id] is already NULL.
A memory leak exists in the Linux kernel's drm/virtio driver within virtio_gpu_execbuffer_ioctl(). When an execbuffer call fails (e.g., invalid bo_handle or a syncobj with no fence), the reserved DRM event is neither cancelled nor freed, and the only driver-side pointer to it is lost. Closing the DRM file does not release this memory, so the allocation leaks permanently.
In the Linux kernel, the drm/virtio driver's virtio_gpu_fence_alloc() can return NULL under memory pressure, but its caller virtio_gpu_init_submit() never checks for this. The NULL fence is then passed to virtio_gpu_fence_event_create(), which unconditionally dereferences it, causing a NULL pointer dereference and kernel crash (general protection fault).
The Linux kernel has a missing memory barrier between anon_vma initialization and the publication of vma->anon_vma. As a result, two threads handling adjacent VMAs can concurrently call __anon_vma_prepare(), leading to a use-after-free (UAF) and a deadlock on the anon_vma->root->rwsem lock. This manifests as a hung task on arm64 platforms.
In the Linux kernel, dissolve_free_hugetlb_folio() does not check hstate_is_gigantic_no_runtime(h), even though remove_hugetlb_folio()/update_and_free_hugetlb_folio() silently bail for such folios. As a result, a still-listed folio is freed, and on vmemmap restore failure the add_hugetlb_folio() rollback corrupts the free list.
In the Linux kernel, damon_hugetlb_mkold() reads the page table entry into a local variable, unsets the accessed bit, and writes the updated value back. If hardware updates the same entry in parallel, hardware updates (e.g., dirty bits) may be lost. The fix uses huge_ptep_get_and_clear() to atomically clear the entry on read.
In the Linux kernel, of_pci_prop_bus_range() and of_pci_prop_intr_map() dereference pdev->subordinate without checking whether the PCI bridge has a subordinate bus allocated. When CONFIG_PCI_DYNAMIC_OF_NODES is enabled, this can cause a NULL pointer dereference and early boot hang.
A vulnerability in the Linux kernel AF_PACKET TX_RING transmission path was fixed. A ring slot could be released and reused while still linked into an skb, because skb_orphan invoked the destructor before the skb was freed. The fix switches to standard zerocopy completion (ubuf_info), so the slot is released only after all references to the payload are freed or copied.
In the Linux kernel, the HID alps driver (alps_input_configured()) allocates and registers a second input device 'DualPoint Stick', but the alps_driver struct has no .remove handler and input2 is not tracked in hdev->inputs. The default remove path (hid_hw_stop -> hidinput_disconnect) only iterates hdev->inputs, so input2 is never unregistered and leaks on every device removal.
In the Linux kernel, alps_input_configured() in the HID alps driver stores data->input2 before registering the input device. If registration fails, input_free_device() frees the memory but data->input2 still points to it, and with active URBs this can lead to a use-after-free.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

