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

CVE-2026-68231

Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: airspy: Return queued buffers on start_streaming() failure<br /> <br /> The vb2 framework hands buffers to the driver via buf_queue() before<br /> calling start_streaming(). If start_streaming() returns an error<br /> without first returning those buffers via vb2_buffer_done(),<br /> vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued<br /> buffers leak.<br /> <br /> airspy_start_streaming() returned -ENODEV early when the USB device had<br /> been disconnected (s-&gt;udev == NULL) without returning any buffers that<br /> buf_queue() had already accepted. Take v4l2_lock first and jump to the<br /> existing err_clear_bit label, which already drains s-&gt;queued_bufs via<br /> vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking.<br /> <br /> This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:<br /> Return queued buffers on start_streaming() failure").
Severity CVSS v4.0: Pending analysis
Last modification:
19/08/2026

CVE-2026-68234

Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix bo-&gt;pin leaking in amdgpu_bo_create_reserved<br /> <br /> amdgpu_bo_create_reserved() only allocates a new BO when<br /> *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is<br /> NULL, it simply skips creation when *bo_ptr is non-NULL.<br /> But it unconditionally reserves, pins, gart allocates<br /> and maps the BO afterwards.<br /> <br /> When the same non-NULL BO pointer is passed in again,<br /> for example firmware buffers that live in adev and are<br /> re-loaded on every resume / cp_resume / start<br /> under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases<br /> pin_count unconditionally, however the matching teardown only unpins<br /> once, so pin_count never drops to zero, so TTM is not able<br /> to move, swap or evict a BO, causing BO leaks.<br /> <br /> This commit fixes this issue by only pinning the bo<br /> once at creation, and repeated calls no longer<br /> take additional pin references.<br /> <br /> (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)
Severity CVSS v4.0: Pending analysis
Last modification:
19/08/2026

CVE-2026-68220

Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and pipe<br /> <br /> Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call<br /> v4l2_subdev_init_finalize() which allocates the subdev active state,<br /> but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup()<br /> calls v4l2_subdev_cleanup() to free it.<br /> <br /> This causes a memory leak on every rmmod, reported by kmemleak:<br /> <br /> unreferenced object 0xffff0000d06fc800 (size 192):<br /> comm "(udev-worker)", pid 254, jiffies 4294913455<br /> backtrace (crc 36eeae58):<br /> kmemleak_alloc+0x34/0x40<br /> __kvmalloc_node_noprof+0x5f8/0x7d8<br /> __v4l2_subdev_state_alloc+0x1fc/0x30c<br /> __v4l2_subdev_init_finalize+0x178/0x368<br /> <br /> Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup()<br /> in both crossbar and pipe cleanup paths.
Severity CVSS v4.0: Pending analysis
Last modification:
17/08/2026

CVE-2026-68221

Publication date:
10/08/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: nuvoton: npcm-video: fix memory leaks in probe and remove<br /> <br /> npcm_video_probe() allocates the npcm_video structure with kzalloc_obj()<br /> but never frees it on any probe error path or in npcm_video_remove(),<br /> leaking the allocation on every failed probe and every normal unbind.<br /> <br /> Additionally, when npcm_video_setup_video() fails, the reserved memory<br /> association established by of_reserved_mem_device_init() in<br /> npcm_video_init() is not released, leaking the rmem_assigned_device<br /> entry on the global list.<br /> <br /> Fix both by adding kfree(video) to all probe error paths and to<br /> npcm_video_remove(), and adding the missing<br /> of_reserved_mem_device_release() call when npcm_video_setup_video()<br /> fails.
Severity CVSS v4.0: Pending analysis
Last modification:
17/08/2026