Vulnerabilidades explotables hoy
367,284en la vista actual
Score único combinando CVSS, membresía KEV y EPSS. Cada CVE con su ficha propia — timeline desde publicación hasta explotación activa.
En catálogo KEV1,685
Nuevos KEV · 24H0
Exploit Today ≥ 701,629
Distribución · última ventana
- Crítico2,274
- Alto9,334
- Medio5,332
- Bajo522
Ventana
Severidad
Filtros
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-531025.5 MED1.3%
——0In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: Fix memory leak after mt76_connac_mcu_alloc_sta_req()
mt76_connac_mcu_alloc_sta_req() allocates an skb which is expected to
be freed eventually by mt76_mcu_skb_send_msg(). However, currently if
an intermediate function fails before sending, the allocated skb is
leaked.
Specifically, mt76_connac_mcu_sta_wed_update() and
mt76_connac_mcu_sta_key_tlv() may fail, leading to an immediate memory
leak in the error path.
Fix this by explicitly freeing the skb in these error paths.
Commit 7c0f63fe37a5 ("wifi: mt76: mt7996: fix memory leak on
mt7996_mcu_sta_key_tlv error") made a similar change.
Compile tested only. Issue found using a prototype static analysis tool
and code review.41dCVE-2025-21027—1.3%
——0——CVE-2026-35370—1.3%
——0——CVE-2022-20319—1.3%
——0——CVE-2024-45566—1.3%
——0——CVE-2023-28006—1.3%
——0——CVE-2026-31775—1.3%
——0——CVE-2021-0568—1.3%
——0——CVE-2022-24932—1.3%
——0——CVE-2026-23301—1.3%
——0——CVE-2026-31744—1.3%
——0——CVE-2026-23067—1.3%
——0——CVE-2026-530075.5 MED1.3%
——0In the Linux kernel, the following vulnerability has been resolved:
ice: fix potential NULL pointer deref in error path of ice_set_ringparam()
ice_set_ringparam nullifies tstamp_ring of temporary tx_rings, without
clearing ICE_TX_RING_FLAGS_TXTIME bit.
When ICE_TX_RING_FLAGS_TXTIME is set and the subsequent
ice_setup_tx_ring() call fails, a NULL pointer dereference could happen
in the unwinding sequence:
ice_clean_tx_ring()
-> ice_is_txtime_cfg() == true (ICE_TX_RING_FLAGS_TXTIME is set)
-> ice_free_tx_tstamp_ring()
-> ice_free_tstamp_ring()
-> tstamp_ring->desc (NULL deref)
Clear ICE_TX_RING_FLAGS_TXTIME bit to avoid the potential issue.
Note that this potential issue is found by manual code review.
Compile test only since unfortunately I don't have E830 devices.48dCVE-2026-45975—1.3%
——0——CVE-2026-43389—1.3%
——0——CVE-2023-21034—1.3%
——0——CVE-2025-58345—1.3%
——0——CVE-2026-32330—1.3%
——0——CVE-2026-0936—1.3%
——0——CVE-2026-43431—1.3%
——0——CVE-2025-36603—1.3%
——0——CVE-2026-234335.5 MED1.3%
——0In the Linux kernel, the following vulnerability has been resolved:
arm_mpam: Fix null pointer dereference when restoring bandwidth counters
When an MSC supporting memory bandwidth monitoring is brought offline and
then online, mpam_restore_mbwu_state() calls __ris_msmon_read() via ipi to
restore the configuration of the bandwidth counters. It doesn't care about
the value read, mbwu_arg.val, and doesn't set it leading to a null pointer
dereference when __ris_msmon_read() adds to it. This results in a kernel
oops with a call trace such as:
Call trace:
__ris_msmon_read+0x19c/0x64c (P)
mpam_restore_mbwu_state+0xa0/0xe8
smp_call_on_cpu_callback+0x1c/0x38
process_one_work+0x154/0x4b4
worker_thread+0x188/0x310
kthread+0x11c/0x130
ret_from_fork+0x10/0x20
Provide a local variable for val to avoid __ris_msmon_read() dereferencing
a null pointer when adding to val.38dCVE-2025-713135.5 MED1.3%
——0In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: Add missing NULL check for alloc_workqueue()
alloc_workqueue() can return NULL on memory allocation failure. Without
proper error checking, this may lead to a NULL pointer dereference when
queue_work() is later called with the NULL workqueue pointer in
epf_ntb_epc_init().
Add a NULL check immediately after alloc_workqueue() and return -ENOMEM on
failure to prevent the driver from loading with an invalid workqueue
pointer.40dCVE-2022-20099—1.3%
——0——CVE-2025-58869—1.3%
——0——CVE-2026-43335—1.3%
——0——CVE-2026-31460—1.3%
——0——CVE-2025-43903—1.3%
——0——CVE-2026-24942—1.3%
——0——CVE-2025-13668—1.3%
——0——CVE-2026-31573—1.3%
——0——CVE-2026-13478—1.3%
——0——CVE-2026-43096—1.3%
——0——CVE-2024-10404—1.3%
——0——CVE-2025-0046—1.3%
——0Incorrect directory permissions could allow a local user to escalate their privileges, potentially resulting in arbitrary code execution.19dCVE-2023-20932—1.3%
——0——CVE-2021-30161—1.3%
——0——CVE-2024-27219—1.3%
——0——CVE-2026-31753—1.3%
——0——CVE-2026-532855.5 MED1.3%
——0In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Wrap DCN32 phantom-plane allocation in DC_RUN_WITH_PREEMPTION_ENABLED
[Why]
dcn32_validate_bandwidth() wraps dcn32_internal_validate_bw() with
DC_FP_START()/DC_FP_END(). In x86 non-RT, DC_FP_START takes fpregs_lock(),
which disables local softirqs.
The DML1 path through dcn32_enable_phantom_plane() calls kvzalloc() to
allocate ~335 KiB for dc_plane_state. This triggers the vmalloc path,
which calls BUG_ON(in_interrupt()) because it's invoked within the
FPU-enabled (softirq disabled) region, leading to a kernel crash.
[How]
Wrap the dc_state_create_phantom_plane() call with the
DC_RUN_WITH_PREEMPTION_ENABLED() macro to allow preemption during
this memory allocation.
(cherry picked from commit 885ccbef7b94a8b38f69c4211c679021aa27ad11)55d