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

Go to Calendar     Go to Press Room     Go to Newsletters subscription

Search

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-64313
Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ecc - Fix carry overflow in vli multiplication<br /> <br /> The carry flag calculation fails when r01.m_high is saturated<br /> (0xFFFFFFFFFFFFFFFF) and addition of lower bits overflows.<br /> <br /> The condition (r01.m_high
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026

CVE-2026-64314
Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: chacha20poly1305 - validate poly1305 template argument<br /> <br /> chachapoly_create() still accepts the compatibility poly1305 parameter<br /> in the template name, but it assumes the second template argument is<br /> always present and immediately passes it to strcmp().<br /> <br /> When the argument is missing, crypto_attr_alg_name() returns an error<br /> pointer. Check for that before comparing the name so malformed template<br /> instantiations fail with an error instead of dereferencing the error<br /> pointer in strcmp().<br /> <br /> This matches the surrounding Crypto API template pattern where<br /> crypto_attr_alg_name() results are validated before string-specific use.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026

CVE-2026-64315
Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: caam - use print_hex_dump_devel to guard key hex dumps<br /> <br /> Use print_hex_dump_devel() for dumping sensitive key material in<br /> *_setkey() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG<br /> is enabled.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026

CVE-2026-64316
Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: caam - use print_hex_dump_devel to guard key hex dumps<br /> <br /> Use print_hex_dump_devel() for dumping sensitive key material in<br /> *_setkey() and gen_split_key() to avoid leaking secrets at runtime when<br /> CONFIG_DYNAMIC_DEBUG is enabled.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026

CVE-2026-64301
Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: scmi: fix of_node refcount leak in scmi_regulator_probe()<br /> <br /> scmi_regulator_probe() calls of_find_node_by_name() which takes a<br /> reference on the returned device node. On the error path where<br /> process_scmi_regulator_of_node() fails, the function returns without<br /> calling of_node_put() on the child node, leaking the reference.<br /> <br /> Add of_node_put(np) on the error path to properly release the<br /> reference.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026

CVE-2026-64302
Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mm: Fix freeing of PMD-sized vmemmap pages<br /> <br /> Commit bf9e4e30f353 ("x86/mm: use pagetable_free()"), switched from<br /> freeing non-boot page tables through __free_pages() to<br /> pagetable_free().<br /> <br /> However, the function is also called to free vmemmap pages.<br /> <br /> Given that vmemmap pages are not page tables, already the page_ptdesc(page)<br /> is wrong. But worse, pagetable_free() calls:<br /> <br /> __free_pages(page, compound_order(page));<br /> <br /> Since vmemmap pages are not compound pages (see vmemmap_alloc_block())<br /> -- except for HVO, which doesn&amp;#39;t apply here -- only first page of a<br /> PMD-sized vmemmap page is freed, leaking the other ones.<br /> <br /> Fix it by properly decoupling pagetable and vmemmap freeing.<br /> free_pagetable() no longer has to mess with SECTION_INFO, as only the<br /> vmemmap is marked like that in register_page_bootmem_memmap().<br /> <br /> The indentation in remove_pmd_table() is messed up. Fix that while<br /> touching it.<br /> <br /> Bootmem info handling will soon be fixed up. For now, handle it<br /> similar to free_pagetable(), just avoiding the ifdef.<br /> <br /> [ dhansen: changelog munging. More imperative voice ]
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026

CVE-2026-64303
Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: fsl-lpspi: terminate the RX channel on TX prepare failure path<br /> <br /> When dmaengine_prep_slave_sg() fails for the TX channel, the error path<br /> terminates the TX DMA channel but leaves the RX channel running. Since<br /> the RX channel was already submitted and issued prior to preparing<br /> the TX descriptor, returning -EINVAL causes the SPI core to unmap the<br /> DMA buffers while the RX DMA engine continues writing to them, leading<br /> to potential memory corruption or use-after-free.<br /> <br /> Terminate the RX channel before returning on the TX prepare failure path.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026

CVE-2026-64304
Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qat - validate RSA CRT component lengths<br /> <br /> The generic RSA key parser (rsa_helper.c) bounds each CRT component (p,<br /> q, dp, dq, qinv) by the modulus size n_sz, but qat_rsa_setkey_crt()<br /> allocates half-size DMA buffers (key_sz / 2) and right-aligns each<br /> component with:<br /> <br /> memcpy(dst + half_key_sz - len, src, len)<br /> <br /> When a CRT component is larger than half_key_sz the subtraction<br /> underflows and memcpy writes past the DMA buffer, causing memory<br /> corruption.<br /> <br /> Add a len &gt; half_key_sz check next to the existing !len check for each<br /> of the five CRT components so the driver falls back to the non-CRT path<br /> instead of writing out of bounds.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026

CVE-2026-64305
Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qat - protect service table iterations with service_lock<br /> <br /> The service_table list is protected by service_lock when entries are<br /> added or removed (in adf_service_add() and adf_service_remove()), but<br /> several functions iterate over the list without holding this lock.<br /> <br /> A concurrent adf_service_register() or adf_service_unregister() call<br /> could modify the list during traversal, leading to list corruption or<br /> a use-after-free.<br /> <br /> Fix this by holding service_lock across all list_for_each_entry()<br /> iterations of service_table in adf_dev_init(), adf_dev_start(),<br /> adf_dev_stop(), adf_dev_shutdown(), adf_dev_restarting_notify(),<br /> adf_dev_restarted_notify(), and adf_error_notifier().<br /> <br /> The lock ordering is safe: callers of the static helpers (adf_dev_up()<br /> and adf_dev_down()) acquire state_lock before service_lock, and no<br /> event_hld callback or service_lock holder ever acquires state_lock in<br /> the reverse order.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026

CVE-2026-64306
Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: drbg - Fix returning success on failure in CTR_DRBG<br /> <br /> drbg_ctr_generate() sometimes returns success when it fails, leaving the<br /> output buffer uninitialized. Fix it.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026

CVE-2026-64307
Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccp - Do not initialize SNP for ioctl(SNP_CONFIG)<br /> <br /> Sashiko notes:<br /> <br /> &gt; if SEV initialization fails and KVM is actively running normal VMs, could a<br /> &gt; userspace process trigger this code path via /dev/sev ioctls (e.g.,<br /> &gt; SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN<br /> &gt; execution for an active VM trigger a general protection fault and crash the<br /> &gt; host?<br /> <br /> Refuse to re-try initialization if SNP is not already initialized for<br /> SNP_CONFIG.<br /> <br /> This is technically an ABI break: before if SNP initialization failed it<br /> could be transparently retriggered by this ioctl, and if no VMs were<br /> running, everything worked fine. Hopefully this is enough of a corner case<br /> that nobody will notice, but someone does, there are a few options:<br /> <br /> * do something like symbol_get() for kvm and refuse to initialize if KVM is<br /> loaded<br /> * check each cpu&amp;#39;s HSAVE_PA for non-zero data before re-initializing<br /> * once initialization has failed, continue to refuse to initialize until<br /> the ccp module is unloaded
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026

CVE-2026-64308
Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccp - Do not initialize SNP for ioctl(SNP_VLEK_LOAD)<br /> <br /> Sashiko notes:<br /> <br /> &gt; if SEV initialization fails and KVM is actively running normal VMs, could a<br /> &gt; userspace process trigger this code path via /dev/sev ioctls (e.g.,<br /> &gt; SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN<br /> &gt; execution for an active VM trigger a general protection fault and crash the<br /> &gt; host?<br /> <br /> The SEV firmware docs for SNP_VLEK_LOAD note:<br /> <br /> &gt; On SNP_SHUTDOWN, the VLEK is deleted.<br /> <br /> That is, the initialization/shutdown wrapper here is pointless, because the<br /> firmware immediately throws away the key anyway. Instead, refuse to do<br /> anything if SNP has not been previously initialized.<br /> <br /> This is an ABI break: before, this was a no-op and almost certainly a<br /> mistake by userspace, and now it returns -ENODEV. ABI compatibility could be<br /> maintained here by simply returning 0 in the check instead.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026
Subscribe to Vulnerabilities