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-53322
Publication date:
26/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/pci: Clean up DMABUFs before disabling function<br /> <br /> On device shutdown, make vfio_pci_core_close_device() call<br /> vfio_pci_dma_buf_cleanup() before the function is disabled via<br /> vfio_pci_core_disable(). This ensures that all access via DMABUFs is<br /> revoked before the function&amp;#39;s BARs become inaccessible.<br /> <br /> This fixes an issue where, if the function is disabled first, a tiny<br /> window exists in which the function&amp;#39;s MSE is cleared and yet BARs<br /> could still be accessed via the DMABUF. The resources would also be<br /> freed and up for grabs by a different driver.
Severity CVSS v4.0: Pending analysis
Last modification:
06/07/2026

CVE-2026-53321
Publication date:
26/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/napi: cap busy_poll_to 10 msec<br /> <br /> Currently there&amp;#39;s no cap on the maximum amount of time that napi is<br /> allowed to poll if no events are found, which can lead to kernel<br /> complaints on a task being stuck as there&amp;#39;s no conditional rescheduling<br /> done within that loop.<br /> <br /> Just cap it to 10 msec in total, that&amp;#39;s already way above any kind of<br /> sane value that will reap any benefits, yet low enough that it&amp;#39;s<br /> nowhere near being able to trigger preemption complaints.
Severity CVSS v4.0: Pending analysis
Last modification:
06/07/2026

CVE-2026-53320
Publication date:
26/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty()<br /> <br /> nilfs_ioctl_mark_blocks_dirty() uses bd_oblocknr to detect dead blocks<br /> by comparing it with the current block number bd_blocknr. If they differ,<br /> the block is considered dead and skipped.<br /> <br /> However, bd_oblocknr should never be 0 since block 0 typically stores the<br /> primary superblock and is never a valid GC target block. A corrupted ioctl<br /> request with bd_oblocknr set to 0 causes the comparison to incorrectly<br /> match when the lookup returns -ENOENT and sets bd_blocknr to 0, bypassing<br /> the dead block check and calling nilfs_bmap_mark() on a non-existent<br /> block. This causes nilfs_btree_do_lookup() to return -ENOENT, triggering<br /> the WARN_ON(ret == -ENOENT).<br /> <br /> Fix this by rejecting ioctl requests with bd_oblocknr set to 0 at the<br /> beginning of each iteration.<br /> <br /> [ryusuke: slightly modified the commit message and comments for accuracy]
Severity CVSS v4.0: Pending analysis
Last modification:
06/07/2026

CVE-2026-53319
Publication date:
26/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-wbt: remove WARN_ON_ONCE from wbt_init_enable_default()<br /> <br /> wbt_init_enable_default() uses WARN_ON_ONCE to check for failures from<br /> wbt_alloc() and wbt_init(). However, both are expected failure paths:<br /> <br /> - wbt_alloc() can return NULL under memory pressure (-ENOMEM)<br /> - wbt_init() can fail with -EBUSY if wbt is already registered<br /> <br /> syzbot triggers this by injecting memory allocation failures during MTD<br /> partition creation via ioctl(BLKPG), causing a spurious warning.<br /> <br /> wbt_init_enable_default() is a best-effort initialization called from<br /> blk_register_queue() with a void return type. Failure simply means the<br /> disk operates without writeback throttling, which is harmless.<br /> <br /> Replace WARN_ON_ONCE with plain if-checks, consistent with how<br /> wbt_set_lat() in the same file already handles these failures. Add a<br /> pr_warn() for the wbt_init() failure to retain diagnostic information<br /> without triggering a full stack trace.
Severity CVSS v4.0: Pending analysis
Last modification:
06/07/2026

CVE-2026-53318
Publication date:
26/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7925: prevent NULL pointer dereference in mt7925_tx_check_aggr()<br /> <br /> Move the NULL check for &amp;#39;sta&amp;#39; before dereferencing it to prevent a<br /> possible crash.
Severity CVSS v4.0: Pending analysis
Last modification:
06/07/2026

CVE-2026-53317
Publication date:
26/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7921: Place upper limit on station AID<br /> <br /> Any station configured with an AID over 20 causes a firmware crash.<br /> This situation occurred in our testing using an AP interface on 7922<br /> hardware, with a modified hostapd, sourced from Mediatek&amp;#39;s OpenWRT<br /> feeds.<br /> <br /> In stock hostapd, station AIDs begin counting at 1, and this<br /> configuration is prevented with an upper limit on associated stations.<br /> However, the modified hostapd began allocation at 65, which caused the<br /> firmware to crash. This fix does not allow these AIDs to work, but will<br /> prevent the firmware crash.<br /> <br /> This crash was only seen on IFTYPE_AP interfaces, and the fix does not<br /> appear to have an effect on IFTYPE_STATION behavior.
Severity CVSS v4.0: Pending analysis
Last modification:
06/07/2026

CVE-2026-53316
Publication date:
26/06/2026
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
Severity CVSS v4.0: Pending analysis
Last modification:
06/07/2026

CVE-2026-53315
Publication date:
26/06/2026
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.
Severity CVSS v4.0: Pending analysis
Last modification:
06/07/2026

CVE-2026-53314
Publication date:
26/06/2026
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.
Severity CVSS v4.0: Pending analysis
Last modification:
06/07/2026

CVE-2026-53313
Publication date:
26/06/2026
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)
Severity CVSS v4.0: Pending analysis
Last modification:
06/07/2026

CVE-2026-53312
Publication date:
26/06/2026
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
Severity CVSS v4.0: Pending analysis
Last modification:
06/07/2026

CVE-2026-53311
Publication date:
26/06/2026
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 /> =====================================================
Severity CVSS v4.0: Pending analysis
Last modification:
06/07/2026
Subscribe to Vulnerabilities