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

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

CVE-2022-49882

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Reject attempts to consume or refresh inactive gfn_to_pfn_cache<br /> <br /> Reject kvm_gpc_check() and kvm_gpc_refresh() if the cache is inactive.<br /> Not checking the active flag during refresh is particularly egregious, as<br /> KVM can end up with a valid, inactive cache, which can lead to a variety<br /> of use-after-free bugs, e.g. consuming a NULL kernel pointer or missing<br /> an mmu_notifier invalidation due to the cache not being on the list of<br /> gfns to invalidate.<br /> <br /> Note, "active" needs to be set if and only if the cache is on the list<br /> of caches, i.e. is reachable via mmu_notifier events. If a relevant<br /> mmu_notifier event occurs while the cache is "active" but not on the<br /> list, KVM will not acquire the cache&amp;#39;s lock and so will not serailize<br /> the mmu_notifier event with active users and/or kvm_gpc_refresh().<br /> <br /> A race between KVM_XEN_ATTR_TYPE_SHARED_INFO and KVM_XEN_HVM_EVTCHN_SEND<br /> can be exploited to trigger the bug.<br /> <br /> 1. Deactivate shinfo cache:<br /> <br /> kvm_xen_hvm_set_attr<br /> case KVM_XEN_ATTR_TYPE_SHARED_INFO<br /> kvm_gpc_deactivate<br /> kvm_gpc_unmap<br /> gpc-&gt;valid = false<br /> gpc-&gt;khva = NULL<br /> gpc-&gt;active = false<br /> <br /> Result: active = false, valid = false<br /> <br /> 2. Cause cache refresh:<br /> <br /> kvm_arch_vm_ioctl<br /> case KVM_XEN_HVM_EVTCHN_SEND<br /> kvm_xen_hvm_evtchn_send<br /> kvm_xen_set_evtchn<br /> kvm_xen_set_evtchn_fast<br /> kvm_gpc_check<br /> return -EWOULDBLOCK because !gpc-&gt;valid<br /> kvm_xen_set_evtchn_fast<br /> return -EWOULDBLOCK<br /> kvm_gpc_refresh<br /> hva_to_pfn_retry<br /> gpc-&gt;valid = true<br /> gpc-&gt;khva = not NULL<br /> <br /> Result: active = false, valid = true<br /> <br /> 3. Race ioctl KVM_XEN_HVM_EVTCHN_SEND against ioctl<br /> KVM_XEN_ATTR_TYPE_SHARED_INFO:<br /> <br /> kvm_arch_vm_ioctl<br /> case KVM_XEN_HVM_EVTCHN_SEND<br /> kvm_xen_hvm_evtchn_send<br /> kvm_xen_set_evtchn<br /> kvm_xen_set_evtchn_fast<br /> read_lock gpc-&gt;lock<br /> kvm_xen_hvm_set_attr case<br /> KVM_XEN_ATTR_TYPE_SHARED_INFO<br /> mutex_lock kvm-&gt;lock<br /> kvm_xen_shared_info_init<br /> kvm_gpc_activate<br /> gpc-&gt;khva = NULL<br /> kvm_gpc_check<br /> [ Check passes because gpc-&gt;valid is<br /> still true, even though gpc-&gt;khva<br /> is already NULL. ]<br /> shinfo = gpc-&gt;khva<br /> pending_bits = shinfo-&gt;evtchn_pending<br /> CRASH: test_and_set_bit(..., pending_bits)
Severity CVSS v4.0: Pending analysis
Last modification:
02/05/2025

CVE-2022-49883

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: smm: number of GPRs in the SMRAM image depends on the image format<br /> <br /> On 64 bit host, if the guest doesn&amp;#39;t have X86_FEATURE_LM, KVM will<br /> access 16 gprs to 32-bit smram image, causing out-ouf-bound ram<br /> access.<br /> <br /> On 32 bit host, the rsm_load_state_64/enter_smm_save_state_64<br /> is compiled out, thus access overflow can&amp;#39;t happen.
Severity CVSS v4.0: Pending analysis
Last modification:
02/05/2025

CVE-2022-49884

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Initialize gfn_to_pfn_cache locks in dedicated helper<br /> <br /> Move the gfn_to_pfn_cache lock initialization to another helper and<br /> call the new helper during VM/vCPU creation. There are race<br /> conditions possible due to kvm_gfn_to_pfn_cache_init()&amp;#39;s<br /> ability to re-initialize the cache&amp;#39;s locks.<br /> <br /> For example: a race between ioctl(KVM_XEN_HVM_EVTCHN_SEND) and<br /> kvm_gfn_to_pfn_cache_init() leads to a corrupted shinfo gpc lock.<br /> <br /> (thread 1) | (thread 2)<br /> |<br /> kvm_xen_set_evtchn_fast |<br /> read_lock_irqsave(&amp;gpc-&gt;lock, ...) |<br /> | kvm_gfn_to_pfn_cache_init<br /> | rwlock_init(&amp;gpc-&gt;lock)<br /> read_unlock_irqrestore(&amp;gpc-&gt;lock, ...) |<br /> <br /> Rename "cache_init" and "cache_destroy" to activate+deactivate to<br /> avoid implying that the cache really is destroyed/freed.<br /> <br /> Note, there more races in the newly named kvm_gpc_activate() that will<br /> be addressed separately.<br /> <br /> [sean: call out that this is a bug fix]
Severity CVSS v4.0: Pending analysis
Last modification:
02/05/2025

CVE-2022-49886

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/tdx: Panic on bad configs that #VE on "private" memory access<br /> <br /> All normal kernel memory is "TDX private memory". This includes<br /> everything from kernel stacks to kernel text. Handling<br /> exceptions on arbitrary accesses to kernel memory is essentially<br /> impossible because they can happen in horribly nasty places like<br /> kernel entry/exit. But, TDX hardware can theoretically _deliver_<br /> a virtualization exception (#VE) on any access to private memory.<br /> <br /> But, it&amp;#39;s not as bad as it sounds. TDX can be configured to never<br /> deliver these exceptions on private memory with a "TD attribute"<br /> called ATTR_SEPT_VE_DISABLE. The guest has no way to *set* this<br /> attribute, but it can check it.<br /> <br /> Ensure ATTR_SEPT_VE_DISABLE is set in early boot. panic() if it<br /> is unset. There is no sane way for Linux to run with this<br /> attribute clear so a panic() is appropriate.<br /> <br /> There&amp;#39;s small window during boot before the check where kernel<br /> has an early #VE handler. But the handler is only for port I/O<br /> and will also panic() as soon as it sees any other #VE, such as<br /> a one generated by a private memory access.<br /> <br /> [ dhansen: Rewrite changelog and rebase on new tdx_parse_tdinfo().<br /> Add Kirill&amp;#39;s tested-by because I made changes since<br /> he wrote this. ]
Severity CVSS v4.0: Pending analysis
Last modification:
02/05/2025

CVE-2022-49889

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Check for NULL cpu_buffer in ring_buffer_wake_waiters()<br /> <br /> On some machines the number of listed CPUs may be bigger than the actual<br /> CPUs that exist. The tracing subsystem allocates a per_cpu directory with<br /> access to the per CPU ring buffer via a cpuX file. But to save space, the<br /> ring buffer will only allocate buffers for online CPUs, even though the<br /> CPU array will be as big as the nr_cpu_ids.<br /> <br /> With the addition of waking waiters on the ring buffer when closing the<br /> file, the ring_buffer_wake_waiters() now needs to make sure that the<br /> buffer is allocated (with the irq_work allocated with it) before trying to<br /> wake waiters, as it will cause a NULL pointer dereference.<br /> <br /> While debugging this, I added a NULL check for the buffer itself (which is<br /> OK to do), and also NULL pointer checks against buffer-&gt;buffers (which is<br /> not fine, and will WARN) as well as making sure the CPU number passed in<br /> is within the nr_cpu_ids (which is also not fine if it isn&amp;#39;t).<br /> <br /> <br /> Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1204705
Severity CVSS v4.0: Pending analysis
Last modification:
07/05/2025

CVE-2022-49888

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: entry: avoid kprobe recursion<br /> <br /> The cortex_a76_erratum_1463225_debug_handler() function is called when<br /> handling debug exceptions (and synchronous exceptions from BRK<br /> instructions), and so is called when a probed function executes. If the<br /> compiler does not inline cortex_a76_erratum_1463225_debug_handler(), it<br /> can be probed.<br /> <br /> If cortex_a76_erratum_1463225_debug_handler() is probed, any debug<br /> exception or software breakpoint exception will result in recursive<br /> exceptions leading to a stack overflow. This can be triggered with the<br /> ftrace multiple_probes selftest, and as per the example splat below.<br /> <br /> This is a regression caused by commit:<br /> <br /> 6459b8469753e9fe ("arm64: entry: consolidate Cortex-A76 erratum 1463225 workaround")<br /> <br /> ... which removed the NOKPROBE_SYMBOL() annotation associated with the<br /> function.<br /> <br /> My intent was that cortex_a76_erratum_1463225_debug_handler() would be<br /> inlined into its caller, el1_dbg(), which is marked noinstr and cannot<br /> be probed. Mark cortex_a76_erratum_1463225_debug_handler() as<br /> __always_inline to ensure this.<br /> <br /> Example splat prior to this patch (with recursive entries elided):<br /> <br /> | # echo p cortex_a76_erratum_1463225_debug_handler &gt; /sys/kernel/debug/tracing/kprobe_events<br /> | # echo p do_el0_svc &gt;&gt; /sys/kernel/debug/tracing/kprobe_events<br /> | # echo 1 &gt; /sys/kernel/debug/tracing/events/kprobes/enable<br /> | Insufficient stack space to handle exception!<br /> | ESR: 0x0000000096000047 -- DABT (current EL)<br /> | FAR: 0xffff800009cefff0<br /> | Task stack: [0xffff800009cf0000..0xffff800009cf4000]<br /> | IRQ stack: [0xffff800008000000..0xffff800008004000]<br /> | Overflow stack: [0xffff00007fbc00f0..0xffff00007fbc10f0]<br /> | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2<br /> | Hardware name: linux,dummy-virt (DT)<br /> | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> | pc : arm64_enter_el1_dbg+0x4/0x20<br /> | lr : el1_dbg+0x24/0x5c<br /> | sp : ffff800009cf0000<br /> | x29: ffff800009cf0000 x28: ffff000002c74740 x27: 0000000000000000<br /> | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000<br /> | x23: 00000000604003c5 x22: ffff80000801745c x21: 0000aaaac95ac068<br /> | x20: 00000000f2000004 x19: ffff800009cf0040 x18: 0000000000000000<br /> | x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> | x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> | x11: 0000000000000010 x10: ffff800008c87190 x9 : ffff800008ca00d0<br /> | x8 : 000000000000003c x7 : 0000000000000000 x6 : 0000000000000000<br /> | x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000043a4<br /> | x2 : 00000000f2000004 x1 : 00000000f2000004 x0 : ffff800009cf0040<br /> | Kernel panic - not syncing: kernel stack overflow<br /> | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2<br /> | Hardware name: linux,dummy-virt (DT)<br /> | Call trace:<br /> | dump_backtrace+0xe4/0x104<br /> | show_stack+0x18/0x4c<br /> | dump_stack_lvl+0x64/0x7c<br /> | dump_stack+0x18/0x38<br /> | panic+0x14c/0x338<br /> | test_taint+0x0/0x2c<br /> | panic_bad_stack+0x104/0x118<br /> | handle_bad_stack+0x34/0x48<br /> | __bad_stack+0x78/0x7c<br /> | arm64_enter_el1_dbg+0x4/0x20<br /> | el1h_64_sync_handler+0x40/0x98<br /> | el1h_64_sync+0x64/0x68<br /> | cortex_a76_erratum_1463225_debug_handler+0x0/0x34<br /> ...<br /> | el1h_64_sync_handler+0x40/0x98<br /> | el1h_64_sync+0x64/0x68<br /> | cortex_a76_erratum_1463225_debug_handler+0x0/0x34<br /> ...<br /> | el1h_64_sync_handler+0x40/0x98<br /> | el1h_64_sync+0x64/0x68<br /> | cortex_a76_erratum_1463225_debug_handler+0x0/0x34<br /> | el1h_64_sync_handler+0x40/0x98<br /> | el1h_64_sync+0x64/0x68<br /> | do_el0_svc+0x0/0x28<br /> | el0t_64_sync_handler+0x84/0xf0<br /> | el0t_64_sync+0x18c/0x190<br /> | Kernel Offset: disabled<br /> | CPU features: 0x0080,00005021,19001080<br /> | Memory Limit: none<br /> | ---[ end Kernel panic - not syncing: kernel stack overflow ]---<br /> <br /> With this patch, cortex_a76_erratum_1463225_debug_handler() is inlined<br /> into el1_dbg(), and el1_dbg() cannot be probed:<br /> <br /> | # echo p cortex_a76_erratum_1463225_debug_handler &gt; /sys/kernel/debug/tracing/kprobe_events<br /> | sh: write error: No such file or directory<br /> | # grep -w cortex_a76_errat<br /> ---truncated---
Severity CVSS v4.0: Pending analysis
Last modification:
07/05/2025

CVE-2022-49887

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: meson: vdec: fix possible refcount leak in vdec_probe()<br /> <br /> v4l2_device_unregister need to be called to put the refcount got by<br /> v4l2_device_register when vdec_probe fails or vdec_remove is called.
Severity CVSS v4.0: Pending analysis
Last modification:
07/05/2025

CVE-2022-49885

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: APEI: Fix integer overflow in ghes_estatus_pool_init()<br /> <br /> Change num_ghes from int to unsigned int, preventing an overflow<br /> and causing subsequent vmalloc() to fail.<br /> <br /> The overflow happens in ghes_estatus_pool_init() when calculating<br /> len during execution of the statement below as both multiplication<br /> operands here are signed int:<br /> <br /> len += (num_ghes * GHES_ESOURCE_PREALLOC_MAX_SIZE);<br /> <br /> The following call trace is observed because of this bug:<br /> <br /> [ 9.317108] swapper/0: vmalloc error: size 18446744071562596352, exceeds total pages, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0-1<br /> [ 9.317131] Call Trace:<br /> [ 9.317134] <br /> [ 9.317137] dump_stack_lvl+0x49/0x5f<br /> [ 9.317145] dump_stack+0x10/0x12<br /> [ 9.317146] warn_alloc.cold+0x7b/0xdf<br /> [ 9.317150] ? __device_attach+0x16a/0x1b0<br /> [ 9.317155] __vmalloc_node_range+0x702/0x740<br /> [ 9.317160] ? device_add+0x17f/0x920<br /> [ 9.317164] ? dev_set_name+0x53/0x70<br /> [ 9.317166] ? platform_device_add+0xf9/0x240<br /> [ 9.317168] __vmalloc_node+0x49/0x50<br /> [ 9.317170] ? ghes_estatus_pool_init+0x43/0xa0<br /> [ 9.317176] vmalloc+0x21/0x30<br /> [ 9.317177] ghes_estatus_pool_init+0x43/0xa0<br /> [ 9.317179] acpi_hest_init+0x129/0x19c<br /> [ 9.317185] acpi_init+0x434/0x4a4<br /> [ 9.317188] ? acpi_sleep_proc_init+0x2a/0x2a<br /> [ 9.317190] do_one_initcall+0x48/0x200<br /> [ 9.317195] kernel_init_freeable+0x221/0x284<br /> [ 9.317200] ? rest_init+0xe0/0xe0<br /> [ 9.317204] kernel_init+0x1a/0x130<br /> [ 9.317205] ret_from_fork+0x22/0x30<br /> [ 9.317208] <br /> <br /> [ rjw: Subject and changelog edits ]
Severity CVSS v4.0: Pending analysis
Last modification:
07/05/2025

CVE-2022-49881

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: fix memory leak in query_regdb_file()<br /> <br /> In the function query_regdb_file() the alpha2 parameter is duplicated<br /> using kmemdup() and subsequently freed in regdb_fw_cb(). However,<br /> request_firmware_nowait() can fail without calling regdb_fw_cb() and<br /> thus leak memory.
Severity CVSS v4.0: Pending analysis
Last modification:
07/05/2025

CVE-2022-49872

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: gso: fix panic on frag_list with mixed head alloc types<br /> <br /> Since commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when<br /> splitting gso_size mangled skb having linear-headed frag_list"), it is<br /> allowed to change gso_size of a GRO packet. However, that commit assumes<br /> that "checking the first list_skb member suffices; i.e if either of the<br /> list_skb members have non head_frag head, then the first one has too".<br /> <br /> It turns out this assumption does not hold. We&amp;#39;ve seen BUG_ON being hit<br /> in skb_segment when skbs on the frag_list had differing head_frag with<br /> the vmxnet3 driver. This happens because __netdev_alloc_skb and<br /> __napi_alloc_skb can return a skb that is page backed or kmalloced<br /> depending on the requested size. As the result, the last small skb in<br /> the GRO packet can be kmalloced.<br /> <br /> There are three different locations where this can be fixed:<br /> <br /> (1) We could check head_frag in GRO and not allow GROing skbs with<br /> different head_frag. However, that would lead to performance<br /> regression on normal forward paths with unmodified gso_size, where<br /> !head_frag in the last packet is not a problem.<br /> <br /> (2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating<br /> that NETIF_F_SG is undesirable. That would need to eat a bit in<br /> sk_buff. Furthermore, that flag can be unset when all skbs on the<br /> frag_list are page backed. To retain good performance,<br /> bpf_skb_net_grow/shrink would have to walk the frag_list.<br /> <br /> (3) Walk the frag_list in skb_segment when determining whether<br /> NETIF_F_SG should be cleared. This of course slows things down.<br /> <br /> This patch implements (3). To limit the performance impact in<br /> skb_segment, the list is walked only for skbs with SKB_GSO_DODGY set<br /> that have gso_size changed. Normal paths thus will not hit it.<br /> <br /> We could check only the last skb but since we need to walk the whole<br /> list anyway, let&amp;#39;s stay on the safe side.
Severity CVSS v4.0: Pending analysis
Last modification:
02/05/2025

CVE-2022-49877

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix the sk-&gt;sk_forward_alloc warning of sk_stream_kill_queues<br /> <br /> When running `test_sockmap` selftests, the following warning appears:<br /> <br /> WARNING: CPU: 2 PID: 197 at net/core/stream.c:205 sk_stream_kill_queues+0xd3/0xf0<br /> Call Trace:<br /> <br /> inet_csk_destroy_sock+0x55/0x110<br /> tcp_rcv_state_process+0xd28/0x1380<br /> ? tcp_v4_do_rcv+0x77/0x2c0<br /> tcp_v4_do_rcv+0x77/0x2c0<br /> __release_sock+0x106/0x130<br /> __tcp_close+0x1a7/0x4e0<br /> tcp_close+0x20/0x70<br /> inet_release+0x3c/0x80<br /> __sock_release+0x3a/0xb0<br /> sock_close+0x14/0x20<br /> __fput+0xa3/0x260<br /> task_work_run+0x59/0xb0<br /> exit_to_user_mode_prepare+0x1b3/0x1c0<br /> syscall_exit_to_user_mode+0x19/0x50<br /> do_syscall_64+0x48/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> The root case is in commit 84472b436e76 ("bpf, sockmap: Fix more uncharged<br /> while msg has more_data"), where I used msg-&gt;sg.size to replace the tosend,<br /> causing breakage:<br /> <br /> if (msg-&gt;apply_bytes &amp;&amp; msg-&gt;apply_bytes apply_bytes;
Severity CVSS v4.0: Pending analysis
Last modification:
02/05/2025