Vulnerabilities exploitable today
349,429in 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,647
New KEV · 24H0
Exploit Today ≥ 701,582
Distribution · last window
- Critical1,327
- High4,319
- Medium3,691
- Low289
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2023-44129—0.7%
——0——CVE-2024-21478—0.7%
——0——CVE-2023-20977—0.7%
——0——CVE-2026-22276—0.7%
——0——CVE-2025-71074—0.7%
——0——CVE-2026-26949—0.7%
——0——CVE-2023-20842—0.7%
——0——CVE-2025-47359—0.7%
——0——CVE-2025-48428—0.7%
——0——CVE-2021-0881—0.7%
——0——CVE-2021-0878—0.7%
——0——CVE-2022-20261—0.7%
——0——CVE-2025-48646—0.7%
——0——CVE-2026-21016—0.7%
——0——CVE-2021-0882—0.7%
——0——CVE-2022-38681—0.7%
——0——CVE-2025-48642—0.7%
——0——CVE-2021-0883—0.7%
——0——CVE-2021-0880—0.7%
——0——CVE-2025-48640—0.7%
——0——CVE-2021-0879—0.7%
——0——CVE-2026-0075—0.7%
——0——CVE-2021-39649—0.7%
——0——CVE-2024-43086—0.7%
——0——CVE-2026-314664.7 MED0.7%
——0In the Linux kernel, the following vulnerability has been resolved:
mm/huge_memory: fix folio isn't locked in softleaf_to_folio()
On arm64 server, we found folio that get from migration entry isn't locked
in softleaf_to_folio(). This issue triggers when mTHP splitting and
zap_nonpresent_ptes() races, and the root cause is lack of memory barrier
in softleaf_to_folio(). The race is as follows:
CPU0 CPU1
deferred_split_scan() zap_nonpresent_ptes()
lock folio
split_folio()
unmap_folio()
change ptes to migration entries
__split_folio_to_order() softleaf_to_folio()
set flags(including PG_locked) for tail pages folio = pfn_folio(softleaf_to_pfn(entry))
smp_wmb() VM_WARN_ON_ONCE(!folio_test_locked(folio))
prep_compound_page() for tail pages
In __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages
are visible before the tail page becomes non-compound. smp_wmb() should
be paired with smp_rmb() in softleaf_to_folio(), which is missed. As a
result, if zap_nonpresent_ptes() accesses migration entry that stores tail
pfn, softleaf_to_folio() may see the updated compound_head of tail page
before page->flags.
This issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio()
because of the race between folio split and zap_nonpresent_ptes()
leading to a folio incorrectly undergoing modification without a folio
lock being held.
This is a BUG_ON() before commit 93976a20345b ("mm: eliminate further
swapops predicates"), which in merged in v6.19-rc1.
To fix it, add missing smp_rmb() if the softleaf entry is migration entry
in softleaf_to_folio() and softleaf_to_page().
[tujinjiang@huawei.com: update function name and comments]4dCVE-2026-234634.7 MED0.7%
——0In the Linux kernel, the following vulnerability has been resolved:
soc: fsl: qbman: fix race condition in qman_destroy_fq
When QMAN_FQ_FLAG_DYNAMIC_FQID is set, there's a race condition between
fq_table[fq->idx] state and freeing/allocating from the pool and
WARN_ON(fq_table[fq->idx]) in qman_create_fq() gets triggered.
Indeed, we can have:
Thread A Thread B
qman_destroy_fq() qman_create_fq()
qman_release_fqid()
qman_shutdown_fq()
gen_pool_free()
-- At this point, the fqid is available again --
qman_alloc_fqid()
-- so, we can get the just-freed fqid in thread B --
fq->fqid = fqid;
fq->idx = fqid * 2;
WARN_ON(fq_table[fq->idx]);
fq_table[fq->idx] = fq;
fq_table[fq->idx] = NULL;
And adding some logs between qman_release_fqid() and
fq_table[fq->idx] = NULL makes the WARN_ON() trigger a lot more.
To prevent that, ensure that fq_table[fq->idx] is set to NULL before
gen_pool_free() is called by using smp_wmb().4dCVE-2021-0873—0.7%
——0——CVE-2021-0872—0.7%
——0——CVE-2023-42741—0.7%
——0——CVE-2021-0875—0.7%
——0——CVE-2025-9970—0.7%
——0——CVE-2026-56269—0.7%
——0——CVE-2023-21014—0.7%
——0——CVE-2026-57438—0.7%
——0——CVE-2025-38311—0.7%
——0——CVE-2024-47030—0.7%
——0——CVE-2022-26436—0.7%
——0——CVE-2026-0007—0.7%
——0——CVE-2025-48585—0.7%
——0——CVE-2026-0024—0.7%
——0——