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-2023-53439

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: skb_partial_csum_set() fix against transport header magic value<br /> <br /> skb-&gt;transport_header uses the special 0xFFFF value<br /> to mark if the transport header was set or not.<br /> <br /> We must prevent callers to accidentaly set skb-&gt;transport_header<br /> to 0xFFFF. Note that only fuzzers can possibly do this today.<br /> <br /> syzbot reported:<br /> <br /> WARNING: CPU: 0 PID: 2340 at include/linux/skbuff.h:2847 skb_transport_offset include/linux/skbuff.h:2956 [inline]<br /> WARNING: CPU: 0 PID: 2340 at include/linux/skbuff.h:2847 virtio_net_hdr_to_skb+0xbcc/0x10c0 include/linux/virtio_net.h:103<br /> Modules linked in:<br /> CPU: 0 PID: 2340 Comm: syz-executor.0 Not tainted 6.3.0-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023<br /> RIP: 0010:skb_transport_header include/linux/skbuff.h:2847 [inline]<br /> RIP: 0010:skb_transport_offset include/linux/skbuff.h:2956 [inline]<br /> RIP: 0010:virtio_net_hdr_to_skb+0xbcc/0x10c0 include/linux/virtio_net.h:103<br /> Code: 41 39 df 0f 82 c3 04 00 00 48 8b 7c 24 10 44 89 e6 e8 08 6e 59 ff 48 85 c0 74 54 e8 ce 36 7e fc e9 37 f8 ff ff e8 c4 36 7e fc 0b e9 93 f8 ff ff 44 89 f7 44 89 e6 e8 32 38 7e fc 45 39 e6 0f<br /> RSP: 0018:ffffc90004497880 EFLAGS: 00010293<br /> RAX: ffffffff84fea55c RBX: 000000000000ffff RCX: ffff888120be2100<br /> RDX: 0000000000000000 RSI: 000000000000ffff RDI: 000000000000ffff<br /> RBP: ffffc90004497990 R08: ffffffff84fe9de5 R09: 0000000000000034<br /> R10: ffffea00048ebd80 R11: 0000000000000034 R12: ffff88811dc2d9c8<br /> R13: dffffc0000000000 R14: ffff88811dc2d9ae R15: 1ffff11023b85b35<br /> FS: 00007f9211a59700(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000200002c0 CR3: 00000001215a5000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> packet_snd net/packet/af_packet.c:3076 [inline]<br /> packet_sendmsg+0x4590/0x61a0 net/packet/af_packet.c:3115<br /> sock_sendmsg_nosec net/socket.c:724 [inline]<br /> sock_sendmsg net/socket.c:747 [inline]<br /> __sys_sendto+0x472/0x630 net/socket.c:2144<br /> __do_sys_sendto net/socket.c:2156 [inline]<br /> __se_sys_sendto net/socket.c:2152 [inline]<br /> __x64_sys_sendto+0xe5/0x100 net/socket.c:2152<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7f9210c8c169<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f9211a59168 EFLAGS: 00000246 ORIG_RAX: 000000000000002c<br /> RAX: ffffffffffffffda RBX: 00007f9210dabf80 RCX: 00007f9210c8c169<br /> RDX: 000000000000ffed RSI: 00000000200000c0 RDI: 0000000000000003<br /> RBP: 00007f9210ce7ca1 R08: 0000000020000540 R09: 0000000000000014<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007ffe135d65cf R14: 00007f9211a59300 R15: 0000000000022000
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53440

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix sysfs interface lifetime<br /> <br /> The current nilfs2 sysfs support has issues with the timing of creation<br /> and deletion of sysfs entries, potentially leading to null pointer<br /> dereferences, use-after-free, and lockdep warnings.<br /> <br /> Some of the sysfs attributes for nilfs2 per-filesystem instance refer to<br /> metadata file "cpfile", "sufile", or "dat", but<br /> nilfs_sysfs_create_device_group that creates those attributes is executed<br /> before the inodes for these metadata files are loaded, and<br /> nilfs_sysfs_delete_device_group which deletes these sysfs entries is<br /> called after releasing their metadata file inodes.<br /> <br /> Therefore, access to some of these sysfs attributes may occur outside of<br /> the lifetime of these metadata files, resulting in inode NULL pointer<br /> dereferences or use-after-free.<br /> <br /> In addition, the call to nilfs_sysfs_create_device_group() is made during<br /> the locking period of the semaphore "ns_sem" of nilfs object, so the<br /> shrinker call caused by the memory allocation for the sysfs entries, may<br /> derive lock dependencies "ns_sem" -&gt; (shrinker) -&gt; "locks acquired in<br /> nilfs_evict_inode()".<br /> <br /> Since nilfs2 may acquire "ns_sem" deep in the call stack holding other<br /> locks via its error handler __nilfs_error(), this causes lockdep to report<br /> circular locking. This is a false positive and no circular locking<br /> actually occurs as no inodes exist yet when<br /> nilfs_sysfs_create_device_group() is called. Fortunately, the lockdep<br /> warnings can be resolved by simply moving the call to<br /> nilfs_sysfs_create_device_group() out of "ns_sem".<br /> <br /> This fixes these sysfs issues by revising where the device&amp;#39;s sysfs<br /> interface is created/deleted and keeping its lifetime within the lifetime<br /> of the metadata files above.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53441

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: cpumap: Fix memory leak in cpu_map_update_elem<br /> <br /> Syzkaller reported a memory leak as follows:<br /> <br /> BUG: memory leak<br /> unreferenced object 0xff110001198ef748 (size 192):<br /> comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 4a 19 00 00 80 ad e3 e4 fe ff c0 00 ....J...........<br /> 00 b2 d3 0c 01 00 11 ff 28 f5 8e 19 01 00 11 ff ........(.......<br /> backtrace:<br /> [] __cpu_map_entry_alloc+0xf7/0xb00<br /> [] cpu_map_update_elem+0x2fe/0x3d0<br /> [] bpf_map_update_value.isra.0+0x2bd/0x520<br /> [] map_update_elem+0x4cb/0x720<br /> [] __se_sys_bpf+0x8c3/0xb90<br /> [] do_syscall_64+0x30/0x40<br /> [] entry_SYSCALL_64_after_hwframe+0x61/0xc6<br /> <br /> BUG: memory leak<br /> unreferenced object 0xff110001198ef528 (size 192):<br /> comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] __cpu_map_entry_alloc+0x260/0xb00<br /> [] cpu_map_update_elem+0x2fe/0x3d0<br /> [] bpf_map_update_value.isra.0+0x2bd/0x520<br /> [] map_update_elem+0x4cb/0x720<br /> [] __se_sys_bpf+0x8c3/0xb90<br /> [] do_syscall_64+0x30/0x40<br /> [] entry_SYSCALL_64_after_hwframe+0x61/0xc6<br /> <br /> BUG: memory leak<br /> unreferenced object 0xff1100010fd93d68 (size 8):<br /> comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)<br /> hex dump (first 8 bytes):<br /> 00 00 00 00 00 00 00 00 ........<br /> backtrace:<br /> [] kvmalloc_node+0x11e/0x170<br /> [] __cpu_map_entry_alloc+0x2f0/0xb00<br /> [] cpu_map_update_elem+0x2fe/0x3d0<br /> [] bpf_map_update_value.isra.0+0x2bd/0x520<br /> [] map_update_elem+0x4cb/0x720<br /> [] __se_sys_bpf+0x8c3/0xb90<br /> [] do_syscall_64+0x30/0x40<br /> [] entry_SYSCALL_64_after_hwframe+0x61/0xc6<br /> <br /> In the cpu_map_update_elem flow, when kthread_stop is called before<br /> calling the threadfn of rcpu-&gt;kthread, since the KTHREAD_SHOULD_STOP bit<br /> of kthread has been set by kthread_stop, the threadfn of rcpu-&gt;kthread<br /> will never be executed, and rcpu-&gt;refcnt will never be 0, which will<br /> lead to the allocated rcpu, rcpu-&gt;queue and rcpu-&gt;queue-&gt;queue cannot be<br /> released.<br /> <br /> Calling kthread_stop before executing kthread&amp;#39;s threadfn will return<br /> -EINTR. We can complete the release of memory resources in this state.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53442

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Block switchdev mode when ADQ is active and vice versa<br /> <br /> ADQ and switchdev are not supported simultaneously. Enabling both at the<br /> same time can result in nullptr dereference.<br /> <br /> To prevent this, check if ADQ is active when changing devlink mode to<br /> switchdev mode, and check if switchdev is active when enabling ADQ.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53443

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mfd: arizona: Use pm_runtime_resume_and_get() to prevent refcnt leak<br /> <br /> In arizona_clk32k_enable(), we should use pm_runtime_resume_and_get()<br /> as pm_runtime_get_sync() will increase the refcnt even when it<br /> returns an error.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53444

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/ttm: fix bulk_move corruption when adding a entry<br /> <br /> When the resource is the first in the bulk_move range, adding it again<br /> (thus moving it to the tail) will corrupt the list since the first<br /> pointer is not moved. This eventually lead to null pointer deref in<br /> ttm_lru_bulk_move_del()
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53445

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: Fix a refcount bug in qrtr_recvmsg()<br /> <br /> Syzbot reported a bug as following:<br /> <br /> refcount_t: addition on 0; use-after-free.<br /> ...<br /> RIP: 0010:refcount_warn_saturate+0x17c/0x1f0 lib/refcount.c:25<br /> ...<br /> Call Trace:<br /> <br /> __refcount_add include/linux/refcount.h:199 [inline]<br /> __refcount_inc include/linux/refcount.h:250 [inline]<br /> refcount_inc include/linux/refcount.h:267 [inline]<br /> kref_get include/linux/kref.h:45 [inline]<br /> qrtr_node_acquire net/qrtr/af_qrtr.c:202 [inline]<br /> qrtr_node_lookup net/qrtr/af_qrtr.c:398 [inline]<br /> qrtr_send_resume_tx net/qrtr/af_qrtr.c:1003 [inline]<br /> qrtr_recvmsg+0x85f/0x990 net/qrtr/af_qrtr.c:1070<br /> sock_recvmsg_nosec net/socket.c:1017 [inline]<br /> sock_recvmsg+0xe2/0x160 net/socket.c:1038<br /> qrtr_ns_worker+0x170/0x1700 net/qrtr/ns.c:688<br /> process_one_work+0x991/0x15c0 kernel/workqueue.c:2390<br /> worker_thread+0x669/0x1090 kernel/workqueue.c:2537<br /> <br /> It occurs in the concurrent scenario of qrtr_recvmsg() and<br /> qrtr_endpoint_unregister() as following:<br /> <br /> cpu0 cpu1<br /> qrtr_recvmsg qrtr_endpoint_unregister<br /> qrtr_send_resume_tx qrtr_node_release<br /> qrtr_node_lookup mutex_lock(&amp;qrtr_node_lock)<br /> spin_lock_irqsave(&amp;qrtr_nodes_lock, ) refcount_dec_and_test(&amp;node-&gt;ref) [node-&gt;ref == 0]<br /> radix_tree_lookup [node != NULL] __qrtr_node_release<br /> qrtr_node_acquire spin_lock_irqsave(&amp;qrtr_nodes_lock, )<br /> kref_get(&amp;node-&gt;ref) [WARNING] ...<br /> mutex_unlock(&amp;qrtr_node_lock)<br /> <br /> Use qrtr_node_lock to protect qrtr_node_lookup() implementation, this<br /> is actually improving the protection of node reference.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53446

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/ASPM: Disable ASPM on MFD function removal to avoid use-after-free<br /> <br /> Struct pcie_link_state-&gt;downstream is a pointer to the pci_dev of function<br /> 0. Previously we retained that pointer when removing function 0, and<br /> subsequent ASPM policy changes dereferenced it, resulting in a<br /> use-after-free warning from KASAN, e.g.:<br /> <br /> # echo 1 &gt; /sys/bus/pci/devices/0000:03:00.0/remove<br /> # echo powersave &gt; /sys/module/pcie_aspm/parameters/policy<br /> <br /> BUG: KASAN: slab-use-after-free in pcie_config_aspm_link+0x42d/0x500<br /> Call Trace:<br /> kasan_report+0xae/0xe0<br /> pcie_config_aspm_link+0x42d/0x500<br /> pcie_aspm_set_policy+0x8e/0x1a0<br /> param_attr_store+0x162/0x2c0<br /> module_attr_store+0x3e/0x80<br /> <br /> PCIe spec r6.0, sec 7.5.3.7, recommends that software program the same ASPM<br /> Control value in all functions of multi-function devices.<br /> <br /> Disable ASPM and free the pcie_link_state when any child function is<br /> removed so we can discard the dangling pcie_link_state-&gt;downstream pointer<br /> and maintain the same ASPM Control configuration for all functions.<br /> <br /> [bhelgaas: commit log and comment]
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53431

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ses: Don&amp;#39;t attach if enclosure has no components<br /> <br /> An enclosure with no components can&amp;#39;t usefully be operated by the driver<br /> (since effectively it has nothing to manage), so report the problem and<br /> don&amp;#39;t attach. Not attaching also fixes an oops which could occur if the<br /> driver tries to manage a zero component enclosure.<br /> <br /> [mkp: Switched to KERN_WARNING since this scenario is common]
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53432

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firewire: net: fix use after free in fwnet_finish_incoming_packet()<br /> <br /> The netif_rx() function frees the skb so we can&amp;#39;t dereference it to<br /> save the skb-&gt;len.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53433

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: add vlan_get_protocol_and_depth() helper<br /> <br /> Before blamed commit, pskb_may_pull() was used instead<br /> of skb_header_pointer() in __vlan_get_protocol() and friends.<br /> <br /> Few callers depended on skb-&gt;head being populated with MAC header,<br /> syzbot caught one of them (skb_mac_gso_segment())<br /> <br /> Add vlan_get_protocol_and_depth() to make the intent clearer<br /> and use it where sensible.<br /> <br /> This is a more generic fix than commit e9d3f80935b6<br /> ("net/af_packet: make sure to pull mac header") which was<br /> dealing with a similar issue.<br /> <br /> kernel BUG at include/linux/skbuff.h:2655 !<br /> invalid opcode: 0000 [#1] SMP KASAN<br /> CPU: 0 PID: 1441 Comm: syz-executor199 Not tainted 6.1.24-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023<br /> RIP: 0010:__skb_pull include/linux/skbuff.h:2655 [inline]<br /> RIP: 0010:skb_mac_gso_segment+0x68f/0x6a0 net/core/gro.c:136<br /> Code: fd 48 8b 5c 24 10 44 89 6b 70 48 c7 c7 c0 ae 0d 86 44 89 e6 e8 a1 91 d0 00 48 c7 c7 00 af 0d 86 48 89 de 31 d2 e8 d1 4a e9 ff 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41<br /> RSP: 0018:ffffc90001bd7520 EFLAGS: 00010286<br /> RAX: ffffffff8469736a RBX: ffff88810f31dac0 RCX: ffff888115a18b00<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffffc90001bd75e8 R08: ffffffff84697183 R09: fffff5200037adf9<br /> R10: 0000000000000000 R11: dffffc0000000001 R12: 0000000000000012<br /> R13: 000000000000fee5 R14: 0000000000005865 R15: 000000000000fed7<br /> FS: 000055555633f300(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020000000 CR3: 0000000116fea000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> [] __skb_gso_segment+0x32d/0x4c0 net/core/dev.c:3419<br /> [] skb_gso_segment include/linux/netdevice.h:4819 [inline]<br /> [] validate_xmit_skb+0x3aa/0xee0 net/core/dev.c:3725<br /> [] __dev_queue_xmit+0x1332/0x3300 net/core/dev.c:4313<br /> [] dev_queue_xmit+0x17/0x20 include/linux/netdevice.h:3029<br /> [] packet_snd net/packet/af_packet.c:3111 [inline]<br /> [] packet_sendmsg+0x49d2/0x6470 net/packet/af_packet.c:3142<br /> [] sock_sendmsg_nosec net/socket.c:716 [inline]<br /> [] sock_sendmsg net/socket.c:736 [inline]<br /> [] __sys_sendto+0x472/0x5f0 net/socket.c:2139<br /> [] __do_sys_sendto net/socket.c:2151 [inline]<br /> [] __se_sys_sendto net/socket.c:2147 [inline]<br /> [] __x64_sys_sendto+0xe5/0x100 net/socket.c:2147<br /> [] do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> [] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53434

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: imx_dsp_rproc: Add custom memory copy implementation for i.MX DSP Cores<br /> <br /> The IRAM is part of the HiFi DSP.<br /> According to hardware specification only 32-bits write are allowed<br /> otherwise we get a Kernel panic.<br /> <br /> Therefore add a custom memory copy and memset functions to deal with<br /> the above restriction.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025