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

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio: Split migration ops from main device ops<br /> <br /> vfio core checks whether the driver sets some migration op (e.g.<br /> set_state/get_state) and accordingly calls its op.<br /> <br /> However, currently mlx5 driver sets the above ops without regards to its<br /> migration caps.<br /> <br /> This might lead to unexpected usage/Oops if user space may call to the<br /> above ops even if the driver doesn&amp;#39;t support migration. As for example,<br /> the migration state_mutex is not initialized in that case.<br /> <br /> The cleanest way to manage that seems to split the migration ops from<br /> the main device ops, this will let the driver setting them separately<br /> from the main ops when it&amp;#39;s applicable.<br /> <br /> As part of that, validate ops construction on registration and include a<br /> check for VFIO_MIGRATION_STOP_COPY since the uAPI claims it must be set<br /> in migration_flags.<br /> <br /> HISI driver was changed as well to match this scheme.<br /> <br /> This scheme may enable down the road to come with some extra group of<br /> ops (e.g. DMA log) that can be set without regards to the other options<br /> based on driver caps.
Severity CVSS v4.0: Pending analysis
Last modification:
18/06/2025

CVE-2022-50118

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/perf: Optimize clearing the pending PMI and remove WARN_ON for PMI check in power_pmu_disable<br /> <br /> commit 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear<br /> pending PMI before resetting an overflown PMC") added a new<br /> function "pmi_irq_pending" in hw_irq.h. This function is to check<br /> if there is a PMI marked as pending in Paca (PACA_IRQ_PMI).This is<br /> used in power_pmu_disable in a WARN_ON. The intention here is to<br /> provide a warning if there is PMI pending, but no counter is found<br /> overflown.<br /> <br /> During some of the perf runs, below warning is hit:<br /> <br /> WARNING: CPU: 36 PID: 0 at arch/powerpc/perf/core-book3s.c:1332 power_pmu_disable+0x25c/0x2c0<br /> Modules linked in:<br /> -----<br /> <br /> NIP [c000000000141c3c] power_pmu_disable+0x25c/0x2c0<br /> LR [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0<br /> Call Trace:<br /> [c000000baffcfb90] [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 (unreliable)<br /> [c000000baffcfc10] [c0000000003e2f8c] perf_pmu_disable+0x4c/0x60<br /> [c000000baffcfc30] [c0000000003e3344] group_sched_out.part.124+0x44/0x100<br /> [c000000baffcfc80] [c0000000003e353c] __perf_event_disable+0x13c/0x240<br /> [c000000baffcfcd0] [c0000000003dd334] event_function+0xc4/0x140<br /> [c000000baffcfd20] [c0000000003d855c] remote_function+0x7c/0xa0<br /> [c000000baffcfd50] [c00000000026c394] flush_smp_call_function_queue+0xd4/0x300<br /> [c000000baffcfde0] [c000000000065b24] smp_ipi_demux_relaxed+0xa4/0x100<br /> [c000000baffcfe20] [c0000000000cb2b0] xive_muxed_ipi_action+0x20/0x40<br /> [c000000baffcfe40] [c000000000207c3c] __handle_irq_event_percpu+0x8c/0x250<br /> [c000000baffcfee0] [c000000000207e2c] handle_irq_event_percpu+0x2c/0xa0<br /> [c000000baffcff10] [c000000000210a04] handle_percpu_irq+0x84/0xc0<br /> [c000000baffcff40] [c000000000205f14] generic_handle_irq+0x54/0x80<br /> [c000000baffcff60] [c000000000015740] __do_irq+0x90/0x1d0<br /> [c000000baffcff90] [c000000000016990] __do_IRQ+0xc0/0x140<br /> [c0000009732f3940] [c000000bafceaca8] 0xc000000bafceaca8<br /> [c0000009732f39d0] [c000000000016b78] do_IRQ+0x168/0x1c0<br /> [c0000009732f3a00] [c0000000000090c8] hardware_interrupt_common_virt+0x218/0x220<br /> <br /> This means that there is no PMC overflown among the active events<br /> in the PMU, but there is a PMU pending in Paca. The function<br /> "any_pmc_overflown" checks the PMCs on active events in<br /> cpuhw-&gt;n_events. Code snippet:<br /> <br /> <br /> if (any_pmc_overflown(cpuhw))<br /> clear_pmi_irq_pending();<br /> else<br /> WARN_ON(pmi_irq_pending());<br /> <br /> <br /> Here the PMC overflown is not from active event. Example: When we do<br /> perf record, default cycles and instructions will be running on PMC6<br /> and PMC5 respectively. It could happen that overflowed event is currently<br /> not active and pending PMI is for the inactive event. Debug logs from<br /> trace_printk:<br /> <br /> <br /> any_pmc_overflown: idx is 5: pmc value is 0xd9a<br /> power_pmu_disable: PMC1: 0x0, PMC2: 0x0, PMC3: 0x0, PMC4: 0x0, PMC5: 0xd9a, PMC6: 0x80002011<br /> <br /> <br /> Here active PMC (from idx) is PMC5 , but overflown PMC is PMC6(0x80002011).<br /> When we handle PMI interrupt for such cases, if the PMC overflown is<br /> from inactive event, it will be ignored. Reference commit:<br /> commit bc09c219b2e6 ("powerpc/perf: Fix finding overflowed PMC in interrupt")<br /> <br /> Patch addresses two changes:<br /> 1) Fix 1 : Removal of warning ( WARN_ON(pmi_irq_pending()); )<br /> We were printing warning if no PMC is found overflown among active PMU<br /> events, but PMI pending in PACA. But this could happen in cases where<br /> PMC overflown is not in active PMC. An inactive event could have caused<br /> the overflow. Hence the warning is not needed. To know pending PMI is<br /> from an inactive event, we need to loop through all PMC&amp;#39;s which will<br /> cause more SPR reads via mfspr and increase in context switch. Also in<br /> existing function: perf_event_interrupt, already we ignore PMI&amp;#39;s<br /> overflown when it is from an inactive PMC.<br /> <br /> 2) Fix 2: optimization in clearing pending PMI.<br /> Currently we check for any active PMC overflown before clearing PMI<br /> pending in Paca. This is causing additional SP<br /> ---truncated---
Severity CVSS v4.0: Pending analysis
Last modification:
18/06/2025

CVE-2022-50119

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rpmsg: Fix possible refcount leak in rpmsg_register_device_override()<br /> <br /> rpmsg_register_device_override need to call put_device to free vch when<br /> driver_set_override fails.<br /> <br /> Fix this by adding a put_device() to the error path.
Severity CVSS v4.0: Pending analysis
Last modification:
18/06/2025

CVE-2022-50120

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: imx_rproc: Fix refcount leak in imx_rproc_addr_init<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 /> This function has two paths missing of_node_put().
Severity CVSS v4.0: Pending analysis
Last modification:
18/06/2025

CVE-2022-50121

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: k3-r5: Fix refcount leak in k3_r5_cluster_of_init<br /> <br /> Every iteration of for_each_available_child_of_node() decrements<br /> the reference count of the previous node.<br /> When breaking early from a for_each_available_child_of_node() loop,<br /> we need to explicitly call of_node_put() on the child node.<br /> Add missing of_node_put() to avoid refcount leak.
Severity CVSS v4.0: Pending analysis
Last modification:
18/06/2025

CVE-2022-50122

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: mt8173-rt5650: Fix refcount leak in mt8173_rt5650_dev_probe<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Fix refcount leak in some error paths.
Severity CVSS v4.0: Pending analysis
Last modification:
18/06/2025

CVE-2022-50106

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/cell/axon_msi: Fix refcount leak in setup_msi_msg_address<br /> <br /> of_get_next_parent() returns a node pointer with refcount incremented,<br /> we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() in the error path to avoid refcount leak.
Severity CVSS v4.0: Pending analysis
Last modification:
18/06/2025

CVE-2022-50107

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix memory leak when using fscache<br /> <br /> If we hit the &amp;#39;index == next_cached&amp;#39; case, we leak a refcount on the<br /> struct page. Fix this by using readahead_folio() which takes care of<br /> the refcount for you.
Severity CVSS v4.0: Pending analysis
Last modification:
18/06/2025

CVE-2022-50108

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mfd: max77620: Fix refcount leak in max77620_initialise_fps<br /> <br /> of_get_child_by_name() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.
Severity CVSS v4.0: Pending analysis
Last modification:
18/06/2025

CVE-2022-50109

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> video: fbdev: amba-clcd: Fix refcount leak bugs<br /> <br /> In clcdfb_of_init_display(), we should call of_node_put() for the<br /> references returned by of_graph_get_next_endpoint() and<br /> of_graph_get_remote_port_parent() which have increased the refcount.<br /> <br /> Besides, we should call of_node_put() both in fail path or when<br /> the references are not used anymore.
Severity CVSS v4.0: Pending analysis
Last modification:
18/06/2025

CVE-2022-50110

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watchdog: sp5100_tco: 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:
18/06/2025

CVE-2022-50111

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mt6359: Fix refcount leak bug<br /> <br /> In mt6359_parse_dt() and mt6359_accdet_parse_dt(), we should call<br /> of_node_put() for the reference returned by of_get_child_by_name()<br /> which has increased the refcount.
Severity CVSS v4.0: Pending analysis
Last modification:
18/06/2025