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

Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/mst: limit DP MST ESI service loop<br /> <br /> The loop in intel_dp_check_mst_status() keeps servicing interrupts<br /> originating from the sink without bound. Add an upper bound to the new<br /> interrupts occurring during interrupt processing to not get stuck on<br /> potentially stuck sink devices. Use arbitrary 32 tries to clear incoming<br /> interrupts in one go.<br /> <br /> Discovered using AI-assisted static analysis confirmed by Intel Product<br /> Security.<br /> <br /> Note: The condition likely pre-dates the commit in the Fixes: tag, but<br /> this is about as far back as a backport has any chance of<br /> succeeding. Before that, the retry had a goto.<br /> <br /> (cherry picked from commit b4ea5272133059acb493cc36599071a9e852ec2e)
Severity CVSS v4.0: Pending analysis
Last modification:
17/08/2026

CVE-2026-68242

Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gt: Fix NULL deref on sched_engine alloc failure<br /> <br /> Avoid using intel_context_put() before intel_context_init() in<br /> execlists_create_virtual() as the kref_put() inside would lead<br /> to NULL deref on the IOCTL path when sched_engine allocation fails.<br /> <br /> Discovered using AI-assisted static analysis confirmed by<br /> Intel Product Security.<br /> <br /> (cherry picked from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d)
Severity CVSS v4.0: Pending analysis
Last modification:
17/08/2026

CVE-2026-68245

Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid()<br /> <br /> The vm pointer returned from amdgpu_vm_get_vm_from_pasid() is only<br /> valid while the lock is still being held. Once xa_unlock_irqrestore is<br /> called and returned, the pointer is no longer under lock and is subject<br /> to modification. Since, the caller still dereferences vm-&gt;task_info in<br /> amdgpu_vm_get_task_info_vm() after the lock is removed, this causes a<br /> use after unlock problem.<br /> <br /> Remove the lifetime issue present in amdgpu_vm_get_task_info_pasid()<br /> through removing the amdgpu_vm_get_vm_from_pasid() function from<br /> amdgpu_vm.c and making the relevant code inline to hold the lock while<br /> it is still in use.<br /> <br /> (cherry picked from commit 9d01579f3f868b333acc901815972685989092c7)
Severity CVSS v4.0: Pending analysis
Last modification:
18/08/2026

CVE-2026-68243

Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU<br /> <br /> Setting context engine slot N into I915_ENGINE_CLASS_INVALID /<br /> I915_ENGINE_CLASS_INVALID_NONE and attempting to apply<br /> I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL.<br /> Fix that.<br /> <br /> Discovered using AI-assisted static analysis confirmed by<br /> Intel Product Security.<br /> <br /> (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)
Severity CVSS v4.0: Pending analysis
Last modification:
19/08/2026

CVE-2026-68244

Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gem: Do not leak siblings[] on proto context error<br /> <br /> After a successful BALANCE/PARALLEL_SUBMIT extension on context<br /> creation, error during processing of next user extension leaks<br /> the siblings[] array. Fix that.<br /> <br /> Discovered using AI-assisted static analysis confirmed by<br /> Intel Product Security.<br /> <br /> (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)
Severity CVSS v4.0: Pending analysis
Last modification:
19/08/2026

CVE-2026-68228

Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: chips-media: wave5: Move src_buf Removal to finish_encode<br /> <br /> During encoder processing, there is a case where the IRQ response could<br /> return the buffer back to userspace via v4l2_m2m_buf_done call. In this<br /> time, userspace could queue up this same buffer before start_encode removes<br /> the index from the ready queue. This would then lead to a case where the<br /> buffer in the ready queue could be a self loop due to the<br /> WRITE_ONCE(prev-&gt;next, new) call in __list_add.<br /> <br /> When __list_del is finally called, the loop is already made so nothing<br /> points back to ready queue list head and pointers are poisoned.<br /> <br /> A buffer should not be marked as DONE before the buffer is removed from<br /> m2m ready queue. Move removal entirely to finish_encode.
Severity CVSS v4.0: Pending analysis
Last modification:
17/08/2026

CVE-2026-68230

Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: amlogic-c3: Add validations for ae and awb config<br /> <br /> Avoid invalid memory access if the zones_num is bigger than<br /> zone_weight.<br /> <br /> This patch fixes the following smatch errors:<br /> drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow &amp;#39;cfg-&gt;zone_weight&amp;#39; 768 zone_weight&amp;#39; 768 zone_weight&amp;#39; 255 zone_weight&amp;#39; 255
Severity CVSS v4.0: Pending analysis
Last modification:
17/08/2026

CVE-2026-68232

Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict<br /> <br /> If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM<br /> reference acquired earlier is not released, resulting in a reference<br /> leak.<br /> <br /> Fix this by dropping the MM reference on the kvmalloc_array()<br /> failure path.
Severity CVSS v4.0: Pending analysis
Last modification:
17/08/2026

CVE-2026-68233

Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vc4: Shut down BO cache timer before teardown<br /> <br /> The BO cache timer callback schedules time_work, and time_work can rearm<br /> the timer through vc4_bo_cache_free_old().<br /> <br /> vc4_bo_cache_destroy() deletes the timer and then cancels the work, which<br /> does not break that cycle: the work being cancelled can rearm the timer,<br /> and the timer then queues work again after teardown.<br /> <br /> Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the<br /> cycle ends with cancel_work_sync().
Severity CVSS v4.0: Pending analysis
Last modification:
17/08/2026

CVE-2026-68236

Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: set new_stream to NULL after release<br /> <br /> In dm_update_crtc_state(), the skip_modeset path releases new_stream<br /> via dc_stream_release() but does not set the pointer to NULL.<br /> <br /> If a later error (e.g., color management failure) triggers the fail<br /> label, the error path calls dc_stream_release() again on the same<br /> dangling pointer, causing a double release and potential use-after-free.<br /> <br /> Fix this by setting new_stream to NULL after the initial release.<br /> <br /> (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)
Severity CVSS v4.0: Pending analysis
Last modification:
17/08/2026

CVE-2026-68235

Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: dce100: skip non-DP stream encoders for DP MST<br /> <br /> On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital<br /> DIG stream encoders plus one analog DAC encoder. When assigning a stream<br /> encoder for a second DisplayPort MST stream, if the preferred digital<br /> encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link()<br /> falls back to the first free pool entry. That entry may be the analog<br /> encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute.<br /> The subsequent atomic commit then dereferences NULL function pointers in<br /> link_set_dpms_on() and crashes.<br /> <br /> Skip encoders without dp_set_stream_attribute when the stream uses a DP<br /> signal (including MST). Use dc_is_dp_signal(stream-&gt;signal) for the MST<br /> fallback path instead of checking only the link connector signal.<br /> <br /> Tested on:<br /> - GPU: AMD Radeon R7 260X (Bonaire / DCE8)<br /> - Board: Supermicro C9X299-PG300<br /> - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot<br /> - Kernel: 7.1.3 (issue observed since 6.19)<br /> - Result: kernel oops without patch; dual monitors stable with patch<br /> <br /> (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)
Severity CVSS v4.0: Pending analysis
Last modification:
18/08/2026

CVE-2026-68229

Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: cedrus: skip invalid H.264 reference list entries<br /> <br /> Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the<br /> stateless slice control and later uses their indices to look up<br /> decode-&gt;dpb[] in _cedrus_write_ref_list().<br /> <br /> Rejecting such controls in cedrus_try_ctrl() would break existing<br /> userspace, since stateless H.264 reference lists may legitimately carry<br /> out-of-range indices for missing references. Instead, guard the actual<br /> DPB lookup in Cedrus and skip entries whose indices do not fit the fixed<br /> V4L2_H264_NUM_DPB_ENTRIES array.<br /> <br /> This keeps the fix local to the driver use site and avoids out-of-bounds<br /> reads from malformed or unsupported reference list entries.
Severity CVSS v4.0: Pending analysis
Last modification:
19/08/2026