Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

017 - Ir a la línea de ayuda en Ciberseguridad    Ir a Agenda     Ir a Sala de prensa     Ir a suscripción de boletines

Ir al buscador

Vulnerabilidades

Con el objetivo de informar, advertir y ayudar a los profesionales sobre las últimas vulnerabilidades de seguridad en sistemas tecnológicos, ponemos a disposición de los usuarios interesados en esta información una base de datos con información en castellano sobre cada una de las últimas vulnerabilidades documentadas y conocidas.

Este repositorio con más de 75.000 registros esta basado en la información de NVD (National Vulnerability Database) – en función de un acuerdo de colaboración – por el cual desde INCIBE realizamos la traducción al castellano de la información incluida. En ocasiones este listado mostrará vulnerabilidades que aún no han sido traducidas debido a que se recogen en el transcurso del tiempo en el que el equipo de INCIBE realiza el proceso de traducción.

Se emplea el estándar de nomenclatura de vulnerabilidades CVE (Common Vulnerabilities and Exposures), con el fin de facilitar el intercambio de información entre diferentes bases de datos y herramientas. Cada una de las vulnerabilidades recogidas enlaza a diversas fuentes de información así como a parches disponibles o soluciones aportadas por los fabricantes y desarrolladores. Es posible realizar búsquedas avanzadas teniendo la opción de seleccionar diferentes criterios como el tipo de vulnerabilidad, fabricante, tipo de impacto entre otros, con el fin de acortar los resultados.

Mediante suscripción RSS o Boletines podemos estar informados diariamente de las últimas vulnerabilidades incorporadas al repositorio.

CVE-2026-53103
Fecha de publicación:
24/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7925: fix potential deadlock in mt7925_roc_abort_sync<br /> <br /> roc_abort_sync() can deadlock with roc_work(). roc_work() holds<br /> dev-&gt;mt76.mutex, while cancel_work_sync() waits for roc_work()<br /> to finish. If the caller already owns the same mutex, both<br /> sides block and no progress is possible.<br /> <br /> This deadlock can occur during station removal when<br /> mt76_sta_state() -&gt; mt76_sta_remove() -&gt;<br /> mt7925_mac_sta_remove_link() -&gt; mt7925_mac_link_sta_remove() -&gt;<br /> mt7925_roc_abort_sync() invokes cancel_work_sync() while<br /> roc_work() is still running and holding dev-&gt;mt76.mutex.<br /> <br /> This avoids the mutex deadlock and preserves exactly-once<br /> work ownership.
Gravedad CVSS v3.1: MEDIA
Última modificación:
21/07/2026

CVE-2026-53102
Fecha de publicación:
24/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: Fix memory leak after mt76_connac_mcu_alloc_sta_req()<br /> <br /> mt76_connac_mcu_alloc_sta_req() allocates an skb which is expected to<br /> be freed eventually by mt76_mcu_skb_send_msg(). However, currently if<br /> an intermediate function fails before sending, the allocated skb is<br /> leaked.<br /> <br /> Specifically, mt76_connac_mcu_sta_wed_update() and<br /> mt76_connac_mcu_sta_key_tlv() may fail, leading to an immediate memory<br /> leak in the error path.<br /> <br /> Fix this by explicitly freeing the skb in these error paths.<br /> Commit 7c0f63fe37a5 ("wifi: mt76: mt7996: fix memory leak on<br /> mt7996_mcu_sta_key_tlv error") made a similar change.<br /> <br /> Compile tested only. Issue found using a prototype static analysis tool<br /> and code review.
Gravedad CVSS v3.1: MEDIA
Última modificación:
21/07/2026

CVE-2026-53101
Fecha de publicación:
24/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7921: fix potential deadlock in mt7921_roc_abort_sync<br /> <br /> roc_abort_sync() can deadlock with roc_work(). roc_work() holds<br /> dev-&gt;mt76.mutex, while cancel_work_sync() waits for roc_work()<br /> to finish. If the caller already owns the same mutex, both<br /> sides block and no progress is possible.<br /> <br /> This deadlock can occur during station removal when<br /> mt76_sta_state() -&gt; mt76_sta_remove() -&gt; mt7921_mac_sta_remove() -&gt;<br /> mt7921_roc_abort_sync() invokes cancel_work_sync() while<br /> roc_work() is still running and holding dev-&gt;mt76.mutex.<br /> <br /> This avoids the mutex deadlock and preserves exactly-once<br /> work ownership.
Gravedad CVSS v3.1: MEDIA
Última modificación:
21/07/2026

CVE-2026-53100
Fecha de publicación:
24/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: fix deadlock in remain-on-channel<br /> <br /> mt76_remain_on_channel() and mt76_roc_complete() call mt76_set_channel()<br /> while already holding dev-&gt;mutex. Since mt76_set_channel() also acquires<br /> dev-&gt;mutex, this results in a deadlock.<br /> <br /> Use __mt76_set_channel() instead of mt76_set_channel().<br /> Add cancel_delayed_work_sync() for mac_work before acquiring the mutex<br /> in mt76_remain_on_channel() to prevent a secondary deadlock with the<br /> mac_work workqueue.
Gravedad CVSS v3.1: MEDIA
Última modificación:
21/07/2026

CVE-2026-53099
Fecha de publicación:
24/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Switch CONFIG_CFI_CLANG to CONFIG_CFI<br /> <br /> This was renamed in commit 23ef9d439769 ("kcfi: Rename CONFIG_CFI_CLANG<br /> to CONFIG_CFI") as it is now a compiler-agnostic option. Using the wrong<br /> name results in the code getting compiled out. Meaning the CFI failures<br /> for btf_dtor_kfunc_t would still trigger.
Gravedad CVSS v3.1: MEDIA
Última modificación:
21/07/2026

CVE-2026-53098
Fecha de publicación:
24/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7915: fix use-after-free bugs in mt7915_mac_dump_work()<br /> <br /> When the mt7915 pci chip is detaching, the mt7915_crash_data is<br /> released in mt7915_coredump_unregister(). However, the work item<br /> dump_work may still be running or pending, leading to UAF bugs<br /> when the already freed crash_data is dereferenced again in<br /> mt7915_mac_dump_work().<br /> <br /> The race condition can occur as follows:<br /> <br /> CPU 0 (removal path) | CPU 1 (workqueue)<br /> mt7915_pci_remove() | mt7915_sys_recovery_set()<br /> mt7915_unregister_device() | mt7915_reset()<br /> mt7915_coredump_unregister() | queue_work()<br /> vfree(dev-&gt;coredump.crash_data) | mt7915_mac_dump_work()<br /> | crash_data-&gt; // UAF<br /> <br /> Fix this by ensuring dump_work is properly canceled before<br /> the crash_data is deallocated. Add cancel_work_sync() in<br /> mt7915_unregister_device() to synchronize with any pending<br /> or executing dump work.
Gravedad CVSS v3.1: ALTA
Última modificación:
21/07/2026

CVE-2026-53105
Fecha de publicación:
24/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7925: prevent NULL vif dereference in mt7925_mac_write_txwi<br /> <br /> Check for a NULL `vif` before accessing `ieee80211_vif_is_mld(vif)` to<br /> avoid a potential kernel panic in scenarios where `vif` might not be<br /> initialized.
Gravedad CVSS v3.1: MEDIA
Última modificación:
23/07/2026

CVE-2026-53104
Fecha de publicación:
24/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: Fix memory leak destroying device<br /> <br /> All MT76 rx queues have an associated page_pool even if the queue is not<br /> associated to a NAPI (e.g. WED RRO queues with WED enabled). Destroy the<br /> page_pool running mt76_dma_cleanup routine during module unload.<br /> Moreover returns pages to the page pool if WED is not enabled for WED RRO<br /> queues.
Gravedad CVSS v3.1: MEDIA
Última modificación:
23/07/2026

CVE-2026-53106
Fecha de publicación:
24/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Do not allow deleting local storage in NMI<br /> <br /> Currently, local storage may deadlock when deferring freeing selem or<br /> local storage through kfree_rcu(), call_rcu() or call_rcu_tasks_trace()<br /> in NMI or reentrant. Since deleting selem in NMI is an unlikely use<br /> case, partially mitigate it by returning error when calling from<br /> bpf_xxx_storage_delete() helpers in NMI. Note that, it is still possible<br /> to deadlock through reentrant. A full mitigation requires returning<br /> error when irqs_disabled() is true, which, however is too heavy-handed<br /> for bpf_xxx_storage_delete().<br /> <br /> The long-term solution requires _nolock versions of call_rcu. Another<br /> possible solution is to defer the free through irq_work [0], but it<br /> would grow the size of selem, which is non-ideal.<br /> <br /> The check is only needed in bpf_selem_unlink(), which is used by helpers<br /> and syscalls. bpf_selem_unlink_nofail() is fine as it is called during<br /> map and owner tear down that never run in NMI or reentrant.<br /> <br /> [0] https://lore.kernel.org/bpf/20260205190233.912-1-alexei.starovoitov@gmail.com/
Gravedad CVSS v3.1: MEDIA
Última modificación:
23/07/2026

CVE-2026-53107
Fecha de publicación:
24/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: libertas: don&amp;#39;t kill URBs in interrupt context<br /> <br /> Serialization for the TX path was enforced by calling<br /> usb_kill_urb()/usb_kill_anchored_urbs(), to prevent transmission before<br /> a previous URB was completed. usb_tx_block() can be called from<br /> interrupt context (e.g. in the HCD giveback path), so we can&amp;#39;t always<br /> use it to kill in-flight URBs.<br /> <br /> Prevent sleeping during interrupt context by checking the tx_submitted<br /> anchor for existing URBs. We now return -EBUSY, to indicate there&amp;#39;s<br /> a pending request.
Gravedad CVSS v3.1: MEDIA
Última modificación:
23/07/2026

CVE-2026-53097
Fecha de publicación:
24/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7996: fix use-after-free bugs in mt7996_mac_dump_work()<br /> <br /> When the mt7996 pci chip is detaching, the mt7996_crash_data is<br /> released in mt7996_coredump_unregister(). However, the work item<br /> dump_work may still be running or pending, leading to UAF bugs<br /> when the already freed crash_data is dereferenced again in<br /> mt7996_mac_dump_work().<br /> <br /> The race condition can occur as follows:<br /> <br /> CPU 0 (removal path) | CPU 1 (workqueue)<br /> mt7996_pci_remove() | mt7996_sys_recovery_set()<br /> mt7996_unregister_device() | mt7996_reset()<br /> mt7996_coredump_unregister() | queue_work()<br /> vfree(dev-&gt;coredump.crash_data) | mt7996_mac_dump_work()<br /> | crash_data-&gt; // UAF<br /> <br /> Fix this by ensuring dump_work is properly canceled before<br /> the crash_data is deallocated. Add cancel_work_sync() in<br /> mt7996_unregister_device() to synchronize with any pending<br /> or executing dump work.
Gravedad CVSS v3.1: ALTA
Última modificación:
21/07/2026

CVE-2026-53096
Fecha de publicación:
24/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Use RCU-safe iteration in dev_map_redirect_multi() SKB path<br /> <br /> The DEVMAP_HASH branch in dev_map_redirect_multi() uses<br /> hlist_for_each_entry_safe() to iterate hash buckets, but this function<br /> runs under RCU protection (called from xdp_do_generic_redirect_map()<br /> in softirq context). Concurrent writers (__dev_map_hash_update_elem,<br /> dev_map_hash_delete_elem) modify the list using RCU primitives<br /> (hlist_add_head_rcu, hlist_del_rcu).<br /> <br /> hlist_for_each_entry_safe() performs plain pointer dereferences without<br /> rcu_dereference(), missing the acquire barrier needed to pair with<br /> writers&amp;#39; rcu_assign_pointer(). On weakly-ordered architectures (ARM64,<br /> POWER), a reader can observe a partially-constructed node. It also<br /> defeats CONFIG_PROVE_RCU lockdep validation and KCSAN data-race<br /> detection.<br /> <br /> Replace with hlist_for_each_entry_rcu() using rcu_read_lock_bh_held()<br /> as the lockdep condition, consistent with the rcu_dereference_check()<br /> used in the DEVMAP (non-hash) branch of the same functions. Also fix<br /> the same incorrect lockdep_is_held(&amp;dtab-&gt;index_lock) condition in<br /> dev_map_enqueue_multi(), where the lock is not held either.
Gravedad CVSS v3.1: ALTA
Última modificación:
21/07/2026
Suscribirse a Vulnerabilidades