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-2024-42091

Publication date:
29/07/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Check pat.ops before dumping PAT settings<br /> <br /> We may leave pat.ops unset when running on brand new platform or<br /> when running as a VF. While the former is unlikely, the latter<br /> is valid (future) use case and will cause NPD when someone will<br /> try to dump PAT settings by debugfs.<br /> <br /> It&amp;#39;s better to check pointer to pat.ops instead of specific .dump<br /> hook, as we have this hook always defined for every .ops variant.
Severity CVSS v4.0: Pending analysis
Last modification:
07/10/2025

CVE-2024-42092

Publication date:
29/07/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: davinci: Validate the obtained number of IRQs<br /> <br /> Value of pdata-&gt;gpio_unbanked is taken from Device Tree. In case of broken<br /> DT due to any error this value can be any. Without this value validation<br /> there can be out of chips-&gt;irqs array boundaries access in<br /> davinci_gpio_probe().<br /> <br /> Validate the obtained nirq value so that it won&amp;#39;t exceed the maximum<br /> number of IRQs per bank.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-42093

Publication date:
29/07/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/dpaa2: Avoid explicit cpumask var allocation on stack<br /> <br /> For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask<br /> variable on stack is not recommended since it can cause potential stack<br /> overflow.<br /> <br /> Instead, kernel code should always use *cpumask_var API(s) to allocate<br /> cpumask var in config-neutral way, leaving allocation strategy to<br /> CONFIG_CPUMASK_OFFSTACK.<br /> <br /> Use *cpumask_var API(s) to address it.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-42094

Publication date:
29/07/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/iucv: Avoid explicit cpumask var allocation on stack<br /> <br /> For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask<br /> variable on stack is not recommended since it can cause potential stack<br /> overflow.<br /> <br /> Instead, kernel code should always use *cpumask_var API(s) to allocate<br /> cpumask var in config-neutral way, leaving allocation strategy to<br /> CONFIG_CPUMASK_OFFSTACK.<br /> <br /> Use *cpumask_var API(s) to address it.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-42088

Publication date:
29/07/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: mt8195: Add platform entry for ETDM1_OUT_BE dai link<br /> <br /> Commit e70b8dd26711 ("ASoC: mediatek: mt8195: Remove afe-dai component<br /> and rework codec link") removed the codec entry for the ETDM1_OUT_BE<br /> dai link entirely instead of replacing it with COMP_EMPTY(). This worked<br /> by accident as the remaining COMP_EMPTY() platform entry became the codec<br /> entry, and the platform entry became completely empty, effectively the<br /> same as COMP_DUMMY() since snd_soc_fill_dummy_dai() doesn&amp;#39;t do anything<br /> for platform entries.<br /> <br /> This causes a KASAN out-of-bounds warning in mtk_soundcard_common_probe()<br /> in sound/soc/mediatek/common/mtk-soundcard-driver.c:<br /> <br /> for_each_card_prelinks(card, i, dai_link) {<br /> if (adsp_node &amp;&amp; !strncmp(dai_link-&gt;name, "AFE_SOF", strlen("AFE_SOF")))<br /> dai_link-&gt;platforms-&gt;of_node = adsp_node;<br /> else if (!dai_link-&gt;platforms-&gt;name &amp;&amp; !dai_link-&gt;platforms-&gt;of_node)<br /> dai_link-&gt;platforms-&gt;of_node = platform_node;<br /> }<br /> <br /> where the code expects the platforms array to have space for at least one entry.<br /> <br /> Add an COMP_EMPTY() entry so that dai_link-&gt;platforms has space.
Severity CVSS v4.0: Pending analysis
Last modification:
25/09/2025

CVE-2024-6748

Publication date:
29/07/2024
Zohocorp ManageEngine OpManager, OpManager Plus, OpManager MSP and RMM versions 128317 and below are vulnerable to authenticated SQL injection in the URL monitoring.
Severity CVSS v4.0: Pending analysis
Last modification:
30/07/2024

CVE-2024-42084

Publication date:
29/07/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftruncate: pass a signed offset<br /> <br /> The old ftruncate() syscall, using the 32-bit off_t misses a sign<br /> extension when called in compat mode on 64-bit architectures. As a<br /> result, passing a negative length accidentally succeeds in truncating<br /> to file size between 2GiB and 4GiB.<br /> <br /> Changing the type of the compat syscall to the signed compat_off_t<br /> changes the behavior so it instead returns -EINVAL.<br /> <br /> The native entry point, the truncate() syscall and the corresponding<br /> loff_t based variants are all correct already and do not suffer<br /> from this mistake.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-42085

Publication date:
29/07/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: core: remove lock of otg mode during gadget suspend/resume to avoid deadlock<br /> <br /> When config CONFIG_USB_DWC3_DUAL_ROLE is selected, and trigger system<br /> to enter suspend status with below command:<br /> echo mem &gt; /sys/power/state<br /> There will be a deadlock issue occurring. Detailed invoking path as<br /> below:<br /> dwc3_suspend_common()<br /> spin_lock_irqsave(&amp;dwc-&gt;lock, flags); lock, flags); gadget_driver is NULL or not. It causes the<br /> following code is executed and deadlock occurs when trying to get the<br /> spinlock. In fact, the root cause is the commit 5265397f9442("usb: dwc3:<br /> Remove DWC3 locking during gadget suspend/resume") that forgot to remove<br /> the lock of otg mode. So, remove the redundant lock of otg mode during<br /> gadget suspend/resume.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-42086

Publication date:
29/07/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: chemical: bme680: Fix overflows in compensate() functions<br /> <br /> There are cases in the compensate functions of the driver that<br /> there could be overflows of variables due to bit shifting ops.<br /> These implications were initially discussed here [1] and they<br /> were mentioned in log message of Commit 1b3bd8592780 ("iio:<br /> chemical: Add support for Bosch BME680 sensor").<br /> <br /> [1]: https://lore.kernel.org/linux-iio/20180728114028.3c1bbe81@archlinux/
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-42087

Publication date:
29/07/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep<br /> <br /> The ilitek-ili9881c controls the reset GPIO using the non-sleeping<br /> gpiod_set_value() function. This complains loudly when the GPIO<br /> controller needs to sleep. As the caller can sleep, use<br /> gpiod_set_value_cansleep() to fix the issue.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-42089

Publication date:
29/07/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: fsl-asoc-card: set priv-&gt;pdev before using it<br /> <br /> priv-&gt;pdev pointer was set after being used in<br /> fsl_asoc_card_audmux_init().<br /> Move this assignment at the start of the probe function, so<br /> sub-functions can correctly use pdev through priv.<br /> <br /> fsl_asoc_card_audmux_init() dereferences priv-&gt;pdev to get access to the<br /> dev struct, used with dev_err macros.<br /> As priv is zero-initialised, there would be a NULL pointer dereference.<br /> Note that if priv-&gt;dev is dereferenced before assignment but never used,<br /> for example if there is no error to be printed, the driver won&amp;#39;t crash<br /> probably due to compiler optimisations.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-42090

Publication date:
29/07/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER<br /> <br /> In create_pinctrl(), pinctrl_maps_mutex is acquired before calling<br /> add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()<br /> calls pinctrl_free(). However, pinctrl_free() attempts to acquire<br /> pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to<br /> a potential deadlock.<br /> <br /> This patch resolves the issue by releasing pinctrl_maps_mutex before<br /> calling pinctrl_free(), preventing the deadlock.<br /> <br /> This bug was discovered and resolved using Coverity Static Analysis<br /> Security Testing (SAST) by Synopsys, Inc.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025