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

Publication date:
26/02/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fix lockdep splat in in6_dump_addrs()<br /> <br /> As reported by syzbot, we should not use rcu_dereference()<br /> when rcu_read_lock() is not held.<br /> <br /> WARNING: suspicious RCU usage<br /> 5.19.0-rc2-syzkaller #0 Not tainted<br /> <br /> net/ipv6/addrconf.c:5175 suspicious rcu_dereference_check() usage!<br /> <br /> other info that might help us debug this:<br /> <br /> rcu_scheduler_active = 2, debug_locks = 1<br /> 1 lock held by syz-executor326/3617:<br /> #0: ffffffff8d5848e8 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0xae/0xc20 net/netlink/af_netlink.c:2223<br /> <br /> stack backtrace:<br /> CPU: 0 PID: 3617 Comm: syz-executor326 Not tainted 5.19.0-rc2-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> in6_dump_addrs+0x12d1/0x1790 net/ipv6/addrconf.c:5175<br /> inet6_dump_addr+0x9c1/0xb50 net/ipv6/addrconf.c:5300<br /> netlink_dump+0x541/0xc20 net/netlink/af_netlink.c:2275<br /> __netlink_dump_start+0x647/0x900 net/netlink/af_netlink.c:2380<br /> netlink_dump_start include/linux/netlink.h:245 [inline]<br /> rtnetlink_rcv_msg+0x73e/0xc90 net/core/rtnetlink.c:6046<br /> netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2501<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]<br /> netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345<br /> netlink_sendmsg+0x917/0xe10 net/netlink/af_netlink.c:1921<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg+0xcf/0x120 net/socket.c:734<br /> ____sys_sendmsg+0x6eb/0x810 net/socket.c:2492<br /> ___sys_sendmsg+0xf3/0x170 net/socket.c:2546<br /> __sys_sendmsg net/socket.c:2575 [inline]<br /> __do_sys_sendmsg net/socket.c:2584 [inline]<br /> __se_sys_sendmsg net/socket.c:2582 [inline]<br /> __x64_sys_sendmsg+0x132/0x220 net/socket.c:2582<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0
Severity CVSS v4.0: Pending analysis
Last modification:
26/02/2025

CVE-2022-49663

Publication date:
26/02/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tunnels: do not assume mac header is set in skb_tunnel_check_pmtu()<br /> <br /> Recently added debug in commit f9aefd6b2aa3 ("net: warn if mac header<br /> was not set") caught a bug in skb_tunnel_check_pmtu(), as shown<br /> in this syzbot report [1].<br /> <br /> In ndo_start_xmit() paths, there is really no need to use skb-&gt;mac_header,<br /> because skb-&gt;data is supposed to point at it.<br /> <br /> [1] WARNING: CPU: 1 PID: 8604 at include/linux/skbuff.h:2784 skb_mac_header_len include/linux/skbuff.h:2784 [inline]<br /> WARNING: CPU: 1 PID: 8604 at include/linux/skbuff.h:2784 skb_tunnel_check_pmtu+0x5de/0x2f90 net/ipv4/ip_tunnel_core.c:413<br /> Modules linked in:<br /> CPU: 1 PID: 8604 Comm: syz-executor.3 Not tainted 5.19.0-rc2-syzkaller-00443-g8720bd951b8e #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:skb_mac_header_len include/linux/skbuff.h:2784 [inline]<br /> RIP: 0010:skb_tunnel_check_pmtu+0x5de/0x2f90 net/ipv4/ip_tunnel_core.c:413<br /> Code: 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 80 3c 02 00 0f 84 b9 fe ff ff 4c 89 ff e8 7c 0f d7 f9 e9 ac fe ff ff e8 c2 13 8a f9 0b e9 28 fc ff ff e8 b6 13 8a f9 48 8b 54 24 70 48 b8 00 00 00<br /> RSP: 0018:ffffc90002e4f520 EFLAGS: 00010212<br /> RAX: 0000000000000324 RBX: ffff88804d5fd500 RCX: ffffc90005b52000<br /> RDX: 0000000000040000 RSI: ffffffff87f05e3e RDI: 0000000000000003<br /> RBP: ffffc90002e4f650 R08: 0000000000000003 R09: 000000000000ffff<br /> R10: 000000000000ffff R11: 0000000000000000 R12: 000000000000ffff<br /> R13: 0000000000000000 R14: 000000000000ffcd R15: 000000000000001f<br /> FS: 00007f3babba9700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020000080 CR3: 0000000075319000 CR4: 00000000003506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> geneve_xmit_skb drivers/net/geneve.c:927 [inline]<br /> geneve_xmit+0xcf8/0x35d0 drivers/net/geneve.c:1107<br /> __netdev_start_xmit include/linux/netdevice.h:4805 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:4819 [inline]<br /> __dev_direct_xmit+0x500/0x730 net/core/dev.c:4309<br /> dev_direct_xmit include/linux/netdevice.h:3007 [inline]<br /> packet_direct_xmit+0x1b8/0x2c0 net/packet/af_packet.c:282<br /> packet_snd net/packet/af_packet.c:3073 [inline]<br /> packet_sendmsg+0x21f4/0x55d0 net/packet/af_packet.c:3104<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg+0xcf/0x120 net/socket.c:734<br /> ____sys_sendmsg+0x6eb/0x810 net/socket.c:2489<br /> ___sys_sendmsg+0xf3/0x170 net/socket.c:2543<br /> __sys_sendmsg net/socket.c:2572 [inline]<br /> __do_sys_sendmsg net/socket.c:2581 [inline]<br /> __se_sys_sendmsg net/socket.c:2579 [inline]<br /> __x64_sys_sendmsg+0x132/0x220 net/socket.c:2579<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> RIP: 0033:0x7f3baaa89109<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f3babba9168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007f3baab9bf60 RCX: 00007f3baaa89109<br /> RDX: 0000000000000000 RSI: 0000000020000a00 RDI: 0000000000000003<br /> RBP: 00007f3baaae305d R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007ffe74f2543f R14: 00007f3babba9300 R15: 0000000000022000<br />
Severity CVSS v4.0: Pending analysis
Last modification:
26/02/2025

CVE-2022-49665

Publication date:
26/02/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: thinkpad_acpi: Fix a memory leak of EFCH MMIO resource<br /> <br /> Unlike release_mem_region(), a call to release_resource() does not<br /> free the resource, so it has to be freed explicitly to avoid a memory<br /> leak.
Severity CVSS v4.0: Pending analysis
Last modification:
26/02/2025

CVE-2022-49666

Publication date:
26/02/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/memhotplug: Add add_pages override for PPC<br /> <br /> With commit ffa0b64e3be5 ("powerpc: Fix virt_addr_valid() for 64-bit Book3E &amp; 32-bit")<br /> the kernel now validate the addr against high_memory value. This results<br /> in the below BUG_ON with dax pfns.<br /> <br /> [ 635.798741][T26531] kernel BUG at mm/page_alloc.c:5521!<br /> 1:mon&gt; e<br /> cpu 0x1: Vector: 700 (Program Check) at [c000000007287630]<br /> pc: c00000000055ed48: free_pages.part.0+0x48/0x110<br /> lr: c00000000053ca70: tlb_finish_mmu+0x80/0xd0<br /> sp: c0000000072878d0<br /> msr: 800000000282b033<br /> current = 0xc00000000afabe00<br /> paca = 0xc00000037ffff300 irqmask: 0x03 irq_happened: 0x05<br /> pid = 26531, comm = 50-landscape-sy<br /> kernel BUG at :5521!<br /> Linux version 5.19.0-rc3-14659-g4ec05be7c2e1 (kvaneesh@ltc-boston8) (gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #625 SMP Thu Jun 23 00:35:43 CDT 2022<br /> 1:mon&gt; t<br /> [link register ] c00000000053ca70 tlb_finish_mmu+0x80/0xd0<br /> [c0000000072878d0] c00000000053ca54 tlb_finish_mmu+0x64/0xd0 (unreliable)<br /> [c000000007287900] c000000000539424 exit_mmap+0xe4/0x2a0<br /> [c0000000072879e0] c00000000019fc1c mmput+0xcc/0x210<br /> [c000000007287a20] c000000000629230 begin_new_exec+0x5e0/0xf40<br /> [c000000007287ae0] c00000000070b3cc load_elf_binary+0x3ac/0x1e00<br /> [c000000007287c10] c000000000627af0 bprm_execve+0x3b0/0xaf0<br /> [c000000007287cd0] c000000000628414 do_execveat_common.isra.0+0x1e4/0x310<br /> [c000000007287d80] c00000000062858c sys_execve+0x4c/0x60<br /> [c000000007287db0] c00000000002c1b0 system_call_exception+0x160/0x2c0<br /> [c000000007287e10] c00000000000c53c system_call_common+0xec/0x250<br /> <br /> The fix is to make sure we update high_memory on memory hotplug.<br /> This is similar to what x86 does in commit 3072e413e305 ("mm/memory_hotplug: introduce add_pages")
Severity CVSS v4.0: Pending analysis
Last modification:
26/02/2025

CVE-2022-49660

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

CVE-2022-49651

Publication date:
26/02/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> srcu: Tighten cleanup_srcu_struct() GP checks<br /> <br /> Currently, cleanup_srcu_struct() checks for a grace period in progress,<br /> but it does not check for a grace period that has not yet started but<br /> which might start at any time. Such a situation could result in a<br /> use-after-free bug, so this commit adds a check for a grace period that<br /> is needed but not yet started to cleanup_srcu_struct().
Severity CVSS v4.0: Pending analysis
Last modification:
24/03/2025

CVE-2022-49652

Publication date:
26/02/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocate<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not needed anymore.<br /> <br /> Add missing of_node_put() in to fix this.
Severity CVSS v4.0: Pending analysis
Last modification:
11/03/2025

CVE-2022-49656

Publication date:
26/02/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: meson: Fix refcount leak in meson_smp_prepare_cpus<br /> <br /> of_find_compatible_node() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when done.<br /> Add missing of_node_put() to avoid refcount leak.
Severity CVSS v4.0: Pending analysis
Last modification:
11/03/2025

CVE-2022-49649

Publication date:
26/02/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen/netback: avoid entering xenvif_rx_next_skb() with an empty rx queue<br /> <br /> xenvif_rx_next_skb() is expecting the rx queue not being empty, but<br /> in case the loop in xenvif_rx_action() is doing multiple iterations,<br /> the availability of another skb in the rx queue is not being checked.<br /> <br /> This can lead to crashes:<br /> <br /> [40072.537261] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080<br /> [40072.537407] IP: xenvif_rx_skb+0x23/0x590 [xen_netback]<br /> [40072.537534] PGD 0 P4D 0<br /> [40072.537644] Oops: 0000 [#1] SMP NOPTI<br /> [40072.537749] CPU: 0 PID: 12505 Comm: v1-c40247-q2-gu Not tainted 4.12.14-122.121-default #1 SLE12-SP5<br /> [40072.537867] Hardware name: HP ProLiant DL580 Gen9/ProLiant DL580 Gen9, BIOS U17 11/23/2021<br /> [40072.537999] task: ffff880433b38100 task.stack: ffffc90043d40000<br /> [40072.538112] RIP: e030:xenvif_rx_skb+0x23/0x590 [xen_netback]<br /> [40072.538217] RSP: e02b:ffffc90043d43de0 EFLAGS: 00010246<br /> [40072.538319] RAX: 0000000000000000 RBX: ffffc90043cd7cd0 RCX: 00000000000000f7<br /> [40072.538430] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffffc90043d43df8<br /> [40072.538531] RBP: 000000000000003f R08: 000077ff80000000 R09: 0000000000000008<br /> [40072.538644] R10: 0000000000007ff0 R11: 00000000000008f6 R12: ffffc90043ce2708<br /> [40072.538745] R13: 0000000000000000 R14: ffffc90043d43ed0 R15: ffff88043ea748c0<br /> [40072.538861] FS: 0000000000000000(0000) GS:ffff880484600000(0000) knlGS:0000000000000000<br /> [40072.538988] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [40072.539088] CR2: 0000000000000080 CR3: 0000000407ac8000 CR4: 0000000000040660<br /> [40072.539211] Call Trace:<br /> [40072.539319] xenvif_rx_action+0x71/0x90 [xen_netback]<br /> [40072.539429] xenvif_kthread_guest_rx+0x14a/0x29c [xen_netback]<br /> <br /> Fix that by stopping the loop in case the rx queue becomes empty.
Severity CVSS v4.0: Pending analysis
Last modification:
11/03/2025

CVE-2022-49653

Publication date:
26/02/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: piix4: Fix a memory leak in the EFCH MMIO support<br /> <br /> The recently added support for EFCH MMIO regions introduced a memory<br /> leak in that code path. The leak is caused by the fact that<br /> release_resource() merely removes the resource from the tree but does<br /> not free its memory. We need to call release_mem_region() instead,<br /> which does free the memory. As a nice side effect, this brings back<br /> some symmetry between the legacy and MMIO paths.
Severity CVSS v4.0: Pending analysis
Last modification:
11/03/2025

CVE-2022-49657

Publication date:
26/02/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbnet: fix memory leak in error case<br /> <br /> usbnet_write_cmd_async() mixed up which buffers<br /> need to be freed in which error case.<br /> <br /> v2: add Fixes tag<br /> v3: fix uninitialized buf pointer
Severity CVSS v4.0: Pending analysis
Last modification:
11/03/2025

CVE-2022-49650

Publication date:
26/02/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: qcom: bam_dma: fix runtime PM underflow<br /> <br /> Commit dbad41e7bb5f ("dmaengine: qcom: bam_dma: check if the runtime pm enabled")<br /> caused unbalanced pm_runtime_get/put() calls when the bam is<br /> controlled remotely. This commit reverts it and just enables pm_runtime<br /> in all cases, the clk_* functions already just nop when the clock is NULL.<br /> <br /> Also clean up a bit by removing unnecessary bamclk null checks.
Severity CVSS v4.0: Pending analysis
Last modification:
26/02/2025