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

Publication date:
16/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Protect against send buffer overflow in NFSv3 READ<br /> <br /> Since before the git era, NFSD has conserved the number of pages<br /> held by each nfsd thread by combining the RPC receive and send<br /> buffers into a single array of pages. This works because there are<br /> no cases where an operation needs a large RPC Call message and a<br /> large RPC Reply at the same time.<br /> <br /> Once an RPC Call has been received, svc_process() updates<br /> svc_rqst::rq_res to describe the part of rq_pages that can be<br /> used for constructing the Reply. This means that the send buffer<br /> (rq_res) shrinks when the received RPC record containing the RPC<br /> Call is large.<br /> <br /> A client can force this shrinkage on TCP by sending a correctly-<br /> formed RPC Call header contained in an RPC record that is<br /> excessively large. The full maximum payload size cannot be<br /> constructed in that case.
Severity CVSS v4.0: Pending analysis
Last modification:
17/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:
17/09/2025

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

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

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

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

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

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

CVE-2022-50341

Publication date:
16/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix oops during encryption<br /> <br /> When running xfstests against Azure the following oops occurred on an<br /> arm64 system<br /> <br /> Unable to handle kernel write to read-only memory at virtual address<br /> ffff0001221cf000<br /> Mem abort info:<br /> ESR = 0x9600004f<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x0f: level 3 permission fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x0000004f<br /> CM = 0, WnR = 1<br /> swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000294f3000<br /> [ffff0001221cf000] pgd=18000001ffff8003, p4d=18000001ffff8003,<br /> pud=18000001ff82e003, pmd=18000001ff71d003, pte=00600001221cf787<br /> Internal error: Oops: 9600004f [#1] PREEMPT SMP<br /> ...<br /> pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)<br /> pc : __memcpy+0x40/0x230<br /> lr : scatterwalk_copychunks+0xe0/0x200<br /> sp : ffff800014e92de0<br /> x29: ffff800014e92de0 x28: ffff000114f9de80 x27: 0000000000000008<br /> x26: 0000000000000008 x25: ffff800014e92e78 x24: 0000000000000008<br /> x23: 0000000000000001 x22: 0000040000000000 x21: ffff000000000000<br /> x20: 0000000000000001 x19: ffff0001037c4488 x18: 0000000000000014<br /> x17: 235e1c0d6efa9661 x16: a435f9576b6edd6c x15: 0000000000000058<br /> x14: 0000000000000001 x13: 0000000000000008 x12: ffff000114f2e590<br /> x11: ffffffffffffffff x10: 0000040000000000 x9 : ffff8000105c3580<br /> x8 : 2e9413b10000001a x7 : 534b4410fb86b005 x6 : 534b4410fb86b005<br /> x5 : ffff0001221cf008 x4 : ffff0001037c4490 x3 : 0000000000000001<br /> x2 : 0000000000000008 x1 : ffff0001037c4488 x0 : ffff0001221cf000<br /> Call trace:<br /> __memcpy+0x40/0x230<br /> scatterwalk_map_and_copy+0x98/0x100<br /> crypto_ccm_encrypt+0x150/0x180<br /> crypto_aead_encrypt+0x2c/0x40<br /> crypt_message+0x750/0x880<br /> smb3_init_transform_rq+0x298/0x340<br /> smb_send_rqst.part.11+0xd8/0x180<br /> smb_send_rqst+0x3c/0x100<br /> compound_send_recv+0x534/0xbc0<br /> smb2_query_info_compound+0x32c/0x440<br /> smb2_set_ea+0x438/0x4c0<br /> cifs_xattr_set+0x5d4/0x7c0<br /> <br /> This is because in scatterwalk_copychunks(), we attempted to write to<br /> a buffer (@sign) that was allocated in the stack (vmalloc area) by<br /> crypt_message() and thus accessing its remaining 8 (x2) bytes ended up<br /> crossing a page boundary.<br /> <br /> To simply fix it, we could just pass @sign kmalloc&amp;#39;d from<br /> crypt_message() and then we&amp;#39;re done. Luckily, we don&amp;#39;t seem to pass<br /> any other vmalloc&amp;#39;d buffers in smb_rqst::rq_iov...<br /> <br /> Instead, let&amp;#39;s map the correct pages and offsets from vmalloc buffers<br /> as well in cifs_sg_set_buf() and then avoiding such oopses.
Severity CVSS v4.0: Pending analysis
Last modification:
17/09/2025

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

CVE-2022-50343

Publication date:
16/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rapidio: fix possible name leaks when rio_add_device() fails<br /> <br /> Patch series "rapidio: fix three possible memory leaks".<br /> <br /> This patchset fixes three name leaks in error handling.<br /> - patch #1 fixes two name leaks while rio_add_device() fails.<br /> - patch #2 fixes a name leak while rio_register_mport() fails.<br /> <br /> <br /> This patch (of 2):<br /> <br /> If rio_add_device() returns error, the name allocated by dev_set_name()<br /> need be freed. It should use put_device() to give up the reference in the<br /> error path, so that the name can be freed in kobject_cleanup(), and the<br /> &amp;#39;rdev&amp;#39; can be freed in rio_release_dev().
Severity CVSS v4.0: Pending analysis
Last modification:
17/09/2025

CVE-2022-50339

Publication date:
16/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: avoid hci_dev_test_and_set_flag() in mgmt_init_hdev()<br /> <br /> syzbot is again reporting attempt to cancel uninitialized work<br /> at mgmt_index_removed() [1], for setting of HCI_MGMT flag from<br /> mgmt_init_hdev() from hci_mgmt_cmd() from hci_sock_sendmsg() can<br /> race with testing of HCI_MGMT flag from mgmt_index_removed() from<br /> hci_sock_bind() due to lack of serialization via hci_dev_lock().<br /> <br /> Since mgmt_init_hdev() is called with mgmt_chan_list_lock held, we can<br /> safely split hci_dev_test_and_set_flag() into hci_dev_test_flag() and<br /> hci_dev_set_flag(). Thus, in order to close this race, set HCI_MGMT flag<br /> after INIT_DELAYED_WORK() completed.<br /> <br /> This is a local fix based on mgmt_chan_list_lock. Lack of serialization<br /> via hci_dev_lock() might be causing different race conditions somewhere<br /> else. But a global fix based on hci_dev_lock() should deserve a future<br /> patch.
Severity CVSS v4.0: Pending analysis
Last modification:
17/09/2025