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-2021-47056

Publication date:
29/02/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qat - ADF_STATUS_PF_RUNNING should be set after adf_dev_init<br /> <br /> ADF_STATUS_PF_RUNNING is (only) used and checked by adf_vf2pf_shutdown()<br /> before calling adf_iov_putmsg()-&gt;mutex_lock(vf2pf_lock), however the<br /> vf2pf_lock is initialized in adf_dev_init(), which can fail and when it<br /> fail, the vf2pf_lock is either not initialized or destroyed, a subsequent<br /> use of vf2pf_lock will cause issue.<br /> To fix this issue, only set this flag if adf_dev_init() returns 0.<br /> <br /> [ 7.178404] BUG: KASAN: user-memory-access in __mutex_lock.isra.0+0x1ac/0x7c0<br /> [ 7.180345] Call Trace:<br /> [ 7.182576] mutex_lock+0xc9/0xd0<br /> [ 7.183257] adf_iov_putmsg+0x118/0x1a0 [intel_qat]<br /> [ 7.183541] adf_vf2pf_shutdown+0x4d/0x7b [intel_qat]<br /> [ 7.183834] adf_dev_shutdown+0x172/0x2b0 [intel_qat]<br /> [ 7.184127] adf_probe+0x5e9/0x600 [qat_dh895xccvf]
Severity CVSS v4.0: Pending analysis
Last modification:
09/01/2025

CVE-2021-47057

Publication date:
29/02/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: sun8i-ss - Fix memory leak of object d when dma_iv fails to map<br /> <br /> In the case where the dma_iv mapping fails, the return error path leaks<br /> the memory allocated to object d. Fix this by adding a new error return<br /> label and jumping to this to ensure d is free&amp;#39;d before the return.<br /> <br /> Addresses-Coverity: ("Resource leak")
Severity CVSS v4.0: Pending analysis
Last modification:
19/03/2025

CVE-2021-47058

Publication date:
29/02/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regmap: set debugfs_name to NULL after it is freed<br /> <br /> There is a upstream commit cffa4b2122f5("regmap:debugfs:<br /> Fix a memory leak when calling regmap_attach_dev") that<br /> adds a if condition when create name for debugfs_name.<br /> With below function invoking logical, debugfs_name is<br /> freed in regmap_debugfs_exit(), but it is not created again<br /> because of the if condition introduced by above commit.<br /> regmap_reinit_cache()<br /> regmap_debugfs_exit()<br /> ...<br /> regmap_debugfs_init()<br /> So, set debugfs_name to NULL after it is freed.
Severity CVSS v4.0: Pending analysis
Last modification:
10/12/2024

CVE-2021-47059

Publication date:
29/02/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: sun8i-ss - fix result memory leak on error path<br /> <br /> This patch fixes a memory leak on an error path.
Severity CVSS v4.0: Pending analysis
Last modification:
10/12/2024

CVE-2021-47060

Publication date:
29/02/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Stop looking for coalesced MMIO zones if the bus is destroyed<br /> <br /> Abort the walk of coalesced MMIO zones if kvm_io_bus_unregister_dev()<br /> fails to allocate memory for the new instance of the bus. If it can&amp;#39;t<br /> instantiate a new bus, unregister_dev() destroys all devices _except_ the<br /> target device. But, it doesn&amp;#39;t tell the caller that it obliterated the<br /> bus and invoked the destructor for all devices that were on the bus. In<br /> the coalesced MMIO case, this can result in a deleted list entry<br /> dereference due to attempting to continue iterating on coalesced_zones<br /> after future entries (in the walk) have been deleted.<br /> <br /> Opportunistically add curly braces to the for-loop, which encompasses<br /> many lines but sneaks by without braces due to the guts being a single<br /> if statement.
Severity CVSS v4.0: Pending analysis
Last modification:
08/04/2025

CVE-2021-47061

Publication date:
29/02/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Destroy I/O bus devices on unregister failure _after_ sync&amp;#39;ing SRCU<br /> <br /> If allocating a new instance of an I/O bus fails when unregistering a<br /> device, wait to destroy the device until after all readers are guaranteed<br /> to see the new null bus. Destroying devices before the bus is nullified<br /> could lead to use-after-free since readers expect the devices on their<br /> reference of the bus to remain valid.
Severity CVSS v4.0: Pending analysis
Last modification:
10/12/2024

CVE-2021-47062

Publication date:
29/02/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: Use online_vcpus, not created_vcpus, to iterate over vCPUs<br /> <br /> Use the kvm_for_each_vcpu() helper to iterate over vCPUs when encrypting<br /> VMSAs for SEV, which effectively switches to use online_vcpus instead of<br /> created_vcpus. This fixes a possible null-pointer dereference as<br /> created_vcpus does not guarantee a vCPU exists, since it is updated at<br /> the very beginning of KVM_CREATE_VCPU. created_vcpus exists to allow the<br /> bulk of vCPU creation to run in parallel, while still correctly<br /> restricting the max number of max vCPUs.
Severity CVSS v4.0: Pending analysis
Last modification:
10/12/2024

CVE-2021-47063

Publication date:
29/02/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: bridge/panel: Cleanup connector on bridge detach<br /> <br /> If we don&amp;#39;t call drm_connector_cleanup() manually in<br /> panel_bridge_detach(), the connector will be cleaned up with the other<br /> DRM objects in the call to drm_mode_config_cleanup(). However, since our<br /> drm_connector is devm-allocated, by the time drm_mode_config_cleanup()<br /> will be called, our connector will be long gone. Therefore, the<br /> connector must be cleaned up when the bridge is detached to avoid<br /> use-after-free conditions.<br /> <br /> v2: Cleanup connector only if it was created<br /> <br /> v3: Add FIXME<br /> <br /> v4: (Use connector-&gt;dev) directly in if() block
Severity CVSS v4.0: Pending analysis
Last modification:
10/12/2024

CVE-2021-47064

Publication date:
29/02/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: fix potential DMA mapping leak<br /> <br /> With buf uninitialized in mt76_dma_tx_queue_skb_raw, its field skip_unmap<br /> could potentially inherit a non-zero value from stack garbage.<br /> If this happens, it will cause DMA mappings for MCU command frames to not be<br /> unmapped after completion
Severity CVSS v4.0: Pending analysis
Last modification:
08/04/2025

CVE-2024-0068

Publication date:
29/02/2024
Improper Link Resolution Before File Access (&amp;#39;Link Following&amp;#39;) vulnerability in HYPR Workforce Access on MacOS allows File Manipulation.This issue affects Workforce Access: before 8.7.1.<br /> <br />
Severity CVSS v4.0: Pending analysis
Last modification:
04/03/2025

CVE-2024-1595

Publication date:
29/02/2024
Delta Electronics CNCSoft-B DOPSoft prior to v4.0.0.82<br /> <br /> insecurely loads libraries, which may allow an attacker to use DLL hijacking and take over the system where the software is installed.<br /> <br />
Severity CVSS v4.0: Pending analysis
Last modification:
06/03/2025

CVE-2024-26548

Publication date:
29/02/2024
An issue in vivotek Network Camera v.FD8166A-VVTK-0204j allows a remote attacker to execute arbitrary code via a crafted payload to the upload_file.cgi component.
Severity CVSS v4.0: Pending analysis
Last modification:
13/05/2025