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-2025-71188

Publication date:
31/01/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: lpc18xx-dmamux: fix device leak on route allocation<br /> <br /> Make sure to drop the reference taken when looking up the DMA mux<br /> platform device during route allocation.<br /> <br /> Note that holding a reference to a device does not prevent its driver<br /> data from going away so there is no point in keeping the reference.
Severity CVSS v4.0: Pending analysis
Last modification:
31/01/2026

CVE-2025-71189

Publication date:
31/01/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: dw: dmamux: fix OF node leak on route allocation failure<br /> <br /> Make sure to drop the reference taken to the DMA master OF node also on<br /> late route allocation failures.
Severity CVSS v4.0: Pending analysis
Last modification:
31/01/2026

CVE-2025-71190

Publication date:
31/01/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: bcm-sba-raid: fix device leak on probe<br /> <br /> Make sure to drop the reference taken when looking up the mailbox device<br /> during probe on probe failures and on driver unbind.
Severity CVSS v4.0: Pending analysis
Last modification:
31/01/2026

CVE-2025-71191

Publication date:
31/01/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: at_hdmac: fix device leak on of_dma_xlate()<br /> <br /> Make sure to drop the reference taken when looking up the DMA platform<br /> device during of_dma_xlate() when releasing channel resources.<br /> <br /> Note that commit 3832b78b3ec2 ("dmaengine: at_hdmac: add missing<br /> put_device() call in at_dma_xlate()") fixed the leak in a couple of<br /> error paths but the reference is still leaking on successful allocation.
Severity CVSS v4.0: Pending analysis
Last modification:
31/01/2026

CVE-2026-23015

Publication date:
31/01/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: mpsse: fix reference leak in gpio_mpsse_probe() error paths<br /> <br /> The reference obtained by calling usb_get_dev() is not released in the<br /> gpio_mpsse_probe() error paths. Fix that by using device managed helper<br /> functions. Also remove the usb_put_dev() call in the disconnect function<br /> since now it will be released automatically.
Severity CVSS v4.0: Pending analysis
Last modification:
31/01/2026

CVE-2026-23016

Publication date:
31/01/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> inet: frags: drop fraglist conntrack references<br /> <br /> Jakub added a warning in nf_conntrack_cleanup_net_list() to make debugging<br /> leaked skbs/conntrack references more obvious.<br /> <br /> syzbot reports this as triggering, and I can also reproduce this via<br /> ip_defrag.sh selftest:<br /> <br /> conntrack cleanup blocked for 60s<br /> WARNING: net/netfilter/nf_conntrack_core.c:2512<br /> [..]<br /> <br /> conntrack clenups gets stuck because there are skbs with still hold nf_conn<br /> references via their frag_list.<br /> <br /> net.core.skb_defer_max=0 makes the hang disappear.<br /> <br /> Eric Dumazet points out that skb_release_head_state() doesn&amp;#39;t follow the<br /> fraglist.<br /> <br /> ip_defrag.sh can only reproduce this problem since<br /> commit 6471658dc66c ("udp: use skb_attempt_defer_free()"), but AFAICS this<br /> problem could happen with TCP as well if pmtu discovery is off.<br /> <br /> The relevant problem path for udp is:<br /> 1. netns emits fragmented packets<br /> 2. nf_defrag_v6_hook reassembles them (in output hook)<br /> 3. reassembled skb is tracked (skb owns nf_conn reference)<br /> 4. ip6_output refragments<br /> 5. refragmented packets also own nf_conn reference (ip6_fragment<br /> calls ip6_copy_metadata())<br /> 6. on input path, nf_defrag_v6_hook skips defragmentation: the<br /> fragments already have skb-&gt;nf_conn attached<br /> 7. skbs are reassembled via ipv6_frag_rcv()<br /> 8. skb_consume_udp -&gt; skb_attempt_defer_free() -&gt; skb ends up<br /> in pcpu freelist, but still has nf_conn reference.<br /> <br /> Possible solutions:<br /> 1 let defrag engine drop nf_conn entry, OR<br /> 2 export kick_defer_list_purge() and call it from the conntrack<br /> netns exit callback, OR<br /> 3 add skb_has_frag_list() check to skb_attempt_defer_free()<br /> <br /> 2 &amp; 3 also solve ip_defrag.sh hang but share same drawback:<br /> <br /> Such reassembled skbs, queued to socket, can prevent conntrack module<br /> removal until userspace has consumed the packet. While both tcp and udp<br /> stack do call nf_reset_ct() before placing skb on socket queue, that<br /> function doesn&amp;#39;t iterate frag_list skbs.<br /> <br /> Therefore drop nf_conn entries when they are placed in defrag queue.<br /> Keep the nf_conn entry of the first (offset 0) skb so that reassembled<br /> skb retains nf_conn entry for sake of TX path.<br /> <br /> Note that fixes tag is incorrect; it points to the commit introducing the<br /> &amp;#39;ip_defrag.sh reproducible problem&amp;#39;: no need to backport this patch to<br /> every stable kernel.
Severity CVSS v4.0: Pending analysis
Last modification:
31/01/2026

CVE-2025-71181

Publication date:
31/01/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust_binder: remove spin_lock() in rust_shrink_free_page()<br /> <br /> When forward-porting Rust Binder to 6.18, I neglected to take commit<br /> fb56fdf8b9a2 ("mm/list_lru: split the lock to per-cgroup scope") into<br /> account, and apparently I did not end up running the shrinker callback<br /> when I sanity tested the driver before submission. This leads to crashes<br /> like the following:<br /> <br /> ============================================<br /> WARNING: possible recursive locking detected<br /> 6.18.0-mainline-maybe-dirty #1 Tainted: G IO<br /> --------------------------------------------<br /> kswapd0/68 is trying to acquire lock:<br /> ffff956000fa18b0 (&amp;l-&gt;lock){+.+.}-{2:2}, at: lock_list_lru_of_memcg+0x128/0x230<br /> <br /> but task is already holding lock:<br /> ffff956000fa18b0 (&amp;l-&gt;lock){+.+.}-{2:2}, at: rust_helper_spin_lock+0xd/0x20<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(&amp;l-&gt;lock);<br /> lock(&amp;l-&gt;lock);<br /> <br /> *** DEADLOCK ***<br /> <br /> May be due to missing lock nesting notation<br /> <br /> 3 locks held by kswapd0/68:<br /> #0: ffffffff90d2e260 (fs_reclaim){+.+.}-{0:0}, at: kswapd+0x597/0x1160<br /> #1: ffff956000fa18b0 (&amp;l-&gt;lock){+.+.}-{2:2}, at: rust_helper_spin_lock+0xd/0x20<br /> #2: ffffffff90cf3680 (rcu_read_lock){....}-{1:2}, at: lock_list_lru_of_memcg+0x2d/0x230<br /> <br /> To fix this, remove the spin_lock() call from rust_shrink_free_page().
Severity CVSS v4.0: Pending analysis
Last modification:
31/01/2026

CVE-2025-71182

Publication date:
31/01/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: j1939: make j1939_session_activate() fail if device is no longer registered<br /> <br /> syzbot is still reporting<br /> <br /> unregister_netdevice: waiting for vcan0 to become free. Usage count = 2<br /> <br /> even after commit 93a27b5891b8 ("can: j1939: add missing calls in<br /> NETDEV_UNREGISTER notification handler") was added. A debug printk() patch<br /> found that j1939_session_activate() can succeed even after<br /> j1939_cancel_active_session() from j1939_netdev_notify(NETDEV_UNREGISTER)<br /> has completed.<br /> <br /> Since j1939_cancel_active_session() is processed with the session list lock<br /> held, checking ndev-&gt;reg_state in j1939_session_activate() with the session<br /> list lock held can reliably close the race window.
Severity CVSS v4.0: Pending analysis
Last modification:
31/01/2026

CVE-2025-71183

Publication date:
31/01/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: always detect conflicting inodes when logging inode refs<br /> <br /> After rename exchanging (either with the rename exchange operation or<br /> regular renames in multiple non-atomic steps) two inodes and at least<br /> one of them is a directory, we can end up with a log tree that contains<br /> only of the inodes and after a power failure that can result in an attempt<br /> to delete the other inode when it should not because it was not deleted<br /> before the power failure. In some case that delete attempt fails when<br /> the target inode is a directory that contains a subvolume inside it, since<br /> the log replay code is not prepared to deal with directory entries that<br /> point to root items (only inode items).<br /> <br /> 1) We have directories "dir1" (inode A) and "dir2" (inode B) under the<br /> same parent directory;<br /> <br /> 2) We have a file (inode C) under directory "dir1" (inode A);<br /> <br /> 3) We have a subvolume inside directory "dir2" (inode B);<br /> <br /> 4) All these inodes were persisted in a past transaction and we are<br /> currently at transaction N;<br /> <br /> 5) We rename the file (inode C), so at btrfs_log_new_name() we update<br /> inode C&amp;#39;s last_unlink_trans to N;<br /> <br /> 6) We get a rename exchange for "dir1" (inode A) and "dir2" (inode B),<br /> so after the exchange "dir1" is inode B and "dir2" is inode A.<br /> During the rename exchange we call btrfs_log_new_name() for inodes<br /> A and B, but because they are directories, we don&amp;#39;t update their<br /> last_unlink_trans to N;<br /> <br /> 7) An fsync against the file (inode C) is done, and because its inode<br /> has a last_unlink_trans with a value of N we log its parent directory<br /> (inode A) (through btrfs_log_all_parents(), called from<br /> btrfs_log_inode_parent()).<br /> <br /> 8) So we end up with inode B not logged, which now has the old name<br /> of inode A. At copy_inode_items_to_log(), when logging inode A, we<br /> did not check if we had any conflicting inode to log because inode<br /> A has a generation lower than the current transaction (created in<br /> a past transaction);<br /> <br /> 9) After a power failure, when replaying the log tree, since we find that<br /> inode A has a new name that conflicts with the name of inode B in the<br /> fs tree, we attempt to delete inode B... this is wrong since that<br /> directory was never deleted before the power failure, and because there<br /> is a subvolume inside that directory, attempting to delete it will fail<br /> since replay_dir_deletes() and btrfs_unlink_inode() are not prepared<br /> to deal with dir items that point to roots instead of inodes.<br /> <br /> When that happens the mount fails and we get a stack trace like the<br /> following:<br /> <br /> [87.2314] BTRFS info (device dm-0): start tree-log replay<br /> [87.2318] BTRFS critical (device dm-0): failed to delete reference to subvol, root 5 inode 256 parent 259<br /> [87.2332] ------------[ cut here ]------------<br /> [87.2338] BTRFS: Transaction aborted (error -2)<br /> [87.2346] WARNING: CPU: 1 PID: 638968 at fs/btrfs/inode.c:4345 __btrfs_unlink_inode+0x416/0x440 [btrfs]<br /> [87.2368] Modules linked in: btrfs loop dm_thin_pool (...)<br /> [87.2470] CPU: 1 UID: 0 PID: 638968 Comm: mount Tainted: G W 6.18.0-rc7-btrfs-next-218+ #2 PREEMPT(full)<br /> [87.2489] Tainted: [W]=WARN<br /> [87.2494] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014<br /> [87.2514] RIP: 0010:__btrfs_unlink_inode+0x416/0x440 [btrfs]<br /> [87.2538] Code: c0 89 04 24 (...)<br /> [87.2568] RSP: 0018:ffffc0e741f4b9b8 EFLAGS: 00010286<br /> [87.2574] RAX: 0000000000000000 RBX: ffff9d3ec8a6cf60 RCX: 0000000000000000<br /> [87.2582] RDX: 0000000000000002 RSI: ffffffff84ab45a1 RDI: 00000000ffffffff<br /> [87.2591] RBP: ffff9d3ec8a6ef20 R08: 0000000000000000 R09: ffffc0e741f4b840<br /> [87.2599] R10: ffff9d45dc1fffa8 R11: 0000000000000003 R12: ffff9d3ee26d77e0<br /> [87.2608] R13: ffffc0e741f4ba98 R14: ffff9d4458040800 R15: ffff9d44b6b7ca10<br /> [87.2618] FS: 00007f7b9603a840(0000) GS:ffff9d4658982000(0000) knlGS:0000000000000000<br /> [87.<br /> ---truncated---
Severity CVSS v4.0: Pending analysis
Last modification:
31/01/2026

CVE-2025-71184

Publication date:
31/01/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix NULL dereference on root when tracing inode eviction<br /> <br /> When evicting an inode the first thing we do is to setup tracing for it,<br /> which implies fetching the root&amp;#39;s id. But in btrfs_evict_inode() the<br /> root might be NULL, as implied in the next check that we do in<br /> btrfs_evict_inode().<br /> <br /> Hence, we either should set the -&gt;root_objectid to 0 in case the root is<br /> NULL, or we move tracing setup after checking that the root is not<br /> NULL. Setting the rootid to 0 at least gives us the possibility to trace<br /> this call even in the case when the root is NULL, so that&amp;#39;s the solution<br /> taken here.
Severity CVSS v4.0: Pending analysis
Last modification:
31/01/2026

CVE-2025-71185

Publication date:
31/01/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation<br /> <br /> Make sure to drop the reference taken when looking up the crossbar<br /> platform device during am335x route allocation.
Severity CVSS v4.0: Pending analysis
Last modification:
31/01/2026

CVE-2025-71186

Publication date:
31/01/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: stm32: dmamux: fix device leak on route allocation<br /> <br /> Make sure to drop the reference taken when looking up the DMA mux<br /> platform device during route allocation.<br /> <br /> Note that holding a reference to a device does not prevent its driver<br /> data from going away so there is no point in keeping the reference.
Severity CVSS v4.0: Pending analysis
Last modification:
31/01/2026