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-53390

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: base: dd: fix memory leak with using debugfs_lookup()<br /> <br /> When calling debugfs_lookup() the result must have dput() called on it,<br /> otherwise the memory will leak over time. To make things simpler, just<br /> call debugfs_lookup_and_remove() instead which handles all of the logic<br /> at once.
Severity CVSS v4.0: Pending analysis
Last modification:
18/09/2025

CVE-2023-53391

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> shmem: use ramfs_kill_sb() for kill_sb method of ramfs-based tmpfs<br /> <br /> As the ramfs-based tmpfs uses ramfs_init_fs_context() for the<br /> init_fs_context method, which allocates fc-&gt;s_fs_info, use ramfs_kill_sb()<br /> to free it and avoid a memory leak.
Severity CVSS v4.0: Pending analysis
Last modification:
18/09/2025

CVE-2023-53392

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: intel-ish-hid: Fix kernel panic during warm reset<br /> <br /> During warm reset device-&gt;fw_client is set to NULL. If a bus driver is<br /> registered after this NULL setting and before new firmware clients are<br /> enumerated by ISHTP, kernel panic will result in the function<br /> ishtp_cl_bus_match(). This is because of reference to<br /> device-&gt;fw_client-&gt;props.protocol_name.<br /> <br /> ISH firmware after getting successfully loaded, sends a warm reset<br /> notification to remove all clients from the bus and sets<br /> device-&gt;fw_client to NULL. Until kernel v5.15, all enabled ISHTP kernel<br /> module drivers were loaded right after any of the first ISHTP device was<br /> registered, regardless of whether it was a matched or an unmatched<br /> device. This resulted in all drivers getting registered much before the<br /> warm reset notification from ISH.<br /> <br /> Starting kernel v5.16, this issue got exposed after the change was<br /> introduced to load only bus drivers for the respective matching devices.<br /> In this scenario, cros_ec_ishtp device and cros_ec_ishtp driver are<br /> registered after the warm reset device fw_client NULL setting.<br /> cros_ec_ishtp driver_register() triggers the callback to<br /> ishtp_cl_bus_match() to match ISHTP driver to the device and causes kernel<br /> panic in guid_equal() when dereferencing fw_client NULL pointer to get<br /> protocol_name.
Severity CVSS v4.0: Pending analysis
Last modification:
18/09/2025

CVE-2023-53393

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix mlx5_ib_get_hw_stats when used for device<br /> <br /> Currently, when mlx5_ib_get_hw_stats() is used for device (port_num = 0),<br /> there is a special handling in order to use the correct counters, but,<br /> port_num is being passed down the stack without any change. Also, some<br /> functions assume that port_num &gt;=1. As a result, the following oops can<br /> occur.<br /> <br /> BUG: unable to handle page fault for address: ffff89510294f1a8<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0002 [#1] SMP<br /> CPU: 8 PID: 1382 Comm: devlink Tainted: G W 6.1.0-rc4_for_upstream_base_2022_11_10_16_12 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:_raw_spin_lock+0xc/0x20<br /> Call Trace:<br /> <br /> mlx5_ib_get_native_port_mdev+0x73/0xe0 [mlx5_ib]<br /> do_get_hw_stats.constprop.0+0x109/0x160 [mlx5_ib]<br /> mlx5_ib_get_hw_stats+0xad/0x180 [mlx5_ib]<br /> ib_setup_device_attrs+0xf0/0x290 [ib_core]<br /> ib_register_device+0x3bb/0x510 [ib_core]<br /> ? atomic_notifier_chain_register+0x67/0x80<br /> __mlx5_ib_add+0x2b/0x80 [mlx5_ib]<br /> mlx5r_probe+0xb8/0x150 [mlx5_ib]<br /> ? auxiliary_match_id+0x6a/0x90<br /> auxiliary_bus_probe+0x3c/0x70<br /> ? driver_sysfs_add+0x6b/0x90<br /> really_probe+0xcd/0x380<br /> __driver_probe_device+0x80/0x170<br /> driver_probe_device+0x1e/0x90<br /> __device_attach_driver+0x7d/0x100<br /> ? driver_allows_async_probing+0x60/0x60<br /> ? driver_allows_async_probing+0x60/0x60<br /> bus_for_each_drv+0x7b/0xc0<br /> __device_attach+0xbc/0x200<br /> bus_probe_device+0x87/0xa0<br /> device_add+0x404/0x940<br /> ? dev_set_name+0x53/0x70<br /> __auxiliary_device_add+0x43/0x60<br /> add_adev+0x99/0xe0 [mlx5_core]<br /> mlx5_attach_device+0xc8/0x120 [mlx5_core]<br /> mlx5_load_one_devl_locked+0xb2/0xe0 [mlx5_core]<br /> devlink_reload+0x133/0x250<br /> devlink_nl_cmd_reload+0x480/0x570<br /> ? devlink_nl_pre_doit+0x44/0x2b0<br /> genl_family_rcv_msg_doit.isra.0+0xc2/0x110<br /> genl_rcv_msg+0x180/0x2b0<br /> ? devlink_nl_cmd_region_read_dumpit+0x540/0x540<br /> ? devlink_reload+0x250/0x250<br /> ? devlink_put+0x50/0x50<br /> ? genl_family_rcv_msg_doit.isra.0+0x110/0x110<br /> netlink_rcv_skb+0x54/0x100<br /> genl_rcv+0x24/0x40<br /> netlink_unicast+0x1f6/0x2c0<br /> netlink_sendmsg+0x237/0x490<br /> sock_sendmsg+0x33/0x40<br /> __sys_sendto+0x103/0x160<br /> ? handle_mm_fault+0x10e/0x290<br /> ? do_user_addr_fault+0x1c0/0x5f0<br /> __x64_sys_sendto+0x25/0x30<br /> do_syscall_64+0x3d/0x90<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Fix it by setting port_num to 1 in order to get device status and remove<br /> unused variable.
Severity CVSS v4.0: Pending analysis
Last modification:
18/09/2025

CVE-2023-53394

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: xsk: Fix crash on regular rq reactivation<br /> <br /> When the regular rq is reactivated after the XSK socket is closed<br /> it could be reading stale cqes which eventually corrupts the rq.<br /> This leads to no more traffic being received on the regular rq and a<br /> crash on the next close or deactivation of the rq.<br /> <br /> Kal Cuttler Conely reported this issue as a crash on the release<br /> path when the xdpsock sample program is stopped (killed) and restarted<br /> in sequence while traffic is running.<br /> <br /> This patch flushes all cqes when during the rq flush. The cqe flushing<br /> is done in the reset state of the rq. mlx5e_rq_to_ready code is moved<br /> into the flush function to allow for this.
Severity CVSS v4.0: Pending analysis
Last modification:
18/09/2025

CVE-2023-53395

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPICA: Add AML_NO_OPERAND_RESOLVE flag to Timer<br /> <br /> ACPICA commit 90310989a0790032f5a0140741ff09b545af4bc5<br /> <br /> According to the ACPI specification 19.6.134, no argument is required to be passed for ASL Timer instruction. For taking care of no argument, AML_NO_OPERAND_RESOLVE flag is added to ASL Timer instruction opcode.<br /> <br /> When ASL timer instruction interpreted by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is not observed.<br /> <br /> =============================================================<br /> UBSAN: array-index-out-of-bounds in acpica/dswexec.c:401:12 index -1 is out of range for type &amp;#39;union acpi_operand_object *[9]&amp;#39;<br /> CPU: 37 PID: 1678 Comm: cat Not tainted<br /> 6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64k<br /> HW name: NVIDIA BIOS v1.1.1-d7acbfc-dirty 12/19/2022 Call trace:<br /> dump_backtrace+0xe0/0x130<br /> show_stack+0x20/0x60<br /> dump_stack_lvl+0x68/0x84<br /> dump_stack+0x18/0x34<br /> ubsan_epilogue+0x10/0x50<br /> __ubsan_handle_out_of_bounds+0x80/0x90<br /> acpi_ds_exec_end_op+0x1bc/0x6d8<br /> acpi_ps_parse_loop+0x57c/0x618<br /> acpi_ps_parse_aml+0x1e0/0x4b4<br /> acpi_ps_execute_method+0x24c/0x2b8<br /> acpi_ns_evaluate+0x3a8/0x4bc<br /> acpi_evaluate_object+0x15c/0x37c<br /> acpi_evaluate_integer+0x54/0x15c<br /> show_power+0x8c/0x12c [acpi_power_meter]
Severity CVSS v4.0: Pending analysis
Last modification:
18/09/2025

CVE-2023-53396

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubifs: Fix memory leak in do_rename<br /> <br /> If renaming a file in an encrypted directory, function<br /> fscrypt_setup_filename allocates memory for a file name. This name is<br /> never used, and before returning to the caller the memory for it is not<br /> freed.<br /> <br /> When running kmemleak on it we see that it is registered as a leak. The<br /> report below is triggered by a simple program &amp;#39;rename&amp;#39; that renames a<br /> file in an encrypted directory:<br /> <br /> unreferenced object 0xffff888101502840 (size 32):<br /> comm "rename", pid 9404, jiffies 4302582475 (age 435.735s)<br /> backtrace:<br /> __kmem_cache_alloc_node<br /> __kmalloc<br /> fscrypt_setup_filename<br /> do_rename<br /> ubifs_rename<br /> vfs_rename<br /> do_renameat2<br /> <br /> To fix this we can remove the call to fscrypt_setup_filename as it&amp;#39;s not<br /> needed.
Severity CVSS v4.0: Pending analysis
Last modification:
18/09/2025

CVE-2023-53397

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> modpost: fix off by one in is_executable_section()<br /> <br /> The &gt; comparison should be &gt;= to prevent an out of bounds array<br /> access.
Severity CVSS v4.0: Pending analysis
Last modification:
18/09/2025

CVE-2023-53381

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: fix leaked reference count of nfsd4_ssc_umount_item<br /> <br /> The reference count of nfsd4_ssc_umount_item is not decremented<br /> on error conditions. This prevents the laundromat from unmounting<br /> the vfsmount of the source file.<br /> <br /> This patch decrements the reference count of nfsd4_ssc_umount_item<br /> on error.
Severity CVSS v4.0: Pending analysis
Last modification:
18/09/2025

CVE-2023-53382

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: Reset connection when trying to use SMCRv2 fails.<br /> <br /> We found a crash when using SMCRv2 with 2 Mellanox ConnectX-4. It<br /> can be reproduced by:<br /> <br /> - smc_run nginx<br /> - smc_run wrk -t 32 -c 500 -d 30 http://:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000014<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 4 PID: 2441 Comm: kworker/4:249 Kdump: loaded Tainted: G W E 6.4.0-rc1+ #42<br /> Workqueue: smc_hs_wq smc_listen_work [smc]<br /> RIP: 0010:smc_clc_send_confirm_accept+0x284/0x580 [smc]<br /> RSP: 0018:ffffb8294b2d7c78 EFLAGS: 00010a06<br /> RAX: ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000<br /> RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00<br /> RBP: ffffb8294b2d7db8 R08: ffff8f1815c5860c R09: 0000000000000000<br /> R10: 0000000000000400 R11: 0000000000000000 R12: ffff8f1846f56180<br /> R13: ffff8f1815c5860c R14: 0000000000000001 R15: 0000000000000001<br /> FS: 0000000000000000(0000) GS:ffff8f1aefd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000014 CR3: 00000001027a0001 CR4: 00000000003706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? mlx5_ib_map_mr_sg+0xa1/0xd0 [mlx5_ib]<br /> ? smcr_buf_map_link+0x24b/0x290 [smc]<br /> ? __smc_buf_create+0x4ee/0x9b0 [smc]<br /> smc_clc_send_accept+0x4c/0xb0 [smc]<br /> smc_listen_work+0x346/0x650 [smc]<br /> ? __schedule+0x279/0x820<br /> process_one_work+0x1e5/0x3f0<br /> worker_thread+0x4d/0x2f0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xe5/0x120<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2c/0x50<br /> <br /> <br /> During the CLC handshake, server sequentially tries available SMCRv2<br /> and SMCRv1 devices in smc_listen_work().<br /> <br /> If an SMCRv2 device is found. SMCv2 based link group and link will be<br /> assigned to the connection. Then assumed that some buffer assignment<br /> errors happen later in the CLC handshake, such as RMB registration<br /> failure, server will give up SMCRv2 and try SMCRv1 device instead. But<br /> the resources assigned to the connection won&amp;#39;t be reset.<br /> <br /> When server tries SMCRv1 device, the connection creation process will<br /> be executed again. Since conn-&gt;lnk has been assigned when trying SMCRv2,<br /> it will not be set to the correct SMCRv1 link in<br /> smcr_lgr_conn_assign_link(). So in such situation, conn-&gt;lgr points to<br /> correct SMCRv1 link group but conn-&gt;lnk points to the SMCRv2 link<br /> mistakenly.<br /> <br /> Then in smc_clc_send_confirm_accept(), conn-&gt;rmb_desc-&gt;mr[link-&gt;link_idx]<br /> will be accessed. Since the link-&gt;link_idx is not correct, the related<br /> MR may not have been initialized, so crash happens.<br /> <br /> | Try SMCRv2 device first<br /> | |-&gt; conn-&gt;lgr: assign existed SMCRv2 link group;<br /> | |-&gt; conn-&gt;link: assign existed SMCRv2 link (link_idx may be 1 in SMC_LGR_SYMMETRIC);<br /> | |-&gt; sndbuf &amp; RMB creation fails, quit;<br /> |<br /> | Try SMCRv1 device then<br /> | |-&gt; conn-&gt;lgr: create SMCRv1 link group and assign;<br /> | |-&gt; conn-&gt;link: keep SMCRv2 link mistakenly;<br /> | |-&gt; sndbuf &amp; RMB creation succeed, only RMB-&gt;mr[link_idx = 0]<br /> | initialized.<br /> |<br /> | Then smc_clc_send_confirm_accept() accesses<br /> | conn-&gt;rmb_desc-&gt;mr[conn-&gt;link-&gt;link_idx, which is 1], then crash.<br /> v<br /> <br /> This patch tries to fix this by cleaning conn-&gt;lnk before assigning<br /> link. In addition, it is better to reset the connection and clean the<br /> resources assigned if trying SMCRv2 failed in buffer creation or<br /> registration.
Severity CVSS v4.0: Pending analysis
Last modification:
18/09/2025

CVE-2023-53383

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/gicv3: Workaround for NVIDIA erratum T241-FABRIC-4<br /> <br /> The T241 platform suffers from the T241-FABRIC-4 erratum which causes<br /> unexpected behavior in the GIC when multiple transactions are received<br /> simultaneously from different sources. This hardware issue impacts<br /> NVIDIA server platforms that use more than two T241 chips<br /> interconnected. Each chip has support for 320 {E}SPIs.<br /> <br /> This issue occurs when multiple packets from different GICs are<br /> incorrectly interleaved at the target chip. The erratum text below<br /> specifies exactly what can cause multiple transfer packets susceptible<br /> to interleaving and GIC state corruption. GIC state corruption can<br /> lead to a range of problems, including kernel panics, and unexpected<br /> behavior.<br /> <br /> &gt;From the erratum text:<br /> "In some cases, inter-socket AXI4 Stream packets with multiple<br /> transfers, may be interleaved by the fabric when presented to ARM<br /> Generic Interrupt Controller. GIC expects all transfers of a packet<br /> to be delivered without any interleaving.<br /> <br /> The following GICv3 commands may result in multiple transfer packets<br /> over inter-socket AXI4 Stream interface:<br /> - Register reads from GICD_I* and GICD_N*<br /> - Register writes to 64-bit GICD registers other than GICD_IROUTERn*<br /> - ITS command MOVALL<br /> <br /> Multiple commands in GICv4+ utilize multiple transfer packets,<br /> including VMOVP, VMOVI, VMAPP, and 64-bit register accesses."<br /> <br /> This issue impacts system configurations with more than 2 sockets,<br /> that require multi-transfer packets to be sent over inter-socket<br /> AXI4 Stream interface between GIC instances on different sockets.<br /> GICv4 cannot be supported. GICv3 SW model can only be supported<br /> with the workaround. Single and Dual socket configurations are not<br /> impacted by this issue and support GICv3 and GICv4."<br /> <br /> <br /> Writing to the chip alias region of the GICD_In{E} registers except<br /> GICD_ICENABLERn has an equivalent effect as writing to the global<br /> distributor. The SPI interrupt deactivate path is not impacted by<br /> the erratum.<br /> <br /> To fix this problem, implement a workaround that ensures read accesses<br /> to the GICD_In{E} registers are directed to the chip that owns the<br /> SPI, and disable GICv4.x features. To simplify code changes, the<br /> gic_configure_irq() function uses the same alias region for both read<br /> and write operations to GICD_ICFGR.
Severity CVSS v4.0: Pending analysis
Last modification:
18/09/2025

CVE-2023-53384

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mwifiex: avoid possible NULL skb pointer dereference<br /> <br /> In &amp;#39;mwifiex_handle_uap_rx_forward()&amp;#39;, always check the value<br /> returned by &amp;#39;skb_copy()&amp;#39; to avoid potential NULL pointer<br /> dereference in &amp;#39;mwifiex_uap_queue_bridged_pkt()&amp;#39;, and drop<br /> original skb in case of copying failure.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.
Severity CVSS v4.0: Pending analysis
Last modification:
18/09/2025