57.538 CVE tracked
782 Exploited now
188 Used by ransomware
Last sync
CVE Tracker
57.538 CVE
Ten vendors followed by CPE identifier, not by keyword: a CVE appears here once NVD says which products it affects — usually a few days after it is published.
| Identifier | Severity, sorted ascending | Product and flaw | EPSS, sort descending | In KEV since, sort descending |
|---|---|---|---|---|
| CVE-2026-64331 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: usbip: vudc: fix NULL deref in vep_dequeue() vep_alloc_request() wasn't initializing vrequest->udc, so cancellations on the FunctionFS AIO path were arriving in vep_dequeue without a valid U | 0.1% | — |
| CVE-2026-64328 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Fix DMA fence leak In ffs_dmabuf_transfer(), a ffs_dma_fence object is kmalloc'd, with the underlying dma_fence later initialized by dma_fence_init(), which sets its kref | 0.2% | — |
| CVE-2026-64327 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Initialize epfile->in early to fix endpoint direction checks When parsing endpoint descriptors, ffs_data_got_descs() generates the eps_addrmap which contains the endpoint | 0.2% | — |
| CVE-2026-64326 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: block: skip sync_blockdev() on surprise removal in bdev_mark_dead() bdev_mark_dead()'s @surprise == true means the device is already gone. The filesystem callback fs_bdev_mark_dead() honours | 0.2% | — |
| CVE-2026-64325 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921/mt7925: fix NULL dereference in CSA beacon This patch is based on a BUG as reported by Bongani Hlope at https://lore.kernel.org/all/[email protected] | 0.1% | — |
| CVE-2026-64321 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: nvme: target: rdma: fix ndev refcount leak on queue connect nvmet_rdma_queue_connect() calls nvmet_rdma_find_get_device() which acquires a reference on the returned ndev via kref_get(). On t | 0.1% | — |
| CVE-2026-64316 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: crypto: caam - use print_hex_dump_devel to guard key hex dumps Use print_hex_dump_devel() for dumping sensitive key material in *_setkey() and gen_split_key() to avoid leaking secrets at run | 0.1% | — |
| CVE-2026-64314 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: crypto: chacha20poly1305 - validate poly1305 template argument chachapoly_create() still accepts the compatibility poly1305 parameter in the template name, but it assumes the second template | 0.2% | — |
| CVE-2026-64310 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Do not initialize SNP for SEV ioctls Sashiko notes: > if SEV initialization fails and KVM is actively running normal VMs, could a > userspace process trigger this code path vi | 0.2% | — |
| CVE-2026-64309 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Do not initialize SNP for ioctl(SNP_COMMIT) Sashiko notes: > if SEV initialization fails and KVM is actively running normal VMs, could a > userspace process trigger this code | 0.2% | — |
| CVE-2026-64308 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Do not initialize SNP for ioctl(SNP_VLEK_LOAD) Sashiko notes: > if SEV initialization fails and KVM is actively running normal VMs, could a > userspace process trigger this co | 0.2% | — |
| CVE-2026-64307 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Do not initialize SNP for ioctl(SNP_CONFIG) Sashiko notes: > if SEV initialization fails and KVM is actively running normal VMs, could a > userspace process trigger this code | 0.2% | — |
| CVE-2026-64306 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: crypto: drbg - Fix returning success on failure in CTR_DRBG drbg_ctr_generate() sometimes returns success when it fails, leaving the output buffer uninitialized. Fix it. | 0.2% | — |
| CVE-2026-64302 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: x86/mm: Fix freeing of PMD-sized vmemmap pages Commit bf9e4e30f353 ("x86/mm: use pagetable_free()"), switched from freeing non-boot page tables through __free_pages() to pagetable_free(). H | 0.2% | — |
| CVE-2026-64301 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: regulator: scmi: fix of_node refcount leak in scmi_regulator_probe() scmi_regulator_probe() calls of_find_node_by_name() which takes a reference on the returned device node. On the error pat | 0.2% | — |
| CVE-2026-64297 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: module: decompress: check return value of module_extend_max_pages() module_extend_max_pages() calls kvrealloc() internally and returns -ENOMEM on allocation failure. The return value is neve | 0.2% | — |
| CVE-2026-64295 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: mm: page_ext: add count limit to page_ext_iter_next to prevent invalid PFN access The page_ext iteration API does not validate if the PFN still belongs to a valid section while advancing the | 0.2% | — |
| CVE-2026-64294 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: mm: do file ownership checks with the proper mount idmap Ever since idmapped mounts were introduced, inode ownership checks (for side-channel protection) in mincore() and madvise(MADV_PAGEOU | 0.2% | — |
| CVE-2026-64292 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: iommufd: Move vevent memory allocation outside spinlock The veventq memory allocation happens inside the spinlock. Given its depth is decided by the user space, this leaves a vulnerability, | 0.2% | — |
| CVE-2026-64291 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: iommufd: Set veventq_depth upper bound iommufd_veventq_alloc() accepts any !0 veventq_depth from userspace, with an upper bound at U32_MAX. This leaves a vulnerability where userspace can a | 0.2% | — |
| CVE-2026-64290 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: iommufd: Break the loop on failure in iommufd_fault_fops_read() On a copy_to_user() failure inside the inner list_for_each_entry, only the inner loop breaks; the outer while re-fetches the j | 0.2% | — |
| CVE-2026-64289 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: iommufd: Set upper bounds on cache invalidation entry_num and entry_len iommufd_hwpt_invalidate() takes a user-controlled entry_num and entry_len, each bounded only by U32_MAX. An entry_len | 0.2% | — |
| CVE-2026-64288 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Avoid dereferencing NULL VNCR pseudo-TLB VNCR TLB invalidation occurs from MMU notifiers or TLBI instructions, and either can race against a vcpu not being onlined yet (no ps | 0.2% | — |
| CVE-2026-64285 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Pin source page for write when adding CPUID data for SNP guest When populating a guest_memfd instance with the initial CPUID data for an SNP guest, acquire a writable pin on the so | 0.1% | — |
| CVE-2026-64278 | MED 5.5 | linux linux_kernel In the Linux kernel, the following vulnerability has been resolved: i2c: imx-lpi2c: mark I2C adapter when hardware is powered down On some i.MX platforms, certain I2C client drivers keep a periodic workqueue which continues to trigger I2C transfers. During | 0.2% | — |