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-2022-50352

Publication date:
16/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns: fix possible memory leak in hnae_ae_register()<br /> <br /> Inject fault while probing module, if device_register() fails,<br /> but the refcount of kobject is not decreased to 0, the name<br /> allocated in dev_set_name() is leaked. Fix this by calling<br /> put_device(), so that name can be freed in callback function<br /> kobject_cleanup().<br /> <br /> unreferenced object 0xffff00c01aba2100 (size 128):<br /> comm "systemd-udevd", pid 1259, jiffies 4294903284 (age 294.152s)<br /> hex dump (first 32 bytes):<br /> 68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff hnae0....!......<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] slab_post_alloc_hook+0xa0/0x3e0<br /> [] __kmem_cache_alloc_node+0x164/0x2b0<br /> [] __kmalloc_node_track_caller+0x6c/0x390<br /> [] kvasprintf+0x8c/0x118<br /> [] kvasprintf_const+0x60/0xc8<br /> [] kobject_set_name_vargs+0x3c/0xc0<br /> [] dev_set_name+0x7c/0xa0<br /> [] hnae_ae_register+0xcc/0x190 [hnae]<br /> [] hns_dsaf_ae_init+0x9c/0x108 [hns_dsaf]<br /> [] hns_dsaf_probe+0x548/0x748 [hns_dsaf]
Severity CVSS v4.0: Pending analysis
Last modification:
14/01/2026

CVE-2023-53304

Publication date:
16/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_set_rbtree: fix overlap expiration walk<br /> <br /> The lazy gc on insert that should remove timed-out entries fails to release<br /> the other half of the interval, if any.<br /> <br /> Can be reproduced with tests/shell/testcases/sets/0044interval_overlap_0<br /> in nftables.git and kmemleak enabled kernel.<br /> <br /> Second bug is the use of rbe_prev vs. prev pointer.<br /> If rbe_prev() returns NULL after at least one iteration, rbe_prev points<br /> to element that is not an end interval, hence it should not be removed.<br /> <br /> Lastly, check the genmask of the end interval if this is active in the<br /> current generation.
Severity CVSS v4.0: Pending analysis
Last modification:
14/01/2026

CVE-2022-50344

Publication date:
16/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix null-ptr-deref in ext4_write_info<br /> <br /> I caught a null-ptr-deref bug as follows:<br /> ==================================================================<br /> KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]<br /> CPU: 1 PID: 1589 Comm: umount Not tainted 5.10.0-02219-dirty #339<br /> RIP: 0010:ext4_write_info+0x53/0x1b0<br /> [...]<br /> Call Trace:<br /> dquot_writeback_dquots+0x341/0x9a0<br /> ext4_sync_fs+0x19e/0x800<br /> __sync_filesystem+0x83/0x100<br /> sync_filesystem+0x89/0xf0<br /> generic_shutdown_super+0x79/0x3e0<br /> kill_block_super+0xa1/0x110<br /> deactivate_locked_super+0xac/0x130<br /> deactivate_super+0xb6/0xd0<br /> cleanup_mnt+0x289/0x400<br /> __cleanup_mnt+0x16/0x20<br /> task_work_run+0x11c/0x1c0<br /> exit_to_user_mode_prepare+0x203/0x210<br /> syscall_exit_to_user_mode+0x5b/0x3a0<br /> do_syscall_64+0x59/0x70<br /> entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> ==================================================================<br /> <br /> Above issue may happen as follows:<br /> -------------------------------------<br /> exit_to_user_mode_prepare<br /> task_work_run<br /> __cleanup_mnt<br /> cleanup_mnt<br /> deactivate_super<br /> deactivate_locked_super<br /> kill_block_super<br /> generic_shutdown_super<br /> shrink_dcache_for_umount<br /> dentry = sb-&gt;s_root<br /> sb-&gt;s_root = NULL s_op-&gt;sync_fs &gt; ext4_sync_fs<br /> dquot_writeback_dquots<br /> sb-&gt;dq_op-&gt;write_info &gt; ext4_write_info<br /> ext4_journal_start(d_inode(sb-&gt;s_root), EXT4_HT_QUOTA, 2)<br /> d_inode(sb-&gt;s_root)<br /> s_root-&gt;d_inode
Severity CVSS v4.0: Pending analysis
Last modification:
14/01/2026

CVE-2022-50345

Publication date:
16/09/2025
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Severity CVSS v4.0: Pending analysis
Last modification:
29/09/2025

CVE-2022-50346

Publication date:
16/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: init quota for &amp;#39;old.inode&amp;#39; in &amp;#39;ext4_rename&amp;#39;<br /> <br /> Syzbot found the following issue:<br /> ext4_parse_param: s_want_extra_isize=128<br /> ext4_inode_info_init: s_want_extra_isize=32<br /> ext4_rename: old.inode=ffff88823869a2c8 old.dir=ffff888238699828 new.inode=ffff88823869d7e8 new.dir=ffff888238699828<br /> __ext4_mark_inode_dirty: inode=ffff888238699828 ea_isize=32 want_ea_size=128<br /> __ext4_mark_inode_dirty: inode=ffff88823869a2c8 ea_isize=32 want_ea_size=128<br /> ext4_xattr_block_set: inode=ffff88823869a2c8<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 13 PID: 2234 at fs/ext4/xattr.c:2070 ext4_xattr_block_set.cold+0x22/0x980<br /> Modules linked in:<br /> RIP: 0010:ext4_xattr_block_set.cold+0x22/0x980<br /> RSP: 0018:ffff888227d3f3b0 EFLAGS: 00010202<br /> RAX: 0000000000000001 RBX: ffff88823007a000 RCX: 0000000000000000<br /> RDX: 0000000000000a03 RSI: 0000000000000040 RDI: ffff888230078178<br /> RBP: 0000000000000000 R08: 000000000000002c R09: ffffed1075c7df8e<br /> R10: ffff8883ae3efc6b R11: ffffed1075c7df8d R12: 0000000000000000<br /> R13: ffff88823869a2c8 R14: ffff8881012e0460 R15: dffffc0000000000<br /> FS: 00007f350ac1f740(0000) GS:ffff8883ae200000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f350a6ed6a0 CR3: 0000000237456000 CR4: 00000000000006e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? ext4_xattr_set_entry+0x3b7/0x2320<br /> ? ext4_xattr_block_set+0x0/0x2020<br /> ? ext4_xattr_set_entry+0x0/0x2320<br /> ? ext4_xattr_check_entries+0x77/0x310<br /> ? ext4_xattr_ibody_set+0x23b/0x340<br /> ext4_xattr_move_to_block+0x594/0x720<br /> ext4_expand_extra_isize_ea+0x59a/0x10f0<br /> __ext4_expand_extra_isize+0x278/0x3f0<br /> __ext4_mark_inode_dirty.cold+0x347/0x410<br /> ext4_rename+0xed3/0x174f<br /> vfs_rename+0x13a7/0x2510<br /> do_renameat2+0x55d/0x920<br /> __x64_sys_rename+0x7d/0xb0<br /> do_syscall_64+0x3b/0xa0<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> As &amp;#39;ext4_rename&amp;#39; will modify &amp;#39;old.inode&amp;#39; ctime and mark inode dirty,<br /> which may trigger expand &amp;#39;extra_isize&amp;#39; and allocate block. If inode<br /> didn&amp;#39;t init quota will lead to warning. To solve above issue, init<br /> &amp;#39;old.inode&amp;#39; firstly in &amp;#39;ext4_rename&amp;#39;.
Severity CVSS v4.0: Pending analysis
Last modification:
14/01/2026

CVE-2022-50347

Publication date:
16/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: rtsx_usb_sdmmc: fix return value check of mmc_add_host()<br /> <br /> mmc_add_host() may return error, if we ignore its return value, the memory<br /> that allocated in mmc_alloc_host() will be leaked and it will lead a kernel<br /> crash because of deleting not added device in the remove path.<br /> <br /> So fix this by checking the return value and calling mmc_free_host() in the<br /> error path, besides, led_classdev_unregister() and pm_runtime_disable() also<br /> need be called.
Severity CVSS v4.0: Pending analysis
Last modification:
14/01/2026

CVE-2022-50348

Publication date:
16/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: Fix a memory leak in an error handling path<br /> <br /> If this memdup_user() call fails, the memory allocated in a previous call<br /> a few lines above should be freed. Otherwise it leaks.
Severity CVSS v4.0: Pending analysis
Last modification:
14/01/2026

CVE-2022-50349

Publication date:
16/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: tifm: fix possible memory leak in tifm_7xx1_switch_media()<br /> <br /> If device_register() returns error in tifm_7xx1_switch_media(),<br /> name of kobject which is allocated in dev_set_name() called in device_add()<br /> is leaked.<br /> <br /> Never directly free @dev after calling device_register(), even<br /> if it returned an error! Always use put_device() to give up the<br /> reference initialized.
Severity CVSS v4.0: Pending analysis
Last modification:
14/01/2026

CVE-2022-50351

Publication date:
16/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix xid leak in cifs_create()<br /> <br /> If the cifs already shutdown, we should free the xid before return,<br /> otherwise, the xid will be leaked.
Severity CVSS v4.0: Pending analysis
Last modification:
14/01/2026

CVE-2022-50350

Publication date:
16/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: iscsi: Fix a race condition between login_work and the login thread<br /> <br /> In case a malicious initiator sends some random data immediately after a<br /> login PDU; the iscsi_target_sk_data_ready() callback will schedule the<br /> login_work and, at the same time, the negotiation may end without clearing<br /> the LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges are<br /> required to complete the login).<br /> <br /> The login has been completed but the login_work function will find the<br /> LOGIN_FLAGS_INITIAL_PDU flag set and will never stop from rescheduling<br /> itself; at this point, if the initiator drops the connection, the<br /> iscsit_conn structure will be freed, login_work will dereference a released<br /> socket structure and the kernel crashes.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000230<br /> PF: supervisor write access in kernel mode<br /> PF: error_code(0x0002) - not-present page<br /> Workqueue: events iscsi_target_do_login_rx [iscsi_target_mod]<br /> RIP: 0010:_raw_read_lock_bh+0x15/0x30<br /> Call trace:<br /> iscsi_target_do_login_rx+0x75/0x3f0 [iscsi_target_mod]<br /> process_one_work+0x1e8/0x3c0<br /> <br /> Fix this bug by forcing login_work to stop after the login has been<br /> completed and the socket callbacks have been restored.<br /> <br /> Add a comment to clearify the return values of iscsi_target_do_login()
Severity CVSS v4.0: Pending analysis
Last modification:
04/08/2026

CVE-2022-50340

Publication date:
16/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vimc: Fix wrong function called when vimc_init() fails<br /> <br /> In vimc_init(), when platform_driver_register(&amp;vimc_pdrv) fails,<br /> platform_driver_unregister(&amp;vimc_pdrv) is wrongly called rather than<br /> platform_device_unregister(&amp;vimc_pdev), which causes kernel warning:<br /> <br /> Unexpected driver unregister!<br /> WARNING: CPU: 1 PID: 14517 at drivers/base/driver.c:270 driver_unregister+0x8f/0xb0<br /> RIP: 0010:driver_unregister+0x8f/0xb0<br /> Call Trace:<br /> <br /> vimc_init+0x7d/0x1000 [vimc]<br /> do_one_initcall+0xd0/0x4e0<br /> do_init_module+0x1cf/0x6b0<br /> load_module+0x65c2/0x7820
Severity CVSS v4.0: Pending analysis
Last modification:
14/01/2026

CVE-2022-50342

Publication date:
16/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> floppy: Fix memory leak in do_floppy_init()<br /> <br /> A memory leak was reported when floppy_alloc_disk() failed in<br /> do_floppy_init().<br /> <br /> unreferenced object 0xffff888115ed25a0 (size 8):<br /> comm "modprobe", pid 727, jiffies 4295051278 (age 25.529s)<br /> hex dump (first 8 bytes):<br /> 00 ac 67 5b 81 88 ff ff ..g[....<br /> backtrace:<br /> [] __kmalloc_node+0x4c/0xc0<br /> [] blk_mq_realloc_tag_set_tags.part.0+0x6f/0x180<br /> [] blk_mq_alloc_tag_set+0x573/0x1130<br /> [] 0xffffffffc06b8b08<br /> [] do_one_initcall+0xd0/0x4f0<br /> [] do_init_module+0x1a4/0x680<br /> [] load_module+0x6249/0x7110<br /> [] __do_sys_finit_module+0x140/0x200<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> unreferenced object 0xffff88810fc30540 (size 32):<br /> comm "modprobe", pid 727, jiffies 4295051278 (age 25.529s)<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 /> [] __kmalloc_node+0x4c/0xc0<br /> [] blk_mq_alloc_tag_set+0x393/0x1130<br /> [] 0xffffffffc06b8b08<br /> [] do_one_initcall+0xd0/0x4f0<br /> [] do_init_module+0x1a4/0x680<br /> [] load_module+0x6249/0x7110<br /> [] __do_sys_finit_module+0x140/0x200<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> If the floppy_alloc_disk() failed, disks of current drive will not be set,<br /> thus the lastest allocated set-&gt;tag cannot be freed in the error handling<br /> path. A simple call graph shown as below:<br /> <br /> floppy_module_init()<br /> floppy_init()<br /> do_floppy_init()<br /> for (drive = 0; drive tag allocated<br /> floppy_alloc_disk()<br /> blk_mq_alloc_disk() # error occurred, disks failed to allocated<br /> <br /> -&gt;out_put_disk:<br /> for (drive = 0; drive tag leaked<br /> <br /> Fix this problem by free the set-&gt;tag of current drive before jump to<br /> error handling path.<br /> <br /> [efremov: added stable list, changed title]
Severity CVSS v4.0: Pending analysis
Last modification:
14/01/2026