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

Publication date:
04/09/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: pm: avoid possible UaF when selecting endp<br /> <br /> select_local_address() and select_signal_address() both select an<br /> endpoint entry from the list inside an RCU protected section, but return<br /> a reference to it, to be read later on. If the entry is dereferenced<br /> after the RCU unlock, reading info could cause a Use-after-Free.<br /> <br /> A simple solution is to copy the required info while inside the RCU<br /> protected section to avoid any risk of UaF later. The address ID might<br /> need to be modified later to handle the ID0 case later, so a copy seems<br /> OK to deal with.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-44988

Publication date:
04/09/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: mv88e6xxx: Fix out-of-bound access<br /> <br /> If an ATU violation was caused by a CPU Load operation, the SPID could<br /> be larger than DSA_MAX_PORTS (the size of mv88e6xxx_chip.ports[] array).
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-42642

Publication date:
04/09/2024
Micron Crucial MX500 Series Solid State Drives M3CR046 is vulnerable to Buffer Overflow, which can be triggered by sending specially crafted ATA packets from the host to the drive controller. NOTE: The supplier states that this vulnerability was fully remediated in December 2024 and that updated firmware is available through Crucial’s official support page.
Severity CVSS v4.0: Pending analysis
Last modification:
05/02/2026

CVE-2024-44973

Publication date:
04/09/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm, slub: do not call do_slab_free for kfence object<br /> <br /> In 782f8906f805 the freeing of kfence objects was moved from deep<br /> inside do_slab_free to the wrapper functions outside. This is a nice<br /> change, but unfortunately it missed one spot in __kmem_cache_free_bulk.<br /> <br /> This results in a crash like this:<br /> <br /> BUG skbuff_head_cache (Tainted: G S B E ): Padding overwritten. 0xffff88907fea0f00-0xffff88907fea0fff @offset=3840<br /> <br /> slab_err (mm/slub.c:1129)<br /> free_to_partial_list (mm/slub.c:? mm/slub.c:4036)<br /> slab_pad_check (mm/slub.c:864 mm/slub.c:1290)<br /> check_slab (mm/slub.c:?)<br /> free_to_partial_list (mm/slub.c:3171 mm/slub.c:4036)<br /> kmem_cache_alloc_bulk (mm/slub.c:? mm/slub.c:4495 mm/slub.c:4586 mm/slub.c:4635)<br /> napi_build_skb (net/core/skbuff.c:348 net/core/skbuff.c:527 net/core/skbuff.c:549)<br /> <br /> All the other callers to do_slab_free appear to be ok.<br /> <br /> Add a kfence_free check in __kmem_cache_free_bulk to avoid the crash.
Severity CVSS v4.0: Pending analysis
Last modification:
03/10/2024

CVE-2024-44966

Publication date:
04/09/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binfmt_flat: Fix corruption when not offsetting data start<br /> <br /> Commit 04d82a6d0881 ("binfmt_flat: allow not offsetting data start")<br /> introduced a RISC-V specific variant of the FLAT format which does<br /> not allocate any space for the (obsolete) array of shared library<br /> pointers. However, it did not disable the code which initializes the<br /> array, resulting in the corruption of sizeof(long) bytes before the DATA<br /> segment, generally the end of the TEXT segment.<br /> <br /> Introduce MAX_SHARED_LIBS_UPDATE which depends on the state of<br /> CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET to guard the initialization of<br /> the shared library pointer region so that it will only be initialized<br /> if space is reserved for it.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-44967

Publication date:
04/09/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mgag200: Bind I2C lifetime to DRM device<br /> <br /> Managed cleanup with devm_add_action_or_reset() will release the I2C<br /> adapter when the underlying Linux device goes away. But the connector<br /> still refers to it, so this cleanup leaves behind a stale pointer<br /> in struct drm_connector.ddc.<br /> <br /> Bind the lifetime of the I2C adapter to the connector&amp;#39;s lifetime by<br /> using DRM&amp;#39;s managed release. When the DRM device goes away (after<br /> the Linux device) DRM will first clean up the connector and then<br /> clean up the I2C adapter.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-44968

Publication date:
04/09/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tick/broadcast: Move per CPU pointer access into the atomic section<br /> <br /> The recent fix for making the take over of the broadcast timer more<br /> reliable retrieves a per CPU pointer in preemptible context.<br /> <br /> This went unnoticed as compilers hoist the access into the non-preemptible<br /> region where the pointer is actually used. But of course it&amp;#39;s valid that<br /> the compiler keeps it at the place where the code puts it which rightfully<br /> triggers:<br /> <br /> BUG: using smp_processor_id() in preemptible [00000000] code:<br /> caller is hotplug_cpu__broadcast_tick_pull+0x1c/0xc0<br /> <br /> Move it to the actual usage site which is in a non-preemptible region.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-44969

Publication date:
04/09/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/sclp: Prevent release of buffer in I/O<br /> <br /> When a task waiting for completion of a Store Data operation is<br /> interrupted, an attempt is made to halt this operation. If this attempt<br /> fails due to a hardware or firmware problem, there is a chance that the<br /> SCLP facility might store data into buffers referenced by the original<br /> operation at a later time.<br /> <br /> Handle this situation by not releasing the referenced data buffers if<br /> the halt attempt fails. For current use cases, this might result in a<br /> leak of few pages of memory in case of a rare hardware/firmware<br /> malfunction.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-44970

Publication date:
04/09/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: SHAMPO, Fix invalid WQ linked list unlink<br /> <br /> When all the strides in a WQE have been consumed, the WQE is unlinked<br /> from the WQ linked list (mlx5_wq_ll_pop()). For SHAMPO, it is possible<br /> to receive CQEs with 0 consumed strides for the same WQE even after the<br /> WQE is fully consumed and unlinked. This triggers an additional unlink<br /> for the same wqe which corrupts the linked list.<br /> <br /> Fix this scenario by accepting 0 sized consumed strides without<br /> unlinking the WQE again.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-44971

Publication date:
04/09/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register()<br /> <br /> bcm_sf2_mdio_register() calls of_phy_find_device() and then<br /> phy_device_remove() in a loop to remove existing PHY devices.<br /> of_phy_find_device() eventually calls bus_find_device(), which calls<br /> get_device() on the returned struct device * to increment the refcount.<br /> The current implementation does not decrement the refcount, which causes<br /> memory leak.<br /> <br /> This commit adds the missing phy_device_free() call to decrement the<br /> refcount via put_device() to balance the refcount.
Severity CVSS v4.0: Pending analysis
Last modification:
03/11/2025

CVE-2024-44972

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

CVE-2024-44951

Publication date:
04/09/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: sc16is7xx: fix TX fifo corruption<br /> <br /> Sometimes, when a packet is received on channel A at almost the same time<br /> as a packet is about to be transmitted on channel B, we observe with a<br /> logic analyzer that the received packet on channel A is transmitted on<br /> channel B. In other words, the Tx buffer data on channel B is corrupted<br /> with data from channel A.<br /> <br /> The problem appeared since commit 4409df5866b7 ("serial: sc16is7xx: change<br /> EFR lock to operate on each channels"), which changed the EFR locking to<br /> operate on each channel instead of chip-wise.<br /> <br /> This commit has introduced a regression, because the EFR lock is used not<br /> only to protect the EFR registers access, but also, in a very obscure and<br /> undocumented way, to protect access to the data buffer, which is shared by<br /> the Tx and Rx handlers, but also by each channel of the IC.<br /> <br /> Fix this regression first by switching to kfifo_out_linear_ptr() in<br /> sc16is7xx_handle_tx() to eliminate the need for a shared Rx/Tx buffer.<br /> <br /> Secondly, replace the chip-wise Rx buffer with a separate Rx buffer for<br /> each channel.
Severity CVSS v4.0: Pending analysis
Last modification:
09/10/2024