Vulnerabilities

With the aim of informing, warning and helping professionals with the latest security vulnerabilities in technology systems, we have made a database available for users interested in this information, which is in Spanish and includes all of the latest documented and recognised vulnerabilities.

This repository, with over 75,000 registers, is based on the information from the NVD (National Vulnerability Database) – by virtue of a partnership agreement – through which INCIBE translates the included information into Spanish.

On occasions this list will show vulnerabilities that have still not been translated, as they are added while the INCIBE team is still carrying out the translation process. The CVE  (Common Vulnerabilities and Exposures) Standard for Information Security Vulnerability Names is used with the aim to support the exchange of information between different tools and databases.

All vulnerabilities collected are linked to different information sources, as well as available patches or solutions provided by manufacturers and developers. It is possible to carry out advanced searches, as there is the option to select different criteria to narrow down the results, some examples being vulnerability types, manufacturers and impact levels, among others.

Through RSS feeds or Newsletters we can be informed daily about the latest vulnerabilities added to the repository. Below there is a list, updated daily, where you can discover the latest vulnerabilities.

CVE-2026-31579

Publication date:
24/04/2026
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. ]
Severity CVSS v4.0: Pending analysis
Last modification:
27/04/2026

CVE-2026-31575

Publication date:
24/04/2026
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().
Severity CVSS v4.0: Pending analysis
Last modification:
27/04/2026

CVE-2026-31574

Publication date:
24/04/2026
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.
Severity CVSS v4.0: Pending analysis
Last modification:
19/05/2026

CVE-2026-31573

Publication date:
24/04/2026
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.
Severity CVSS v4.0: Pending analysis
Last modification:
27/04/2026

CVE-2026-31566

Publication date:
24/04/2026
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)
Severity CVSS v4.0: Pending analysis
Last modification:
27/04/2026

CVE-2026-31567

Publication date:
24/04/2026
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 ]
Severity CVSS v4.0: Pending analysis
Last modification:
27/04/2026

CVE-2026-31568

Publication date:
24/04/2026
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.
Severity CVSS v4.0: Pending analysis
Last modification:
27/04/2026

CVE-2026-31569

Publication date:
24/04/2026
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[].
Severity CVSS v4.0: Pending analysis
Last modification:
27/04/2026

CVE-2026-31570

Publication date:
24/04/2026
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 (
Severity CVSS v4.0: Pending analysis
Last modification:
27/04/2026

CVE-2026-31571

Publication date:
24/04/2026
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)
Severity CVSS v4.0: Pending analysis
Last modification:
27/04/2026

CVE-2026-31572

Publication date:
24/04/2026
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
Severity CVSS v4.0: Pending analysis
Last modification:
27/04/2026

CVE-2026-31559

Publication date:
24/04/2026
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.
Severity CVSS v4.0: Pending analysis
Last modification:
27/04/2026