p PatchFirst

PatchFirst · Latest vulnerabilities

linux-raspi vulnerabilities · Page 166

Vulnerabilities published for linux-raspi in the last 30 days: 791. Listed in the KEV catalogue: 0.

RSS ↗ JSON ↗
Filter vulnerabilities
Clear filters

Vulnerabilities: 10282

  1. CVE-2026-68281

    Not ratedEPSS 0.18%No fix published

    drm/imagination: Count paired job fence as dependency in prepare_job()

    In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Count paired job fence as dependency in prepare_job() The DRM scheduler's prepare_job() callback counts the remaining non-signaled native dependencies for a job, preventing job submission until those (plus job data and fence update) can fit in the job queue's CCCB. This means checking which dependencies can be waited upon in the firmware, i.e. whether they are backed by a UFO object, i.e. whether their drm_sched_fence::parent has been assigned to a pvr_queue_fence::base fence. That happens when the job owning the fence is submitted to the firmware. Paired

    linux-raspiOperating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  2. CVE-2026-68280

    Not ratedEPSS 0.18%No fix published

    drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS()

    In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS() The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_cor

    linux-raspiOperating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  3. CVE-2026-68279

    Not ratedEPSS 0.18%No fix published

    drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers

    In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &raw->msg[idx], num_bytes); without checking that idx + num_bytes <= raw->curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the c

    linux-raspiOperating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  4. CVE-2026-68278

    Not ratedEPSS 0.24%No fix published

    drm/dp/mst: fix buffer overflows in sideband chunk accumulation

    In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix buffer overflows in sideband chunk accumulation drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out

    linux-raspiOperating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  5. CVE-2026-68277

    Not ratedEPSS 0.22%No fix published

    drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers

    In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers Three sideband reply parsers read 16-bit fields as: val = (raw->msg[idx] << 8) | (raw->msg[idx+1]); and check bounds only after the fact. When idx == raw->curlen, raw->msg[idx+1] reads one byte past the received message data into the following struct fields (curchunk_len, curchunk_idx, curlen). Affected functions: - drm_dp_sideband_parse_enum_path_resources_ack() full_payload_bw_number and avail_payload_bw_number fields - drm_dp_sideband_parse_allocate_payload_ack() allocated_pbn field - drm_

    linux-raspiOperating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  6. CVE-2026-68273

    High · CVSS 7.8EPSS 0.13%No fix published

    drm/amdgpu: Fix context pstate override handling

    In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix context pstate override handling There are several problems in the context pstate handling code. The most serious ones are potential use-after-free and NULL pointer dereferences at context initialization time. Both are due amdgpu_ctx_init() not holding the adev->pm.stable_pstate_ctx_lock, which is otherwise used from both sysfs and the context code itself for modifying and clearing the stored context pointer. Second issue is that context fini can trample over the pstate configuration set via sysfs. This is due the restore state (ctx->stable_pstate) being s

    linux-raspiOperating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  7. CVE-2026-68272

    Not ratedEPSS 0.18%No fix published

    drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1

    In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk

    linux-raspiOperating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  8. CVE-2026-68271

    Not ratedEPSS 0.18%No fix published

    drm/nouveau: fix reversed error cleanup order in ucopy functions

    In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix reversed error cleanup order in ucopy functions nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it,

    linux-raspiOperating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  9. CVE-2026-68269

    Not ratedEPSS 0.21%No fix published

    drm/i915/gem: Add missing nospec on parallel submit slot

    In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Add missing nospec on parallel submit slot Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643)

    linux-raspiOperating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  10. CVE-2026-68266

    High · CVSS 7.8EPSS 0.14%No fix published

    drm/xe: Hold a dma-buf reference for imported BOs

    In the Linux kernel, the following vulnerability has been resolved: drm/xe: Hold a dma-buf reference for imported BOs An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter's dma_buf->resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:

    linux-raspiOperating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  11. CVE-2026-68263

    High · CVSS 7.8EPSS 0.12%No fix published

    drm/imagination: Fix double call to drm_sched_entity_fini()

    In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix double call to drm_sched_entity_fini() Call sequence of double call: pvr_context_destroy   pvr_context_kill_queues     pvr_queue_kill       drm_sched_entity_destroy         drm_sched_entity_fini // here   pvr_context_put     kref_put(..., pvr_context_release)       pvr_context_destroy_queues         pvr_queue_destroy           drm_sched_entity_fini // here Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls drm_sched_entity_flush() + drm_sched_entity_fini(). drm_sched_entity_flush() ensures all pending jobs are completed and drm_sch

    linux-raspiOperating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  12. CVE-2026-68262

    High · CVSS 7.1EPSS 0.13%No fix published

    drm/imagination: Fix user array stride in pvr_set_uobj_array()

    In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix user array stride in pvr_set_uobj_array() pvr_set_uobj_array() copies an array of kernel objects to a userspace array whose element size is described by out->stride. When out->stride is different from the kernel object size, the slow path advances the userspace pointer by the kernel object size and the kernel pointer by the userspace stride. This reverses the intended layout. For larger userspace strides, later copies read from the wrong kernel addresses. For smaller userspace strides, later copies are written at the wrong userspace offsets. The paddin

    linux-raspiOperating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  13. CVE-2026-68261

    Not ratedEPSS 0.21%No fix published

    drm/imagination: fix error checking of pvr_vm_context_lookup()

    In the Linux kernel, the following vulnerability has been resolved: drm/imagination: fix error checking of pvr_vm_context_lookup() Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop using IS_ERR() for checking the return value. Using IS_ERR() leads to the kernel oops reported below. It can be reproduced by passing an invalid VM context handle from userspace to the DRM_IOCTL_PVR_CREATE_CONTEXT ioctl. [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148 [ 92.742042] Mem abort info: [ 92.744890] ESR = 0x0000000096000004 [ 92.748686] EC = 0x25: DABT (current EL),

    linux-raspiOperating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  14. CVE-2026-68260

    High · CVSS 7.8EPSS 0.16%No fix published

    drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM

    In the Linux kernel, the following vulnerability has been resolved: drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [<ffff

    linux-raspiOperating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  15. CVE-2026-68259

    High · CVSS 7.1EPSS 0.17%No fix published

    drm/amdkfd: Check bounds in allocate_event_notification_slot

    In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds in allocate_event_notification_slot The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren't checking the bounds on that value. Check them. v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50)

    linux-raspiOperating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  16. CVE-2026-68258

    High · CVSS 7.1EPSS 0.13%No fix published

    drm/amdkfd: Check bounds on CRIU restore queue type and mqd size

    In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds on CRIU restore queue type and mqd size We weren't checking whether the values provided in the private data in kfd CRIU restore were within bounds. For queue type, add a KFD_QUEUE_TYPE_MAX and ensure the provided type is less than it. For mqd_size, add new function mqd_size_from_queue_type and confirm that the provided mqd_size matches expectations. (cherry picked from commit f19d8086f6644083c913d70bfdeee20e1b6f46a5)

    linux-raspiOperating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  17. CVE-2026-68257

    High · CVSS 7.8EPSS 0.14%No fix published

    drm/amdkfd: fix 32-bit overflow in CWSR total size calculation

    In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix 32-bit overflow in CWSR total size calculation total_cwsr_size was computed in 32-bit before being used as a BO/SVM allocation size. With large ctx_save_restore_area_size and debug_memory_size multiplied by the XCC count, the product can wrap, yielding an undersized CWSR save area that firmware later overruns. Promote total_cwsr_size to u64 and use check_add_overflow()/ check_mul_overflow() in both kfd_queue_acquire_buffers() and kfd_queue_release_buffers(). (cherry picked from commit 319f7e13423ae3f486b9aea82f9ad2d6af0ee608)

    linux-raspiOperating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  18. CVE-2026-68256

    Not ratedEPSS 0.18%No fix published

    drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference

    In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)

    linux-raspiOperating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  19. CVE-2026-68255

    High · CVSS 7.7EPSS 0.19%No fix published

    drm/virtio: bound EDID block reads to the response buffer

    In the Linux kernel, the following vulnerability has been resolved: drm/virtio: bound EDID block reads to the response buffer virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Confo

    linux-raspiOperating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  20. CVE-2026-68254

    Not ratedEPSS 0.17%No fix published

    drm/i915/vrr: require valid min/max vfreq for VRR

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

    linux-raspiOperating systems
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

Check your server

Check your installed stack and versions against the current vulnerability feeds.

Check your server →