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

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/core: Fix null-ptr-deref in ib_core_cleanup()<br /> <br /> KASAN reported a null-ptr-deref error:<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]<br /> CPU: 1 PID: 379<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> RIP: 0010:destroy_workqueue+0x2f/0x740<br /> RSP: 0018:ffff888016137df8 EFLAGS: 00000202<br /> ...<br /> Call Trace:<br /> ib_core_cleanup+0xa/0xa1 [ib_core]<br /> __do_sys_delete_module.constprop.0+0x34f/0x5b0<br /> do_syscall_64+0x3a/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7fa1a0d221b7<br /> ...<br /> <br /> It is because the fail of roce_gid_mgmt_init() is ignored:<br /> <br /> ib_core_init()<br /> roce_gid_mgmt_init()<br /> gid_cache_wq = alloc_ordered_workqueue # fail<br /> ...<br /> ib_core_cleanup()<br /> roce_gid_mgmt_cleanup()<br /> destroy_workqueue(gid_cache_wq)<br /> # destroy an unallocated wq<br /> <br /> Fix this by catching the fail of roce_gid_mgmt_init() in ib_core_init().
Severity CVSS v4.0: Pending analysis
Last modification:
01/10/2025

CVE-2022-49926

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: Fix possible memory leaks in dsa_loop_init()<br /> <br /> kmemleak reported memory leaks in dsa_loop_init():<br /> <br /> kmemleak: 12 new suspected memory leaks<br /> <br /> unreferenced object 0xffff8880138ce000 (size 2048):<br /> comm "modprobe", pid 390, jiffies 4295040478 (age 238.976s)<br /> backtrace:<br /> [] kmalloc_trace+0x26/0x60<br /> [] phy_device_create+0x5d/0x970<br /> [] get_phy_device+0xf3/0x2b0<br /> [] __fixed_phy_register.part.0+0x92/0x4e0<br /> [] fixed_phy_register+0x84/0xb0<br /> [] dsa_loop_init+0xa9/0x116 [dsa_loop]<br /> ...<br /> <br /> There are two reasons for memleak in dsa_loop_init().<br /> <br /> First, fixed_phy_register() create and register phy_device:<br /> <br /> fixed_phy_register()<br /> get_phy_device()<br /> phy_device_create() # freed by phy_device_free()<br /> phy_device_register() # freed by phy_device_remove()<br /> <br /> But fixed_phy_unregister() only calls phy_device_remove().<br /> So the memory allocated in phy_device_create() is leaked.<br /> <br /> Second, when mdio_driver_register() fail in dsa_loop_init(),<br /> it just returns and there is no cleanup for phydevs.<br /> <br /> Fix the problems by catching the error of mdio_driver_register()<br /> in dsa_loop_init(), then calling both fixed_phy_unregister() and<br /> phy_device_free() to release phydevs.<br /> Also add a function for phydevs cleanup to avoid duplacate.
Severity CVSS v4.0: Pending analysis
Last modification:
01/10/2025

CVE-2022-49927

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfs4: Fix kmemleak when allocate slot failed<br /> <br /> If one of the slot allocate failed, should cleanup all the other<br /> allocated slots, otherwise, the allocated slots will leak:<br /> <br /> unreferenced object 0xffff8881115aa100 (size 64):<br /> comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s)<br /> hex dump (first 32 bytes):<br /> 00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z.....<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] nfs4_find_or_create_slot+0x8e/0x130<br /> [] nfs4_realloc_slot_table+0x23f/0x270<br /> [] nfs40_init_client+0x4a/0x90<br /> [] nfs4_init_client+0xce/0x270<br /> [] nfs4_set_client+0x1a2/0x2b0<br /> [] nfs4_create_server+0x300/0x5f0<br /> [] nfs4_try_get_tree+0x65/0x110<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
Severity CVSS v4.0: Pending analysis
Last modification:
01/10/2025

CVE-2022-49928

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: Fix null-ptr-deref when xps sysfs alloc failed<br /> <br /> There is a null-ptr-deref when xps sysfs alloc failed:<br /> BUG: KASAN: null-ptr-deref in sysfs_do_create_link_sd+0x40/0xd0<br /> Read of size 8 at addr 0000000000000030 by task gssproxy/457<br /> <br /> CPU: 5 PID: 457 Comm: gssproxy Not tainted 6.0.0-09040-g02357b27ee03 #9<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x34/0x44<br /> kasan_report+0xa3/0x120<br /> sysfs_do_create_link_sd+0x40/0xd0<br /> rpc_sysfs_client_setup+0x161/0x1b0<br /> rpc_new_client+0x3fc/0x6e0<br /> rpc_create_xprt+0x71/0x220<br /> rpc_create+0x1d4/0x350<br /> gssp_rpc_create+0xc3/0x160<br /> set_gssp_clnt+0xbc/0x140<br /> write_gssp+0x116/0x1a0<br /> proc_reg_write+0xd6/0x130<br /> vfs_write+0x177/0x690<br /> ksys_write+0xb9/0x150<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> When the xprt_switch sysfs alloc failed, should not add xprt and<br /> switch sysfs to it, otherwise, maybe null-ptr-deref; also initialize<br /> the &amp;#39;xps_sysfs&amp;#39; to NULL to avoid oops when destroy it.
Severity CVSS v4.0: Pending analysis
Last modification:
01/10/2025

CVE-2022-49930

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hns: Fix NULL pointer problem in free_mr_init()<br /> <br /> Lock grab occurs in a concurrent scenario, resulting in stepping on a NULL<br /> pointer. It should be init mutex_init() first before use the lock.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> Call trace:<br /> __mutex_lock.constprop.0+0xd0/0x5c0<br /> __mutex_lock_slowpath+0x1c/0x2c<br /> mutex_lock+0x44/0x50<br /> free_mr_send_cmd_to_hw+0x7c/0x1c0 [hns_roce_hw_v2]<br /> hns_roce_v2_dereg_mr+0x30/0x40 [hns_roce_hw_v2]<br /> hns_roce_dereg_mr+0x4c/0x130 [hns_roce_hw_v2]<br /> ib_dereg_mr_user+0x54/0x124<br /> uverbs_free_mr+0x24/0x30<br /> destroy_hw_idr_uobject+0x38/0x74<br /> uverbs_destroy_uobject+0x48/0x1c4<br /> uobj_destroy+0x74/0xcc<br /> ib_uverbs_cmd_verbs+0x368/0xbb0<br /> ib_uverbs_ioctl+0xec/0x1a4<br /> __arm64_sys_ioctl+0xb4/0x100<br /> invoke_syscall+0x50/0x120<br /> el0_svc_common.constprop.0+0x58/0x190<br /> do_el0_svc+0x30/0x90<br /> el0_svc+0x2c/0xb4<br /> el0t_64_sync_handler+0x1a4/0x1b0<br /> el0t_64_sync+0x19c/0x1a0
Severity CVSS v4.0: Pending analysis
Last modification:
01/10/2025

CVE-2022-49929

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix mr leak in RESPST_ERR_RNR<br /> <br /> rxe_recheck_mr() will increase mr&amp;#39;s ref_cnt, so we should call rxe_put(mr)<br /> to drop mr&amp;#39;s ref_cnt in RESPST_ERR_RNR to avoid below warning:<br /> <br /> WARNING: CPU: 0 PID: 4156 at drivers/infiniband/sw/rxe/rxe_pool.c:259 __rxe_cleanup+0x1df/0x240 [rdma_rxe]<br /> ...<br /> Call Trace:<br /> rxe_dereg_mr+0x4c/0x60 [rdma_rxe]<br /> ib_dereg_mr_user+0xa8/0x200 [ib_core]<br /> ib_mr_pool_destroy+0x77/0xb0 [ib_core]<br /> nvme_rdma_destroy_queue_ib+0x89/0x240 [nvme_rdma]<br /> nvme_rdma_free_queue+0x40/0x50 [nvme_rdma]<br /> nvme_rdma_teardown_io_queues.part.0+0xc3/0x120 [nvme_rdma]<br /> nvme_rdma_error_recovery_work+0x4d/0xf0 [nvme_rdma]<br /> process_one_work+0x582/0xa40<br /> ? pwq_dec_nr_in_flight+0x100/0x100<br /> ? rwlock_bug.part.0+0x60/0x60<br /> worker_thread+0x2a9/0x700<br /> ? process_one_work+0xa40/0xa40<br /> kthread+0x168/0x1a0<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x22/0x30
Severity CVSS v4.0: Pending analysis
Last modification:
12/11/2025

CVE-2022-49919

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: release flow rule object from commit path<br /> <br /> No need to postpone this to the commit release path, since no packets<br /> are walking over this object, this is accessed from control plane only.<br /> This helped uncovered UAF triggered by races with the netlink notifier.
Severity CVSS v4.0: Pending analysis
Last modification:
01/10/2025

CVE-2022-49920

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: netlink notifier might race to release objects<br /> <br /> commit release path is invoked via call_rcu and it runs lockless to<br /> release the objects after rcu grace period. The netlink notifier handler<br /> might win race to remove objects that the transaction context is still<br /> referencing from the commit release path.<br /> <br /> Call rcu_barrier() to ensure pending rcu callbacks run to completion<br /> if the list of transactions to be destroyed is not empty.
Severity CVSS v4.0: Pending analysis
Last modification:
01/10/2025

CVE-2022-49921

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sched: Fix use after free in red_enqueue()<br /> <br /> We can&amp;#39;t use "skb" again after passing it to qdisc_enqueue(). This is<br /> basically identical to commit 2f09707d0c97 ("sch_sfb: Also store skb<br /> len before calling child enqueue").
Severity CVSS v4.0: Pending analysis
Last modification:
01/10/2025

CVE-2022-49922

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send()<br /> <br /> nfcmrvl_i2c_nci_send() will be called by nfcmrvl_nci_send(), and skb<br /> should be freed in nfcmrvl_i2c_nci_send(). However, nfcmrvl_nci_send()<br /> will only free skb when i2c_master_send() return &gt;=0, which means skb<br /> will memleak when i2c_master_send() failed. Free skb no matter whether<br /> i2c_master_send() succeeds.
Severity CVSS v4.0: Pending analysis
Last modification:
01/10/2025

CVE-2022-49923

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: nxp-nci: Fix potential memory leak in nxp_nci_send()<br /> <br /> nxp_nci_send() will call nxp_nci_i2c_write(), and only free skb when<br /> nxp_nci_i2c_write() failed. However, even if the nxp_nci_i2c_write()<br /> run succeeds, the skb will not be freed in nxp_nci_i2c_write(). As the<br /> result, the skb will memleak. nxp_nci_send() should also free the skb<br /> when nxp_nci_i2c_write() succeeds.
Severity CVSS v4.0: Pending analysis
Last modification:
01/10/2025

CVE-2022-49918

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvs: fix WARNING in __ip_vs_cleanup_batch()<br /> <br /> During the initialization of ip_vs_conn_net_init(), if file ip_vs_conn<br /> or ip_vs_conn_sync fails to be created, the initialization is successful<br /> by default. Therefore, the ip_vs_conn or ip_vs_conn_sync file doesn&amp;#39;t<br /> be found during the remove.<br /> <br /> The following is the stack information:<br /> name &amp;#39;ip_vs_conn_sync&amp;#39;<br /> WARNING: CPU: 3 PID: 9 at fs/proc/generic.c:712<br /> remove_proc_entry+0x389/0x460<br /> Modules linked in:<br /> Workqueue: netns cleanup_net<br /> RIP: 0010:remove_proc_entry+0x389/0x460<br /> Call Trace:<br /> <br /> __ip_vs_cleanup_batch+0x7d/0x120<br /> ops_exit_list+0x125/0x170<br /> cleanup_net+0x4ea/0xb00<br /> process_one_work+0x9bf/0x1710<br /> worker_thread+0x665/0x1080<br /> kthread+0x2e4/0x3a0<br /> ret_from_fork+0x1f/0x30<br />
Severity CVSS v4.0: Pending analysis
Last modification:
12/11/2025