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

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cassini: Fix a memory leak in the error handling path of cas_init_one()<br /> <br /> cas_saturn_firmware_init() allocates some memory using vmalloc(). This<br /> memory is freed in the .remove() function but not it the error handling<br /> path of the probe.<br /> <br /> Add the missing vfree() to avoid a memory leak, should an error occur.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53436

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: snic: Fix possible memory leak if device_add() fails<br /> <br /> If device_add() returns error, the name allocated by dev_set_name() needs<br /> be freed. As the comment of device_add() says, put_device() should be used<br /> to give up the reference in the error path. So fix this by calling<br /> put_device(), then the name can be freed in kobject_cleanp().
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53437

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: uvcvideo: Handle cameras with invalid descriptors<br /> <br /> If the source entity does not contain any pads, do not create a link.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53438

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/MCE: Always save CS register on AMD Zen IF Poison errors<br /> <br /> The Instruction Fetch (IF) units on current AMD Zen-based systems do not<br /> guarantee a synchronous #MC is delivered for poison consumption errors.<br /> Therefore, MCG_STATUS[EIPV|RIPV] will not be set. However, the<br /> microarchitecture does guarantee that the exception is delivered within<br /> the same context. In other words, the exact rIP is not known, but the<br /> context is known to not have changed.<br /> <br /> There is no architecturally-defined method to determine this behavior.<br /> <br /> The Code Segment (CS) register is always valid on such IF unit poison<br /> errors regardless of the value of MCG_STATUS[EIPV|RIPV].<br /> <br /> Add a quirk to save the CS register for poison consumption from the IF<br /> unit banks.<br /> <br /> This is needed to properly determine the context of the error.<br /> Otherwise, the severity grading function will assume the context is<br /> IN_KERNEL due to the m-&gt;cs value being 0 (the initialized value). This<br /> leads to unnecessary kernel panics on data poison errors due to the<br /> kernel believing the poison consumption occurred in kernel context.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53422

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: fw: fix memory leak in debugfs<br /> <br /> Fix a memory leak that occurs when reading the fw_info<br /> file all the way, since we return NULL indicating no<br /> more data, but don&amp;#39;t free the status tracking object.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53423

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> objtool: Fix memory leak in create_static_call_sections()<br /> <br /> strdup() allocates memory for key_name. We need to release the memory in<br /> the following error paths. Add free() to avoid memory leak.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53424

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: mediatek: fix of_iomap memory leak<br /> <br /> Smatch reports:<br /> drivers/clk/mediatek/clk-mtk.c:583 mtk_clk_simple_probe() warn:<br /> &amp;#39;base&amp;#39; from of_iomap() not released on lines: 496.<br /> <br /> This problem was also found in linux-next. In mtk_clk_simple_probe(),<br /> base is not released when handling errors<br /> if clk_data is not existed, which may cause a leak.<br /> So free_base should be added here to release base.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53425

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: platform: mediatek: vpu: fix NULL ptr dereference<br /> <br /> If pdev is NULL, then it is still dereferenced.<br /> <br /> This fixes this smatch warning:<br /> <br /> drivers/media/platform/mediatek/vpu/mtk_vpu.c:570 vpu_load_firmware() warn: address of NULL pointer &amp;#39;pdev&amp;#39;
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53426

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: Fix xsk_diag use-after-free error during socket cleanup<br /> <br /> Fix a use-after-free error that is possible if the xsk_diag interface<br /> is used after the socket has been unbound from the device. This can<br /> happen either due to the socket being closed or the device<br /> disappearing. In the early days of AF_XDP, the way we tested that a<br /> socket was not bound to a device was to simply check if the netdevice<br /> pointer in the xsk socket structure was NULL. Later, a better system<br /> was introduced by having an explicit state variable in the xsk socket<br /> struct. For example, the state of a socket that is on the way to being<br /> closed and has been unbound from the device is XSK_UNBOUND.<br /> <br /> The commit in the Fixes tag below deleted the old way of signalling<br /> that a socket is unbound, setting dev to NULL. This in the belief that<br /> all code using the old way had been exterminated. That was<br /> unfortunately not true as the xsk diagnostics code was still using the<br /> old way and thus does not work as intended when a socket is going<br /> down. Fix this by introducing a test against the state variable. If<br /> the socket is in the state XSK_UNBOUND, simply abort the diagnostic&amp;#39;s<br /> netlink operation.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53427

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix warning and UAF when destroy the MR list<br /> <br /> If the MR allocate failed, the MR recovery work not initialized<br /> and list not cleared. Then will be warning and UAF when release<br /> the MR:<br /> <br /> WARNING: CPU: 4 PID: 824 at kernel/workqueue.c:3066 __flush_work.isra.0+0xf7/0x110<br /> CPU: 4 PID: 824 Comm: mount.cifs Not tainted 6.1.0-rc5+ #82<br /> RIP: 0010:__flush_work.isra.0+0xf7/0x110<br /> Call Trace:<br /> <br /> __cancel_work_timer+0x2ba/0x2e0<br /> smbd_destroy+0x4e1/0x990<br /> _smbd_get_connection+0x1cbd/0x2110<br /> smbd_get_connection+0x21/0x40<br /> cifs_get_tcp_session+0x8ef/0xda0<br /> mount_get_conns+0x60/0x750<br /> cifs_mount+0x103/0xd00<br /> cifs_smb3_do_mount+0x1dd/0xcb0<br /> smb3_get_tree+0x1d5/0x300<br /> vfs_get_tree+0x41/0xf0<br /> path_mount+0x9b3/0xdd0<br /> __x64_sys_mount+0x190/0x1d0<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> BUG: KASAN: use-after-free in smbd_destroy+0x4fc/0x990<br /> Read of size 8 at addr ffff88810b156a08 by task mount.cifs/824<br /> CPU: 4 PID: 824 Comm: mount.cifs Tainted: G W 6.1.0-rc5+ #82<br /> Call Trace:<br /> dump_stack_lvl+0x34/0x44<br /> print_report+0x171/0x472<br /> kasan_report+0xad/0x130<br /> smbd_destroy+0x4fc/0x990<br /> _smbd_get_connection+0x1cbd/0x2110<br /> smbd_get_connection+0x21/0x40<br /> cifs_get_tcp_session+0x8ef/0xda0<br /> mount_get_conns+0x60/0x750<br /> cifs_mount+0x103/0xd00<br /> cifs_smb3_do_mount+0x1dd/0xcb0<br /> smb3_get_tree+0x1d5/0x300<br /> vfs_get_tree+0x41/0xf0<br /> path_mount+0x9b3/0xdd0<br /> __x64_sys_mount+0x190/0x1d0<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Allocated by task 824:<br /> kasan_save_stack+0x1e/0x40<br /> kasan_set_track+0x21/0x30<br /> __kasan_kmalloc+0x7a/0x90<br /> _smbd_get_connection+0x1b6f/0x2110<br /> smbd_get_connection+0x21/0x40<br /> cifs_get_tcp_session+0x8ef/0xda0<br /> mount_get_conns+0x60/0x750<br /> cifs_mount+0x103/0xd00<br /> cifs_smb3_do_mount+0x1dd/0xcb0<br /> smb3_get_tree+0x1d5/0x300<br /> vfs_get_tree+0x41/0xf0<br /> path_mount+0x9b3/0xdd0<br /> __x64_sys_mount+0x190/0x1d0<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Freed by task 824:<br /> kasan_save_stack+0x1e/0x40<br /> kasan_set_track+0x21/0x30<br /> kasan_save_free_info+0x2a/0x40<br /> ____kasan_slab_free+0x143/0x1b0<br /> __kmem_cache_free+0xc8/0x330<br /> _smbd_get_connection+0x1c6a/0x2110<br /> smbd_get_connection+0x21/0x40<br /> cifs_get_tcp_session+0x8ef/0xda0<br /> mount_get_conns+0x60/0x750<br /> cifs_mount+0x103/0xd00<br /> cifs_smb3_do_mount+0x1dd/0xcb0<br /> smb3_get_tree+0x1d5/0x300<br /> vfs_get_tree+0x41/0xf0<br /> path_mount+0x9b3/0xdd0<br /> __x64_sys_mount+0x190/0x1d0<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Let&amp;#39;s initialize the MR recovery work before MR allocate to prevent<br /> the warning, remove the MRs from the list to prevent the UAF.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53428

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powercap: arm_scmi: Remove recursion while parsing zones<br /> <br /> Powercap zones can be defined as arranged in a hierarchy of trees and when<br /> registering a zone with powercap_register_zone(), the kernel powercap<br /> subsystem expects this to happen starting from the root zones down to the<br /> leaves; on the other side, de-registration by powercap_deregister_zone()<br /> must begin from the leaf zones.<br /> <br /> Available SCMI powercap zones are retrieved dynamically from the platform<br /> at probe time and, while any defined hierarchy between the zones is<br /> described properly in the zones descriptor, the platform returns the<br /> availables zones with no particular well-defined order: as a consequence,<br /> the trees possibly composing the hierarchy of zones have to be somehow<br /> walked properly to register the retrieved zones from the root.<br /> <br /> Currently the ARM SCMI Powercap driver walks the zones using a recursive<br /> algorithm; this approach, even though correct and tested can lead to kernel<br /> stack overflow when processing a returned hierarchy of zones composed by<br /> particularly high trees.<br /> <br /> Avoid possible kernel stack overflow by substituting the recursive approach<br /> with an iterative one supported by a dynamically allocated stack-like data<br /> structure.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025

CVE-2023-53429

Publication date:
18/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: don&amp;#39;t check PageError in __extent_writepage<br /> <br /> __extent_writepage currenly sets PageError whenever any error happens,<br /> and the also checks for PageError to decide if to call error handling.<br /> This leads to very unclear responsibility for cleaning up on errors.<br /> In the VM and generic writeback helpers the basic idea is that once<br /> I/O is fired off all error handling responsibility is delegated to the<br /> end I/O handler. But if that end I/O handler sets the PageError bit,<br /> and the submitter checks it, the bit could in some cases leak into the<br /> submission context for fast enough I/O.<br /> <br /> Fix this by simply not checking PageError and just using the local<br /> ret variable to check for submission errors. This also fundamentally<br /> solves the long problem documented in a comment in __extent_writepage<br /> by never leaking the error bit into the submission context.
Severity CVSS v4.0: Pending analysis
Last modification:
19/09/2025