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

Publication date:
05/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: fix a Null pointer dereference vulnerability<br /> <br /> [Why]<br /> A null pointer dereference vulnerability exists in the AMD display driver&amp;#39;s<br /> (DC module) cleanup function dc_destruct().<br /> When display control context (dc-&gt;ctx) construction fails<br /> (due to memory allocation failure), this pointer remains NULL.<br /> During subsequent error handling when dc_destruct() is called,<br /> there&amp;#39;s no NULL check before dereferencing the perf_trace member<br /> (dc-&gt;ctx-&gt;perf_trace), causing a kernel null pointer dereference crash.<br /> <br /> [How]<br /> Check if dc-&gt;ctx is non-NULL before dereferencing.<br /> <br /> (Updated commit text and removed unnecessary error message)<br /> (cherry picked from commit 9dd8e2ba268c636c240a918e0a31e6feaee19404)
Severity CVSS v4.0: Pending analysis
Last modification:
25/11/2025

CVE-2025-39707

Publication date:
05/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: check if hubbub is NULL in debugfs/amdgpu_dm_capabilities<br /> <br /> HUBBUB structure is not initialized on DCE hardware, so check if it is NULL<br /> to avoid null dereference while accessing amdgpu_dm_capabilities file in<br /> debugfs.
Severity CVSS v4.0: Pending analysis
Last modification:
25/11/2025

CVE-2025-39702

Publication date:
05/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: sr: Fix MAC comparison to be constant-time<br /> <br /> To prevent timing attacks, MACs need to be compared in constant time.<br /> Use the appropriate helper function for this.
Severity CVSS v4.0: Pending analysis
Last modification:
06/02/2026

CVE-2025-39694

Publication date:
05/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/sclp: Fix SCCB present check<br /> <br /> Tracing code called by the SCLP interrupt handler contains early exits<br /> if the SCCB address associated with an interrupt is NULL. This check is<br /> performed after physical to virtual address translation.<br /> <br /> If the kernel identity mapping does not start at address zero, the<br /> resulting virtual address is never zero, so that the NULL checks won&amp;#39;t<br /> work. Subsequently this may result in incorrect accesses to the first<br /> page of the identity mapping.<br /> <br /> Fix this by introducing a function that handles the NULL case before<br /> address translation.
Severity CVSS v4.0: Pending analysis
Last modification:
07/01/2026

CVE-2025-39693

Publication date:
05/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Avoid a NULL pointer dereference<br /> <br /> [WHY]<br /> Although unlikely drm_atomic_get_new_connector_state() or<br /> drm_atomic_get_old_connector_state() can return NULL.<br /> <br /> [HOW]<br /> Check returns before dereference.<br /> <br /> (cherry picked from commit 1e5e8d672fec9f2ab352be121be971877bff2af9)
Severity CVSS v4.0: Pending analysis
Last modification:
07/01/2026

CVE-2025-39697

Publication date:
05/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: Fix a race when updating an existing write<br /> <br /> After nfs_lock_and_join_requests() tests for whether the request is<br /> still attached to the mapping, nothing prevents a call to<br /> nfs_inode_remove_request() from succeeding until we actually lock the<br /> page group.<br /> The reason is that whoever called nfs_inode_remove_request() doesn&amp;#39;t<br /> necessarily have a lock on the page group head.<br /> <br /> So in order to avoid races, let&amp;#39;s take the page group lock earlier in<br /> nfs_lock_and_join_requests(), and hold it across the removal of the<br /> request in nfs_inode_remove_request().
Severity CVSS v4.0: Pending analysis
Last modification:
08/01/2026

CVE-2025-39699

Publication date:
05/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/riscv: prevent NULL deref in iova_to_phys<br /> <br /> The riscv_iommu_pte_fetch() function returns either NULL for<br /> unmapped/never-mapped iova, or a valid leaf pte pointer that<br /> requires no further validation.<br /> <br /> riscv_iommu_iova_to_phys() failed to handle NULL returns.<br /> Prevent null pointer dereference in<br /> riscv_iommu_iova_to_phys(), and remove the pte validation.
Severity CVSS v4.0: Pending analysis
Last modification:
25/11/2025

CVE-2025-39695

Publication date:
05/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Flush delayed SKBs while releasing RXE resources<br /> <br /> When skb packets are sent out, these skb packets still depends on<br /> the rxe resources, for example, QP, sk, when these packets are<br /> destroyed.<br /> <br /> If these rxe resources are released when the skb packets are destroyed,<br /> the call traces will appear.<br /> <br /> To avoid skb packets hang too long time in some network devices,<br /> a timestamp is added when these skb packets are created. If these<br /> skb packets hang too long time in network devices, these network<br /> devices can free these skb packets to release rxe resources.
Severity CVSS v4.0: Pending analysis
Last modification:
25/11/2025

CVE-2025-39696

Publication date:
05/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: hda: tas2781: Fix wrong reference of tasdevice_priv<br /> <br /> During the conversion to unify the calibration data management, the<br /> reference to tasdevice_priv was wrongly set to h-&gt;hda_priv instead of<br /> h-&gt;priv. This resulted in memory corruption and crashes eventually.<br /> Unfortunately it&amp;#39;s a void pointer, hence the compiler couldn&amp;#39;t know<br /> that it&amp;#39;s wrong.
Severity CVSS v4.0: Pending analysis
Last modification:
25/11/2025

CVE-2025-39698

Publication date:
05/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/futex: ensure io_futex_wait() cleans up properly on failure<br /> <br /> The io_futex_data is allocated upfront and assigned to the io_kiocb<br /> async_data field, but the request isn&amp;#39;t marked with REQ_F_ASYNC_DATA<br /> at that point. Those two should always go together, as the flag tells<br /> io_uring whether the field is valid or not.<br /> <br /> Additionally, on failure cleanup, the futex handler frees the data but<br /> does not clear -&gt;async_data. Clear the data and the flag in the error<br /> path as well.<br /> <br /> Thanks to Trend Micro Zero Day Initiative and particularly ReDress for<br /> reporting this.
Severity CVSS v4.0: Pending analysis
Last modification:
25/11/2025

CVE-2025-39689

Publication date:
05/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Also allocate and copy hash for reading of filter files<br /> <br /> Currently the reader of set_ftrace_filter and set_ftrace_notrace just adds<br /> the pointer to the global tracer hash to its iterator. Unlike the writer<br /> that allocates a copy of the hash, the reader keeps the pointer to the<br /> filter hashes. This is problematic because this pointer is static across<br /> function calls that release the locks that can update the global tracer<br /> hashes. This can cause UAF and similar bugs.<br /> <br /> Allocate and copy the hash for reading the filter files like it is done<br /> for the writers. This not only fixes UAF bugs, but also makes the code a<br /> bit simpler as it doesn&amp;#39;t have to differentiate when to free the<br /> iterator&amp;#39;s hash between writers and readers.
Severity CVSS v4.0: Pending analysis
Last modification:
08/01/2026

CVE-2025-39686

Publication date:
05/09/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: Make insn_rw_emulate_bits() do insn-&gt;n samples<br /> <br /> The `insn_rw_emulate_bits()` function is used as a default handler for<br /> `INSN_READ` instructions for subdevices that have a handler for<br /> `INSN_BITS` but not for `INSN_READ`. Similarly, it is used as a default<br /> handler for `INSN_WRITE` instructions for subdevices that have a handler<br /> for `INSN_BITS` but not for `INSN_WRITE`. It works by emulating the<br /> `INSN_READ` or `INSN_WRITE` instruction handling with a constructed<br /> `INSN_BITS` instruction. However, `INSN_READ` and `INSN_WRITE`<br /> instructions are supposed to be able read or write multiple samples,<br /> indicated by the `insn-&gt;n` value, but `insn_rw_emulate_bits()` currently<br /> only handles a single sample. For `INSN_READ`, the comedi core will<br /> copy `insn-&gt;n` samples back to user-space. (That triggered KASAN<br /> kernel-infoleak errors when `insn-&gt;n` was greater than 1, but that is<br /> being fixed more generally elsewhere in the comedi core.)<br /> <br /> Make `insn_rw_emulate_bits()` either handle `insn-&gt;n` samples, or return<br /> an error, to conform to the general expectation for `INSN_READ` and<br /> `INSN_WRITE` handlers.
Severity CVSS v4.0: Pending analysis
Last modification:
08/01/2026