Vulnerabilities exploitable today
351,929in current view
Single score combining CVSS, KEV membership and EPSS. Every CVE with its own record — timeline from publication to active exploitation.
In KEV catalog1,653
New KEV · 24H0
Exploit Today ≥ 701,590
Distribution · last window
- Critical1,913
- High6,189
- Medium5,025
- Low479
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2019-9450—2.6%
——1——CVE-2025-0086—2.6%
——1——CVE-2023-45775—2.6%
——1——CVE-2025-49077—2.6%
——1——CVE-2022-42520—2.6%
——1——CVE-2022-42521—2.6%
——1——CVE-2026-45773—2.6%
——1——CVE-2023-24852—2.6%
——1——CVE-2025-47684—2.6%
——1——CVE-2026-640237.8 HIG2.5%
——1In the Linux kernel, the following vulnerability has been resolved:
gpio: aggregator: fix a potential use-after-free
On error we free aggr->lookups->dev_id before removing the entry from
the lookup table. If a concurrent thread calls gpiod_find() before we
remove the entry, it could iterate over the list and call
gpiod_match_lookup_table() which unconditionally dereferences dev_id
when calling strcmp(). Reverse the order of cleanup.3dCVE-2021-39630—2.5%
——1——CVE-2026-533007.8 HIG2.5%
——1In the Linux kernel, the following vulnerability has been resolved:
net: enetc: fix NTMP DMA use-after-free issue
The AI-generated review reported a potential DMA use-after-free issue
[1]. If netc_xmit_ntmp_cmd() times out and returns an error, the pending
command is not explicitly aborted, while ntmp_free_data_mem()
unconditionally frees the DMA buffer. If the buffer has already been
reallocated elsewhere, this may lead to silent memory corruption. Because
the hardware eventually processes the pending command and perform a DMA
write of the response to the physical address of the freed buffer.
To resolve this issue, this patch does the following modifications:
1. Convert cbdr->ring_lock from a spinlock to a mutex
The lock was originally a spinlock in case NTMP operations might be
invoked from atomic context. After downstream support for all NTMP
tables, no such usage has materialized. A mutex lock is now required
because the driver now needs to reclaim used BDs and release associated
DMA memory within the lock's context, while dma_free_coherent() might
sleep.
2. Introduce software command BD (struct netc_swcbd)
The hardware write-back overwrites the addr and len fields of the BD,
so the driver cannot rely on the hardware BD to free the associated DMA
memory. The driver now maintains a software shadow BD storing the DMA
buffer pointer, DMA address, and size. And netc_xmit_ntmp_cmd() only
reclaims older BDs when the number of used BDs reaches
NETC_CBDR_CLEAN_WORK (16). The software BD enables correct DMA memory
release. With this, struct ntmp_dma_buf and ntmp_free_data_mem() are no
longer needed and are removed.
3. Require callers to hold ring_lock across netc_xmit_ntmp_cmd()
netc_xmit_ntmp_cmd() releases the ring_lock before the caller finishes
consuming the response. At this point, if a concurrent thread submits
a new command, it may trigger ntmp_clean_cbdr() and free the DMA buffer
while it is still in use. Move ring_lock ownership to the caller to
ensure the response buffer cannot be reclaimed prematurely. So the
helpers ntmp_select_and_lock_cbdr() and ntmp_unlock_cbdr() are added.
These changes eliminate the DMA use-after-free condition and ensure safe
and consistent BD reclamation and DMA buffer lifecycle management.15dCVE-2026-532265.5 MED2.5%
——1In the Linux kernel, the following vulnerability has been resolved:
gpio: rockchip: fix generic IRQ chip leak on remove
The driver allocates domain generic chips using
irq_alloc_domain_generic_chips() during probe. However, on driver
remove/teardown, the generic chips are not automatically freed when the
IRQ domain is removed because the domain flags do not include
IRQ_DOMAIN_FLAG_DESTROY_GC.
This causes both the domain generic chips structure and the associated
generic chips to be leaked. Additionally, the generic chips remain on
the global gc_list and may later be visited by generic IRQ chip suspend,
resume, or shutdown callbacks after the GPIO bank has been removed,
potentially resulting in a use-after-free and kernel crash.
Fix the resource leak by explicitly calling
irq_domain_remove_generic_chips() before removing the IRQ domain in
rockchip_gpio_remove().5dCVE-2026-1380—2.5%
——1——CVE-2025-55046—2.5%
——1——CVE-2026-8942—2.5%
——1——CVE-2026-23999—2.5%
——1——CVE-2026-9500—2.5%
——1——CVE-2026-35247—2.5%
——1——CVE-2025-40039—2.5%
——1——CVE-2026-31568—2.5%
——1——CVE-2026-44523—2.5%
——1——CVE-2025-20693—2.5%
——1——CVE-2023-32837—2.5%
——1——CVE-2025-71128—2.5%
——1——CVE-2026-640507.8 HIG2.5%
——1In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dpu: don't mix devm and drmm functions
Mixing devm and drmm functions will result in a use-after-free on msm
driver teardown if userspace keeps a reference on the drm device:
The WB connector data will be destroyed because of the use of
devm_kzalloc()), while the usersoace still can try interacting with the
WB connector (which uses drmm_ functions).
Change dpu_writeback_init() to use drmm_.
Patchwork: https://patchwork.freedesktop.org/patch/722656/3dCVE-2026-135733.3 LOW2.5%
——1A vulnerability was found in llvm llvm-project up to 22.1.6. This affects the function llvm::StringMap::insert in the library /lib/IR/ValueSymbolTable.cpp of the component ValueSymbolTable Module. The manipulation results in stack-based buffer overflow. Attacking locally is a requirement. The exploit has been made public and could be used. The presence of this vulnerability remains uncertain at this time. The LLVM project explains, that the reported behavior is outside its documented security scope and therefore not considered a security vulnerability.16dCVE-2021-0436—2.5%
——1——CVE-2025-13521—2.5%
——1——CVE-2026-8904—2.5%
——1——CVE-2026-41255—2.5%
——1——CVE-2025-8298—2.5%
——1——CVE-2026-46020—2.5%
——1——CVE-2026-31532—2.5%
——1——CVE-2026-45951—2.5%
——1——CVE-2026-48156—2.5%
——1——CVE-2021-0702—2.5%
——1——CVE-2025-15067—2.5%
——1——CVE-2024-42037—2.5%
——1——CVE-2026-532907.8 HIG2.5%
——1In the Linux kernel, the following vulnerability has been resolved:
drm/xe/eustall: Fix drm_dev_put called before stream disable in close
In xe_eu_stall_stream_close(), drm_dev_put() is called before the
stream is disabled and its resources are freed. If this drops the
last reference, the device structures could be freed while the
subsequent cleanup code still accesses them, leading to a
use-after-free.
Fix this by moving drm_dev_put() after all device accesses are
complete. This matches the ordering in xe_oa_release().
(cherry picked from commit 35aff528f7297e949e5e19c9cd7fd748cf1cf21c)15d