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

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-2026-68262
Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/imagination: Fix user array stride in pvr_set_uobj_array()<br /> <br /> pvr_set_uobj_array() copies an array of kernel objects to a userspace<br /> array whose element size is described by out-&gt;stride. When out-&gt;stride<br /> is different from the kernel object size, the slow path advances the<br /> userspace pointer by the kernel object size and the kernel pointer by the<br /> userspace stride.<br /> <br /> This reverses the intended layout. For larger userspace strides, later<br /> copies read from the wrong kernel addresses. For smaller userspace<br /> strides, later copies are written at the wrong userspace offsets. The<br /> padding clear is also done only for the first element instead of the<br /> padding area for each element.<br /> <br /> Advance the userspace pointer by out-&gt;stride and the kernel pointer by<br /> obj_size, and clear per-element padding while the current userspace<br /> pointer is still available.
Severity CVSS v4.0: Pending analysis
Last modification:
17/08/2026

CVE-2026-68257
Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: fix 32-bit overflow in CWSR total size calculation<br /> <br /> total_cwsr_size was computed in 32-bit before being used as a BO/SVM<br /> allocation size.<br /> With large ctx_save_restore_area_size and debug_memory_size<br /> multiplied by the XCC count, the product can wrap,<br /> yielding an undersized CWSR save area that firmware later overruns.<br /> <br /> Promote total_cwsr_size to u64 and use check_add_overflow()/<br /> check_mul_overflow() in both kfd_queue_acquire_buffers() and<br /> kfd_queue_release_buffers().<br /> <br /> (cherry picked from commit 319f7e13423ae3f486b9aea82f9ad2d6af0ee608)
Severity CVSS v4.0: Pending analysis
Last modification:
18/08/2026

CVE-2026-68258
Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Check bounds on CRIU restore queue type and mqd size<br /> <br /> We weren&amp;#39;t checking whether the values provided in the private<br /> data in kfd CRIU restore were within bounds.<br /> <br /> For queue type, add a KFD_QUEUE_TYPE_MAX and ensure the provided<br /> type is less than it.<br /> <br /> For mqd_size, add new function mqd_size_from_queue_type and confirm<br /> that the provided mqd_size matches expectations.<br /> <br /> (cherry picked from commit f19d8086f6644083c913d70bfdeee20e1b6f46a5)
Severity CVSS v4.0: Pending analysis
Last modification:
18/08/2026

CVE-2026-68255
Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/virtio: bound EDID block reads to the response buffer<br /> <br /> virtio_get_edid_block() validates the read offset only against the<br /> device-supplied resp-&gt;size field, never against the fixed-size resp-&gt;edid<br /> array. The EDID block index is driven by the device-supplied extension<br /> count, so a malicious virtio-gpu backend can advertise a large size<br /> together with a high block count and read far past the array into adjacent<br /> kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds<br /> read / info leak).<br /> <br /> Also reject any read whose end exceeds the size of the edid array.<br /> Conforming EDID responses stay within the array and are unaffected.
Severity CVSS v4.0: Pending analysis
Last modification:
19/08/2026

CVE-2026-68259
Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Check bounds in allocate_event_notification_slot<br /> <br /> The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT<br /> <br /> allocate_event_notification_slot has an option to specify<br /> an event id to allocate at, used by CRIU. We weren&amp;#39;t checking<br /> the bounds on that value.<br /> <br /> Check them.<br /> <br /> v2: Lower bounds check is unecessary because of idr_alloc<br /> already rejecting negative numbers. Upper bounds check should<br /> be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might<br /> not yet exist<br /> <br /> (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50)
Severity CVSS v4.0: Pending analysis
Last modification:
19/08/2026

CVE-2026-68247
Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/bios: range check LFP Data Block panel_type2<br /> <br /> While the panel_type from LFP Data Block is range checked, panel_type2<br /> is not. Add a few helpers for range checking, and use them to not only<br /> check panel_type2, but also improve clarity and correctness in the panel<br /> type selection.<br /> <br /> Discovered using AI-assisted static analysis confirmed by Intel Product<br /> Security.<br /> <br /> v2:<br /> - Fix commit message typo (Michał)<br /> - Add is_panel_type_pnp() (Ville)<br /> <br /> (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)
Severity CVSS v4.0: Pending analysis
Last modification:
17/08/2026

CVE-2026-68253
Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/hdcp: check streams[] bounds before overflow<br /> <br /> The data-&gt;streams[] overflow check is done after the buffer overflow has<br /> already happened. Move the overflow check before the write.<br /> <br /> Side note, emitting a warning splat with a backtrace might be overkill<br /> here, but prefer not changing the behaviour other than not doing the<br /> overrun.<br /> <br /> Discovered using AI-assisted static analysis confirmed by Intel Product<br /> Security.<br /> <br /> (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd)
Severity CVSS v4.0: Pending analysis
Last modification:
17/08/2026

CVE-2026-68254
Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/vrr: require valid min/max vfreq for VRR<br /> <br /> Ensure the EDID provided min/max vfreq are valid. Most scenarios are<br /> already covered (by coincidence) through the checks in<br /> intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit<br /> about it. At worst, a zero min_vfreq could lead to a division by zero in<br /> intel_vrr_compute_vmax().<br /> <br /> Discovered using AI-assisted static analysis confirmed by Intel Product<br /> Security.<br /> <br /> (cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6)
Severity CVSS v4.0: Pending analysis
Last modification:
17/08/2026

CVE-2026-68252
Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON()<br /> <br /> There&amp;#39;s no need to crash the kernel for these cases.<br /> <br /> (cherry picked from commit 9723a8bed3aa251a26bee4583bac9d8fb064dd44)
Severity CVSS v4.0: Pending analysis
Last modification:
18/08/2026

CVE-2026-68246
Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON()<br /> <br /> There&amp;#39;s no need to crash the kernel for these cases.<br /> <br /> (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd)
Severity CVSS v4.0: Pending analysis
Last modification:
19/08/2026

CVE-2026-68248
Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Return NULL on error in active_instance<br /> <br /> Avoid returning &amp;node-&gt;base when node is NULL due to OOM<br /> during GFP_ATOMIC allocation.<br /> <br /> Discovered using AI-assisted static analysis confirmed by<br /> Intel Product Security.<br /> <br /> (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)
Severity CVSS v4.0: Pending analysis
Last modification:
19/08/2026

CVE-2026-68249
Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON()<br /> <br /> There&amp;#39;s no need to crash the kernel for these cases.<br /> <br /> (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)
Severity CVSS v4.0: Pending analysis
Last modification:
19/08/2026
Subscribe to Vulnerabilities