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

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix NULL pointer dereference in smb2_get_info_filesystem()<br /> <br /> If share is , share-&gt;path is NULL and it cause NULL pointer<br /> dereference issue.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53400

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: hda: Fix Oops by 9.1 surround channel names<br /> <br /> get_line_out_pfx() may trigger an Oops by overflowing the static array<br /> with more than 8 channels. This was reported for MacBookPro 12,1 with<br /> Cirrus codec.<br /> <br /> As a workaround, extend for the 9.1 channels and also fix the<br /> potential Oops by unifying the code paths accessing the same array<br /> with the proper size check.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53401

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: kmem: fix a NULL pointer dereference in obj_stock_flush_required()<br /> <br /> KCSAN found an issue in obj_stock_flush_required():<br /> stock-&gt;cached_objcg can be reset between the check and dereference:<br /> <br /> ==================================================================<br /> BUG: KCSAN: data-race in drain_all_stock / drain_obj_stock<br /> <br /> write to 0xffff888237c2a2f8 of 8 bytes by task 19625 on cpu 0:<br /> drain_obj_stock+0x408/0x4e0 mm/memcontrol.c:3306<br /> refill_obj_stock+0x9c/0x1e0 mm/memcontrol.c:3340<br /> obj_cgroup_uncharge+0xe/0x10 mm/memcontrol.c:3408<br /> memcg_slab_free_hook mm/slab.h:587 [inline]<br /> __cache_free mm/slab.c:3373 [inline]<br /> __do_kmem_cache_free mm/slab.c:3577 [inline]<br /> kmem_cache_free+0x105/0x280 mm/slab.c:3602<br /> __d_free fs/dcache.c:298 [inline]<br /> dentry_free fs/dcache.c:375 [inline]<br /> __dentry_kill+0x422/0x4a0 fs/dcache.c:621<br /> dentry_kill+0x8d/0x1e0<br /> dput+0x118/0x1f0 fs/dcache.c:913<br /> __fput+0x3bf/0x570 fs/file_table.c:329<br /> ____fput+0x15/0x20 fs/file_table.c:349<br /> task_work_run+0x123/0x160 kernel/task_work.c:179<br /> resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]<br /> exit_to_user_mode_loop+0xcf/0xe0 kernel/entry/common.c:171<br /> exit_to_user_mode_prepare+0x6a/0xa0 kernel/entry/common.c:203<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]<br /> syscall_exit_to_user_mode+0x26/0x140 kernel/entry/common.c:296<br /> do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> read to 0xffff888237c2a2f8 of 8 bytes by task 19632 on cpu 1:<br /> obj_stock_flush_required mm/memcontrol.c:3319 [inline]<br /> drain_all_stock+0x174/0x2a0 mm/memcontrol.c:2361<br /> try_charge_memcg+0x6d0/0xd10 mm/memcontrol.c:2703<br /> try_charge mm/memcontrol.c:2837 [inline]<br /> mem_cgroup_charge_skmem+0x51/0x140 mm/memcontrol.c:7290<br /> sock_reserve_memory+0xb1/0x390 net/core/sock.c:1025<br /> sk_setsockopt+0x800/0x1e70 net/core/sock.c:1525<br /> udp_lib_setsockopt+0x99/0x6c0 net/ipv4/udp.c:2692<br /> udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2817<br /> sock_common_setsockopt+0x61/0x70 net/core/sock.c:3668<br /> __sys_setsockopt+0x1c3/0x230 net/socket.c:2271<br /> __do_sys_setsockopt net/socket.c:2282 [inline]<br /> __se_sys_setsockopt net/socket.c:2279 [inline]<br /> __x64_sys_setsockopt+0x66/0x80 net/socket.c:2279<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> value changed: 0xffff8881382d52c0 -&gt; 0xffff888138893740<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 1 PID: 19632 Comm: syz-executor.0 Not tainted 6.3.0-rc2-syzkaller-00387-g534293368afa #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023<br /> <br /> Fix it by using READ_ONCE()/WRITE_ONCE() for all accesses to<br /> stock-&gt;cached_objcg.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53402

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kernel/printk/index.c: 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:
19/09/2025

CVE-2023-53403

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> time/debug: 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 at<br /> once.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53404

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: fotg210: 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:
19/09/2025

CVE-2023-53405

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: gadget: gr_udc: 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:
19/09/2025

CVE-2023-53389

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: dp: Only trigger DRM HPD events if bridge is attached<br /> <br /> The MediaTek DisplayPort interface bridge driver starts its interrupts<br /> as soon as its probed. However when the interrupts trigger the bridge<br /> might not have been attached to a DRM device. As drm_helper_hpd_irq_event()<br /> does not check whether the passed in drm_device is valid or not, a NULL<br /> pointer passed in results in a kernel NULL pointer dereference in it.<br /> <br /> Check whether the bridge is attached and only trigger an HPD event if<br /> it is.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

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:
19/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:
19/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:
19/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:
19/09/2025