Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

Go to Calendar     Go to Press Room     Go to Newsletters subscription

Search

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-2025-21831
Publication date:
06/03/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Avoid putting some root ports into D3 on TUXEDO Sirius Gen1<br /> <br /> commit 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend") sets the<br /> policy that all PCIe ports are allowed to use D3. When the system is<br /> suspended if the port is not power manageable by the platform and won&amp;#39;t be<br /> used for wakeup via a PME this sets up the policy for these ports to go<br /> into D3hot.<br /> <br /> This policy generally makes sense from an OSPM perspective but it leads to<br /> problems with wakeup from suspend on the TUXEDO Sirius 16 Gen 1 with a<br /> specific old BIOS. This manifests as a system hang.<br /> <br /> On the affected Device + BIOS combination, add a quirk for the root port of<br /> the problematic controller to ensure that these root ports are not put into<br /> D3hot at suspend.<br /> <br /> This patch is based on<br /> <br /> https://lore.kernel.org/linux-pci/20230708214457.1229-2-mario.limonciello@amd.com<br /> <br /> but with the added condition both in the documentation and in the code to<br /> apply only to the TUXEDO Sirius 16 Gen 1 with a specific old BIOS and only<br /> the affected root ports.
Severity CVSS v4.0: Pending analysis
Last modification:
29/10/2025

CVE-2025-21833
Publication date:
06/03/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE<br /> <br /> There is a WARN_ON_ONCE to catch an unlikely situation when<br /> domain_remove_dev_pasid can&amp;#39;t find the `pasid`. In case it nevertheless<br /> happens we must avoid using a NULL pointer.
Severity CVSS v4.0: Pending analysis
Last modification:
02/11/2025

CVE-2025-21832
Publication date:
06/03/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: don&amp;#39;t revert iter for -EIOCBQUEUED<br /> <br /> blkdev_read_iter() has a few odd checks, like gating the position and<br /> count adjustment on whether or not the result is bigger-than-or-equal to<br /> zero (where bigger than makes more sense), and not checking the return<br /> value of blkdev_direct_IO() before doing an iov_iter_revert(). The<br /> latter can lead to attempting to revert with a negative value, which<br /> when passed to iov_iter_revert() as an unsigned value will lead to<br /> throwing a WARN_ON() because unroll is bigger than MAX_RW_COUNT.<br /> <br /> Be sane and don&amp;#39;t revert for -EIOCBQUEUED, like what is done in other<br /> spots.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2025-21829
Publication date:
06/03/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix the warning "__rxe_cleanup+0x12c/0x170 [rdma_rxe]"<br /> <br /> The Call Trace is as below:<br /> "<br /> <br /> ? show_regs.cold+0x1a/0x1f<br /> ? __rxe_cleanup+0x12c/0x170 [rdma_rxe]<br /> ? __warn+0x84/0xd0<br /> ? __rxe_cleanup+0x12c/0x170 [rdma_rxe]<br /> ? report_bug+0x105/0x180<br /> ? handle_bug+0x46/0x80<br /> ? exc_invalid_op+0x19/0x70<br /> ? asm_exc_invalid_op+0x1b/0x20<br /> ? __rxe_cleanup+0x12c/0x170 [rdma_rxe]<br /> ? __rxe_cleanup+0x124/0x170 [rdma_rxe]<br /> rxe_destroy_qp.cold+0x24/0x29 [rdma_rxe]<br /> ib_destroy_qp_user+0x118/0x190 [ib_core]<br /> rdma_destroy_qp.cold+0x43/0x5e [rdma_cm]<br /> rtrs_cq_qp_destroy.cold+0x1d/0x2b [rtrs_core]<br /> rtrs_srv_close_work.cold+0x1b/0x31 [rtrs_server]<br /> process_one_work+0x21d/0x3f0<br /> worker_thread+0x4a/0x3c0<br /> ? process_one_work+0x3f0/0x3f0<br /> kthread+0xf0/0x120<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x22/0x30<br /> <br /> "<br /> When too many rdma resources are allocated, rxe needs more time to<br /> handle these rdma resources. Sometimes with the current timeout, rxe<br /> can not release the rdma resources correctly.<br /> <br /> Compared with other rdma drivers, a bigger timeout is used.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2025-21830
Publication date:
06/03/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> landlock: Handle weird files<br /> <br /> A corrupted filesystem (e.g. bcachefs) might return weird files.<br /> Instead of throwing a warning and allowing access to such file, treat<br /> them as regular files.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-58086
Publication date:
06/03/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Stop active perfmon if it is being destroyed<br /> <br /> If the active performance monitor (`v3d-&gt;active_perfmon`) is being<br /> destroyed, stop it first. Currently, the active perfmon is not<br /> stopped during destruction, leaving the `v3d-&gt;active_perfmon` pointer<br /> stale. This can lead to undefined behavior and instability.<br /> <br /> This patch ensures that the active perfmon is stopped before being<br /> destroyed, aligning with the behavior introduced in commit<br /> 7d1fd3638ee3 ("drm/v3d: Stop the active perfmon before being destroyed").
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2025-0337
Publication date:
06/03/2025
ServiceNow has addressed an authorization bypass vulnerability that was identified in the Washington release of the Now Platform. This vulnerability, if exploited, potentially could enable an authenticated user to access unauthorized data stored within the Now Platform that the user otherwise would not be entitled to access. <br /> <br /> This issue is addressed in the listed patches and family release, which have been made available to hosted and self-hosted customers, as well as partners.
Severity CVSS v4.0: HIGH
Last modification:
15/04/2026

CVE-2024-58082
Publication date:
06/03/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: nuvoton: Fix an error check in npcm_video_ece_init()<br /> <br /> When function of_find_device_by_node() fails, it returns NULL instead of<br /> an error code. So the corresponding error check logic should be modified<br /> to check whether the return value is NULL and set the error code to be<br /> returned as -ENODEV.
Severity CVSS v4.0: Pending analysis
Last modification:
31/10/2025

CVE-2024-58078
Publication date:
06/03/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: misc_minor_alloc to use ida for all dynamic/misc dynamic minors<br /> <br /> misc_minor_alloc was allocating id using ida for minor only in case of<br /> MISC_DYNAMIC_MINOR but misc_minor_free was always freeing ids<br /> using ida_free causing a mismatch and following warn:<br /> &gt; &gt; WARNING: CPU: 0 PID: 159 at lib/idr.c:525 ida_free+0x3e0/0x41f<br /> &gt; &gt; ida_free called for id=127 which is not allocated.<br /> &gt; &gt;
Severity CVSS v4.0: Pending analysis
Last modification:
31/10/2025

CVE-2024-58081
Publication date:
06/03/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: mmp2: call pm_genpd_init() only after genpd.name is set<br /> <br /> Setting the genpd&amp;#39;s struct device&amp;#39;s name with dev_set_name() is<br /> happening within pm_genpd_init(). If it remains NULL, things can blow up<br /> later, such as when crafting the devfs hierarchy for the power domain:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read<br /> ...<br /> Call trace:<br /> strlen from start_creating+0x90/0x138<br /> start_creating from debugfs_create_dir+0x20/0x178<br /> debugfs_create_dir from genpd_debug_add.part.0+0x4c/0x144<br /> genpd_debug_add.part.0 from genpd_debug_init+0x74/0x90<br /> genpd_debug_init from do_one_initcall+0x5c/0x244<br /> do_one_initcall from kernel_init_freeable+0x19c/0x1f4<br /> kernel_init_freeable from kernel_init+0x1c/0x12c<br /> kernel_init from ret_from_fork+0x14/0x28<br /> <br /> Bisecting tracks this crash back to commit 899f44531fe6 ("pmdomain: core:<br /> Add GENPD_FLAG_DEV_NAME_FW flag"), which exchanges use of genpd-&gt;name<br /> with dev_name(&amp;genpd-&gt;dev) in genpd_debug_add.part().
Severity CVSS v4.0: Pending analysis
Last modification:
01/10/2025

CVE-2024-58084
Publication date:
06/03/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: qcom: scm: Fix missing read barrier in qcom_scm_get_tzmem_pool()<br /> <br /> Commit 2e4955167ec5 ("firmware: qcom: scm: Fix __scm and waitq<br /> completion variable initialization") introduced a write barrier in probe<br /> function to store global &amp;#39;__scm&amp;#39; variable. We all known barriers are<br /> paired (see memory-barriers.txt: "Note that write barriers should<br /> normally be paired with read or address-dependency barriers"), therefore<br /> accessing it from concurrent contexts requires read barrier. Previous<br /> commit added such barrier in qcom_scm_is_available(), so let&amp;#39;s use that<br /> directly.<br /> <br /> Lack of this read barrier can result in fetching stale &amp;#39;__scm&amp;#39; variable<br /> value, NULL, and dereferencing it.<br /> <br /> Note that barrier in qcom_scm_is_available() satisfies here the control<br /> dependency.
Severity CVSS v4.0: Pending analysis
Last modification:
01/10/2025

CVE-2024-58077
Publication date:
06/03/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: soc-pcm: don&amp;#39;t use soc_pcm_ret() on .prepare callback<br /> <br /> commit 1f5664351410 ("ASoC: lower "no backend DAIs enabled for ... Port"<br /> log severity") ignores -EINVAL error message on common soc_pcm_ret().<br /> It is used from many functions, ignoring -EINVAL is over-kill.<br /> <br /> The reason why -EINVAL was ignored was it really should only be used<br /> upon invalid parameters coming from userspace and in that case we don&amp;#39;t<br /> want to log an error since we do not want to give userspace a way to do<br /> a denial-of-service attack on the syslog / diskspace.<br /> <br /> So don&amp;#39;t use soc_pcm_ret() on .prepare callback is better idea.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025
Subscribe to Vulnerabilities