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

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-53324

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: Use pci_name() for debugfs directory naming<br /> <br /> Use pci_name(pdev) for the per-device debugfs directory instead of<br /> hardcoded "0" for PFs and pci_slot_name(pdev-&gt;slot) for VFs. The<br /> previous approach had two issues:<br /> <br /> 1. pci_slot_name() dereferences pdev-&gt;slot, which can be NULL for VFs<br /> in environments like generic VFIO passthrough or nested KVM,<br /> causing a NULL pointer dereference.<br /> <br /> 2. Multiple PFs would all use "0", and VFs across different PCI<br /> domains or buses could share the same slot name, leading to<br /> -EEXIST errors from debugfs_create_dir().<br /> <br /> pci_name(pdev) returns the unique BDF address, is always valid, and is<br /> unique across the system.
Gravedad: Pendiente de análisis
Última modificación:
30/06/2026

CVE-2026-53307

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: pinconf-generic: Fully validate &amp;#39;pinmux&amp;#39; property<br /> <br /> The pinconf_generic_parse_dt_pinmux() assumes that the &amp;#39;pinmux&amp;#39; property<br /> is not empty when present. This might be not true. With that, the allocator<br /> will give a special value in return and not NULL which lead to the crash<br /> when trying to access that (invalid) memory. Fix that by fully validating<br /> &amp;#39;pinmux&amp;#39; value, including its length.
Gravedad: Pendiente de análisis
Última modificación:
30/06/2026

CVE-2026-53308

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: max77705: Free allocated workqueue and fix removal order<br /> <br /> Use devm interface for allocating workqueue to fix two bugs at the same<br /> time:<br /> <br /> 1. Driver leaks the memory on remove(), because the workqueue is not<br /> destroyed.<br /> <br /> 2. Driver allocates workqueue and then registers interrupt handlers<br /> with devm interface. This means that probe error paths will not use a<br /> reversed order, but first destroy the workqueue and then, via devm<br /> release handlers, free the interrupt.<br /> <br /> The interrupt handler schedules work on this exact workqueue, thus if<br /> interrupt is hit in this short time window - after destroying<br /> workqueue, but before devm() frees the interrupt - the schedulled<br /> work will lead to use of freed memory.<br /> <br /> Change is not equivalent in the workqueue itself: use non-legacy API<br /> which does not set (__WQ_LEGACY | WQ_MEM_RECLAIM). The workqueue is<br /> used to update power supply (power_supply_changed()) status, thus there<br /> is no point to run it for memory reclaim. Note that dev_name() is not<br /> directly used in second argument to prevent possible unlikely parsing<br /> any "%" character in device name as format.
Gravedad: Pendiente de análisis
Última modificación:
30/06/2026

CVE-2026-53309

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2/dlm: fix off-by-one in dlm_match_regions() region comparison<br /> <br /> The local-vs-remote region comparison loop uses &amp;#39;
Gravedad CVSS v3.1: CRÍTICA
Última modificación:
30/06/2026

CVE-2026-53310

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc/tegra: cbb: Fix cross-fabric target timeout lookup<br /> <br /> When a fabric receives an error interrupt, the error may have<br /> occurred on a different fabric. The target timeout lookup was using<br /> the wrong base address (cbb-&gt;regs) with offsets from a different<br /> fabric&amp;#39;s target map, causing a kernel page fault.<br /> <br /> Unable to handle kernel paging request at virtual address ffff80000954cc00<br /> pc : tegra234_cbb_get_tmo_slv+0xc/0x28<br /> Call trace:<br /> tegra234_cbb_get_tmo_slv+0xc/0x28<br /> print_err_notifier+0x6c0/0x7d0<br /> tegra234_cbb_isr+0xe4/0x1b4<br /> <br /> Add tegra234_cbb_get_fabric() to look up the correct fabric device<br /> using fab_id, and use its base address for accessing target timeout<br /> registers.
Gravedad: Pendiente de análisis
Última modificación:
30/06/2026

CVE-2026-53311

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse: fix uninit-value in fuse_dentry_revalidate()<br /> <br /> fuse_dentry_revalidate() may be called with a dentry that didn&amp;#39;t had<br /> -&gt;d_time initialised. The issue was found with KMSAN, where lookup_open()<br /> calls __d_alloc(), followed by d_revalidate(), as shown below:<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in fuse_dentry_revalidate+0x150/0x13d0 fs/fuse/dir.c:394<br /> fuse_dentry_revalidate+0x150/0x13d0 fs/fuse/dir.c:394<br /> d_revalidate fs/namei.c:1030 [inline]<br /> lookup_open fs/namei.c:4405 [inline]<br /> open_last_lookups fs/namei.c:4583 [inline]<br /> path_openat+0x1614/0x64c0 fs/namei.c:4827<br /> do_file_open+0x2aa/0x680 fs/namei.c:4859<br /> [...]<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slub.c:4466 [inline]<br /> slab_alloc_node mm/slub.c:4788 [inline]<br /> kmem_cache_alloc_lru_noprof+0x382/0x1280 mm/slub.c:4807<br /> __d_alloc+0x55/0xa00 fs/dcache.c:1740<br /> d_alloc_parallel+0x99/0x2740 fs/dcache.c:2604<br /> lookup_open fs/namei.c:4398 [inline]<br /> open_last_lookups fs/namei.c:4583 [inline]<br /> path_openat+0x135f/0x64c0 fs/namei.c:4827<br /> do_file_open+0x2aa/0x680 fs/namei.c:4859<br /> [...]<br /> =====================================================
Gravedad: Pendiente de análisis
Última modificación:
30/06/2026

CVE-2026-53312

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/riscv: Remove overflows on the invalidation path<br /> <br /> Since RISC-V supports a sign extended page table it should support<br /> a gather-&gt;end of ULONG_MAX, but if this happens it will infinite loop<br /> because of the overflow.<br /> <br /> Also avoid overflow computing the length by moving the +1 to the other<br /> side of the
Gravedad: Pendiente de análisis
Última modificación:
30/06/2026

CVE-2026-53313

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Avoid NULL dereference in dc_dmub_srv error paths<br /> <br /> In dc_dmub_srv_log_diagnostic_data() and<br /> dc_dmub_srv_enable_dpia_trace().<br /> <br /> Both functions check:<br /> <br /> if (!dc_dmub_srv || !dc_dmub_srv-&gt;dmub)<br /> <br /> and then call DC_LOG_ERROR() inside that block.<br /> <br /> DC_LOG_ERROR() uses dc_dmub_srv-&gt;ctx internally. So if<br /> dc_dmub_srv is NULL, the logging itself can dereference a<br /> NULL pointer and cause a crash.<br /> <br /> Fix this by splitting the checks.<br /> <br /> First check if dc_dmub_srv is NULL and return immediately.<br /> Then check dc_dmub_srv-&gt;dmub and log the error only when<br /> dc_dmub_srv is valid.<br /> <br /> Fixes the below:<br /> ../display/dc/dc_dmub_srv.c:962 dc_dmub_srv_log_diagnostic_data() error: we previously assumed &amp;#39;dc_dmub_srv&amp;#39; could be null (see line 961)<br /> ../display/dc/dc_dmub_srv.c:1167 dc_dmub_srv_enable_dpia_trace() error: we previously assumed &amp;#39;dc_dmub_srv&amp;#39; could be null (see line 1166)
Gravedad: Pendiente de análisis
Última modificación:
30/06/2026

CVE-2026-53314

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> padata: Put CPU offline callback in ONLINE section to allow failure<br /> <br /> syzbot reported the following warning:<br /> <br /> DEAD callback error for CPU1<br /> WARNING: kernel/cpu.c:1463 at _cpu_down+0x759/0x1020 kernel/cpu.c:1463, CPU#0: syz.0.1960/14614<br /> <br /> at commit 4ae12d8bd9a8 ("Merge tag &amp;#39;kbuild-fixes-7.0-2&amp;#39; of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux")<br /> which tglx traced to padata_cpu_dead() given it&amp;#39;s the only<br /> sub-CPUHP_TEARDOWN_CPU callback that returns an error.<br /> <br /> Failure isn&amp;#39;t allowed in hotplug states before CPUHP_TEARDOWN_CPU<br /> so move the CPU offline callback to the ONLINE section where failure is<br /> possible.
Gravedad: Pendiente de análisis
Última modificación:
30/06/2026

CVE-2026-53315

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/ras: Fix NULL deref in ras_core_get_utc_second_timestamp()<br /> <br /> ras_core_get_utc_second_timestamp() retrieves the current UTC timestamp<br /> (in seconds since the Unix epoch) through a platform-specific RAS system<br /> callback and is used for timestamping RAS error events.<br /> <br /> The function checks ras_core in the conditional statement before calling<br /> the sys_fn callback. However, when the condition fails, the function<br /> prints an error message using ras_core-&gt;dev.<br /> <br /> If ras_core is NULL, this can lead to a potential NULL pointer<br /> dereference when accessing ras_core-&gt;dev.<br /> <br /> Add an early NULL check for ras_core at the beginning of the function<br /> and return 0 when the pointer is not valid. This prevents the<br /> dereference and makes the control flow clearer.
Gravedad: Pendiente de análisis
Última modificación:
30/06/2026

CVE-2026-53316

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/ras: Fix NULL deref in ras_core_ras_interrupt_detected()<br /> <br /> Fixes a NULL pointer dereference when ras_core is NULL and ras_core-&gt;dev<br /> is accessed in the error path.<br /> <br /> Reported by: Dan Carpenter
Gravedad: Pendiente de análisis
Última modificación:
30/06/2026

CVE-2026-53298

Fecha de publicación:
26/06/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: airoha: Move ndesc initialization at end of airoha_qdma_init_rx_queue()<br /> <br /> If queue entry or DMA descriptor list allocation fails in<br /> airoha_qdma_init_rx_queue routine, airoha_qdma_cleanup() will trigger a<br /> NULL pointer dereference running netif_napi_del() for RX queue NAPIs<br /> since netif_napi_add() has never been executed to this particular RX NAPI.<br /> The issue is due to the early ndesc initialization in<br /> airoha_qdma_init_rx_queue() since airoha_qdma_cleanup() relies on ndesc<br /> value to check if the queue is properly initialized. Fix the issue moving<br /> ndesc initialization at end of airoha_qdma_init_tx routine.<br /> Move page_pool allocation after descriptor list allocation in order to<br /> avoid memory leaks if desc allocation fails.
Gravedad: Pendiente de análisis
Última modificación:
30/06/2026