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

Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wireguard: device: use exit_rtnl callback instead of manual rtnl_lock in pre_exit<br /> <br /> wg_netns_pre_exit() manually acquires rtnl_lock() inside the<br /> pernet .pre_exit callback. This causes a hung task when another<br /> thread holds rtnl_mutex - the cleanup_net workqueue (or the<br /> setup_net failure rollback path) blocks indefinitely in<br /> wg_netns_pre_exit() waiting to acquire the lock.<br /> <br /> Convert to .exit_rtnl, introduced in commit 7a60d91c690b ("net:<br /> Add -&gt;exit_rtnl() hook to struct pernet_operations."), where the<br /> framework already holds RTNL and batches all callbacks under a<br /> single rtnl_lock()/rtnl_unlock() pair, eliminating the contention<br /> window.<br /> <br /> The rcu_assign_pointer(wg-&gt;creating_net, NULL) is safe to move<br /> from .pre_exit to .exit_rtnl (which runs after synchronize_rcu())<br /> because all RCU readers of creating_net either use maybe_get_net()<br /> - which returns NULL for a dying namespace with zero refcount - or<br /> access net-&gt;user_ns which remains valid throughout the entire<br /> ops_undo_list sequence.<br /> <br /> [ Jason: added __net_exit and __read_mostly annotations that were missing. ]
Gravedad CVSS v3.1: MEDIA
Última modificación:
27/04/2026

CVE-2026-31575

Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/userfaultfd: fix hugetlb fault mutex hash calculation<br /> <br /> In mfill_atomic_hugetlb(), linear_page_index() is used to calculate the<br /> page index for hugetlb_fault_mutex_hash(). However, linear_page_index()<br /> returns the index in PAGE_SIZE units, while hugetlb_fault_mutex_hash()<br /> expects the index in huge page units. This mismatch means that different<br /> addresses within the same huge page can produce different hash values,<br /> leading to the use of different mutexes for the same huge page. This can<br /> cause races between faulting threads, which can corrupt the reservation<br /> map and trigger the BUG_ON in resv_map_release().<br /> <br /> Fix this by introducing hugetlb_linear_page_index(), which returns the<br /> page index in huge page granularity, and using it in place of<br /> linear_page_index().
Gravedad CVSS v3.1: MEDIA
Última modificación:
27/04/2026

CVE-2026-31574

Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clockevents: Add missing resets of the next_event_forced flag<br /> <br /> The prevention mechanism against timer interrupt starvation missed to reset<br /> the next_event_forced flag in a couple of places:<br /> <br /> - When the clock event state changes. That can cause the flag to be<br /> stale over a shutdown/startup sequence<br /> <br /> - When a non-forced event is armed, which then prevents rearming before<br /> that event. If that event is far out in the future this will cause<br /> missed timer interrupts.<br /> <br /> - In the suspend wakeup handler.<br /> <br /> That led to stalls which have been reported by several people.<br /> <br /> Add the missing resets, which fixes the problems for the reporters.
Gravedad CVSS v3.1: MEDIA
Última modificación:
19/05/2026

CVE-2026-31573

Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: verisilicon: Fix kernel panic due to __initconst misuse<br /> <br /> Fix a kernel panic when probing the driver as a module:<br /> <br /> Unable to handle kernel paging request at virtual address<br /> ffffd9c18eb05000<br /> of_find_matching_node_and_match+0x5c/0x1a0<br /> hantro_probe+0x2f4/0x7d0 [hantro_vpu]<br /> <br /> The imx8mq_vpu_shared_resources array is referenced by variant<br /> structures through their shared_devices field. When built as a<br /> module, __initconst causes this data to be freed after module<br /> init, but it&amp;#39;s later accessed during probe, causing a page fault.<br /> <br /> The imx8mq_vpu_shared_resources is referenced from non-init code,<br /> so keeping __initconst or __initconst_or_module here is wrong.<br /> <br /> Drop the __initconst annotation and let it live in the normal .rodata<br /> section.<br /> <br /> A bug of __initconst called from regular non-init probe code<br /> leading to bugs during probe deferrals or during unbind-bind cycles.
Gravedad CVSS v3.1: MEDIA
Última modificación:
27/04/2026

CVE-2026-31566

Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix fence put before wait in amdgpu_amdkfd_submit_ib<br /> <br /> amdgpu_amdkfd_submit_ib() submits a GPU job and gets a fence<br /> from amdgpu_ib_schedule(). This fence is used to wait for job<br /> completion.<br /> <br /> Currently, the code drops the fence reference using dma_fence_put()<br /> before calling dma_fence_wait().<br /> <br /> If dma_fence_put() releases the last reference, the fence may be<br /> freed before dma_fence_wait() is called. This can lead to a<br /> use-after-free.<br /> <br /> Fix this by waiting on the fence first and releasing the reference<br /> only after dma_fence_wait() completes.<br /> <br /> Fixes the below:<br /> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:697 amdgpu_amdkfd_submit_ib() warn: passing freed memory &amp;#39;f&amp;#39; (line 696)<br /> <br /> (cherry picked from commit 8b9e5259adc385b61a6590a13b82ae0ac2bd3482)
Gravedad CVSS v3.1: ALTA
Última modificación:
27/04/2026

CVE-2026-31567

Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM: sleep: Drop spurious WARN_ON() from pm_restore_gfp_mask()<br /> <br /> Commit 35e4a69b2003f ("PM: sleep: Allow pm_restrict_gfp_mask()<br /> stacking") introduced refcount-based GFP mask management that warns<br /> when pm_restore_gfp_mask() is called with saved_gfp_count == 0.<br /> <br /> Some hibernation paths call pm_restore_gfp_mask() defensively where<br /> the GFP mask may or may not be restricted depending on the execution<br /> path. For example, the uswsusp interface invokes it in<br /> SNAPSHOT_CREATE_IMAGE, SNAPSHOT_UNFREEZE, and snapshot_release().<br /> Before the stacking change this was a silent no-op; it now triggers<br /> a spurious WARNING.<br /> <br /> Remove the WARN_ON() wrapper from the !saved_gfp_count check while<br /> retaining the check itself, so that defensive calls remain harmless<br /> without producing false warnings.<br /> <br /> [ rjw: Subject tweak ]
Gravedad CVSS v3.1: MEDIA
Última modificación:
27/04/2026

CVE-2026-31568

Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/mm: Add missing secure storage access fixups for donated memory<br /> <br /> There are special cases where secure storage access exceptions happen<br /> in a kernel context for pages that don&amp;#39;t have the PG_arch_1 bit<br /> set. That bit is set for non-exported guest secure storage (memory)<br /> but is absent on storage donated to the Ultravisor since the kernel<br /> isn&amp;#39;t allowed to export donated pages.<br /> <br /> Prior to this patch we would try to export the page by calling<br /> arch_make_folio_accessible() which would instantly return since the<br /> arch bit is absent signifying that the page was already exported and<br /> no further action is necessary. This leads to secure storage access<br /> exception loops which can never be resolved.<br /> <br /> With this patch we unconditionally try to export and if that fails we<br /> fixup.
Gravedad CVSS v3.1: ALTA
Última modificación:
27/04/2026

CVE-2026-31569

Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: KVM: Handle the case that EIOINTC&amp;#39;s coremap is empty<br /> <br /> EIOINTC&amp;#39;s coremap in eiointc_update_sw_coremap() can be empty, currently<br /> we get a cpuid with -1 in this case, but we actually need 0 because it&amp;#39;s<br /> similar as the case that cpuid &gt;= 4.<br /> <br /> This fix an out-of-bounds access to kvm_arch::phyid_map::phys_map[].
Gravedad CVSS v3.1: ALTA
Última modificación:
27/04/2026

CVE-2026-31570

Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: gw: fix OOB heap access in cgw_csum_crc8_rel()<br /> <br /> cgw_csum_crc8_rel() correctly computes bounds-safe indices via calc_idx():<br /> <br /> int from = calc_idx(crc8-&gt;from_idx, cf-&gt;len);<br /> int to = calc_idx(crc8-&gt;to_idx, cf-&gt;len);<br /> int res = calc_idx(crc8-&gt;result_idx, cf-&gt;len);<br /> <br /> if (from result_idx] = ...; /* BUG: raw negative index */<br /> <br /> With from_idx = to_idx = result_idx = -64 on a 64-byte CAN FD frame,<br /> calc_idx(-64, 64) = 0 so the guard passes, but the loop iterates with<br /> i = -64, reading cf-&gt;data[-64], and the write goes to cf-&gt;data[-64].<br /> This write might end up to 56 (7.0-rc) or 40 (
Gravedad CVSS v3.1: ALTA
Última modificación:
27/04/2026

CVE-2026-31571

Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Unlink NV12 planes earlier<br /> <br /> unlink_nv12_plane() will clobber parts of the plane state<br /> potentially already set up by plane_atomic_check(), so we<br /> must make sure not to call the two in the wrong order.<br /> The problem happens when a plane previously selected as<br /> a Y plane is now configured as a normal plane by user space.<br /> plane_atomic_check() will first compute the proper plane<br /> state based on the userspace request, and unlink_nv12_plane()<br /> later clears some of the state.<br /> <br /> This used to work on account of unlink_nv12_plane() skipping<br /> the state clearing based on the plane visibility. But I removed<br /> that check, thinking it was an impossible situation. Now when<br /> that situation happens unlink_nv12_plane() will just WARN<br /> and proceed to clobber the state.<br /> <br /> Rather than reverting to the old way of doing things, I think<br /> it&amp;#39;s more clear if we unlink the NV12 planes before we even<br /> compute the new plane state.<br /> <br /> (cherry picked from commit 017ecd04985573eeeb0745fa2c23896fb22ee0cc)
Gravedad CVSS v3.1: MEDIA
Última modificación:
27/04/2026

CVE-2026-31572

Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: designware: amdisp: Fix resume-probe race condition issue<br /> <br /> Identified resume-probe race condition in kernel v7.0 with the commit<br /> 38fa29b01a6a ("i2c: designware: Combine the init functions"),but this<br /> issue existed from the beginning though not detected.<br /> <br /> The amdisp i2c device requires ISP to be in power-on state for probe<br /> to succeed. To meet this requirement, this device is added to genpd<br /> to control ISP power using runtime PM. The pm_runtime_get_sync() called<br /> before i2c_dw_probe() triggers PM resume, which powers on ISP and also<br /> invokes the amdisp i2c runtime resume before the probe completes resulting<br /> in this race condition and a NULL dereferencing issue in v7.0<br /> <br /> Fix this race condition by using the genpd APIs directly during probe:<br /> - Call dev_pm_genpd_resume() to Power ON ISP before probe<br /> - Call dev_pm_genpd_suspend() to Power OFF ISP after probe<br /> - Set the device to suspended state with pm_runtime_set_suspended()<br /> - Enable runtime PM only after the device is fully initialized
Gravedad CVSS v3.1: MEDIA
Última modificación:
27/04/2026

CVE-2026-31559

Fecha de publicación:
24/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Fix missing NULL checks for kstrdup()<br /> <br /> 1. Replace "of_find_node_by_path("/")" with "of_root" to avoid multiple<br /> calls to "of_node_put()".<br /> <br /> 2. Fix a potential kernel oops during early boot when memory allocation<br /> fails while parsing CPU model from device tree.
Gravedad CVSS v3.1: MEDIA
Última modificación:
27/04/2026