Red Hat Linux Linux Kernel Vulnerabilities & Security Advisories
2132 advisories tracked · Red Hat Security Data API · 1 listed in the CISA Known Exploited Vulnerabilities catalog
Every row below is a published Red Hat Linux advisory that VulniPulse classified as Linux Kernel, with the CVEs, affected and fixed releases and exploitation status the vendor stated. Severity mix: 776 high, 1353 medium, 1 low.
Android app · Google Play
Monitor Red Hat CVEs from your phone.
Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 32 official vendor sources and 160+ reviewed platform categories.
Source
Red Hat Security Data API
Red Hat Enterprise Linux errata (RHSA) via the official Red Hat Security Data API — CVE severity, CVSS and affected packages. A credential-free official source.
Latest Red Hat Linux Kernel advisories
Medium [CVE-2026-68250] replace BUG_ON with WARN_ON
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af) A local attacker could potentially trigger a condition that would previously lead to a kernel panic due to a `BUG_ON()` macro. This vulnerability could result in a system-wide Denial of Service (DoS), making the system unresponsive. The issue has been resolved by replacing the `BUG_ON()` with `WARN_ON()`, which logs a warning instead of crashing the kernel. This issue affects AMDGPU SDMA 5.2. Certain error paths used BUG_ON(), forcing kernel panic. Systems without AMD GPUs are not affected. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-617. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat OpenShift Container Platform 4. Will not fix / out of support: Red Hat Enterprise Linux 6. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-68249] replace BUG_ON with WARN_ON
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d) This issue occurs when certain conditions trigger a `BUG_ON()` macro, which is designed to halt system execution upon detecting a critical error. A local attacker could exploit this to cause a kernel crash, leading to a denial of service (DoS) by making the system unavailable. This issue affects AMDGPU SDMA 5.0. Certain error paths used BUG_ON(), forcing kernel panic. A local user exercising those GPU paths could trigger denial of service. Systems without AMD GPUs are not affected. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-617. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat OpenShift Container Platform 4. Will not fix / out of support: Red Hat Enterprise Linux 6. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-68248] Return NULL on error in active_instance
In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832) This vulnerability occurs when the system experiences an Out-Of-Memory (OOM) condition during a specific memory allocation. An attacker could potentially trigger this condition, leading to an improper return value and causing a system crash, resulting in a Denial of Service (DoS). Returns address of NULL node container during GFP_ATOMIC allocation failure. Systems without Intel graphics are not affected. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-476. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-68247] range check LFP Data Block panel_type2
In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: range check LFP Data Block panel_type2 While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (Michał) - Add is_panel_type_pnp() (Ville) (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df) This component, responsible for display-related operations, failed to perform a necessary range check on the `panel_type2` field within the LFP Data Block. This oversight could result in the selection of an incorrect panel type, potentially impacting display functionality or system stability. This issue affects Intel i915 display BIOS parsing. Systems without Intel graphics are not affected. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-1285. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat Enterprise Linux for NVIDIA 26. Red Hat lists Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat OpenShift Container Platform 4 as not affected.
Medium [CVE-2026-68246] replace BUG_ON with WARN_ON
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd) A vulnerability in the `drm/amdgpu/gfx11` graphics driver could cause the system to crash. This issue arises from a condition that, when met, would trigger an error-handling mechanism designed to halt the kernel (BUG_ON()). An attacker with local access could potentially exploit this to cause a Denial of Service (DoS), rendering the system unusable. The fix replaces this critical error halt with a warning (WARN_ON()), preventing system instability. This issue affects AMDGPU GFX11 hardware. BUG_ON() on error paths forces kernel panic. Systems without AMD GPUs are not affected. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-617. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat OpenShift Container Platform 4. Will not fix / out of support: Red Hat Enterprise Linux 6. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-68244] Do not leak siblings on proto context error
In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff) An attacker could potentially exploit this to cause resource exhaustion, leading to a Denial of Service (DoS). Systems without Intel graphics are not affected. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-772. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-68243] Fix NULL deref in I915_CONTEXT_PARAM_SSEU
In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87) A local attacker could trigger a NULL dereference by setting a context engine slot to an invalid class and then attempting to apply specific parameters to that slot. This could lead to a system crash, resulting in a Denial of Service (DoS). This issue affects Intel i915 graphics. Systems without Intel graphics are not affected. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-476. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-68242] Fix NULL deref on sched_engine alloc failure
In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix NULL deref on sched_engine alloc failure Avoid using intel_context_put() before intel_context_init() in execlists_create_virtual() as the kref_put() inside would lead to NULL deref on the IOCTL path when sched_engine allocation fails. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d) A flaw was found in the Linux kernel's graphics subsystem (specifically drm/i915/gt). This vulnerability arises from an improper handling of memory allocation failures during graphics engine scheduling, which can lead to a null pointer dereference. A local attacker could exploit this issue to trigger a system crash, resulting in a Denial of Service (DoS). This issue affects Intel i915 virtual engine creation. intel_context_put() before intel_context_init() on sched_engine allocation failure causes NULL dereference. Systems without Intel graphics are not affected. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-476. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat Enterprise Linux for NVIDIA 26. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-68241] limit DP MST ESI service loop
In the Linux kernel, the following vulnerability has been resolved: drm/i915/mst: limit DP MST ESI service loop The loop in intel_dp_check_mst_status() keeps servicing interrupts originating from the sink without bound. Add an upper bound to the new interrupts occurring during interrupt processing to not get stuck on potentially stuck sink devices. Use arbitrary 32 tries to clear incoming interrupts in one go. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Note: The condition likely pre-dates the commit in the Fixes: tag, but this is about as far back as a backport has any chance of succeeding. Before that, the retry had a goto. (cherry picked from commit b4ea5272133059acb493cc36599071a9e852ec2e) A flaw was found in the Linux kernel's DisplayPort Multi-Stream Transport (MST) subsystem. An unbounded loop in the `intel_dp_check_mst_status()` function, responsible for servicing interrupts from a sink device, can lead to a system becoming unresponsive. A malicious or faulty DisplayPort MST sink device could exploit this to trigger a Denial of Service (DoS) condition. This issue affects systems using Intel i915 DisplayPort MST. intel_dp_check_mst_status() could loop indefinitely servicing sink interrupts from a stuck device, causing soft lockup. Systems without Intel graphics or DP MST are not affected.
Medium [CVE-2026-68240] publish dpagemap early to avoid device mapping leak on error
In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: publish dpagemap early to avoid device mapping leak on error drm_gpusvm_get_pages() only stored the local dpagemap into svm_pages->dpagemap on the success path. If a later page failed (e.g. -EOPNOTSUPP when ctx->allow_mixed is false) and jumped to err_unmap, svm_pages->dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped device_unmap() and leaked the device mappings already created. Assign svm_pages->dpagemap when the first device page is mapped so the err_unmap path can device_unmap() those mappings. This issue was found by Sashiko AI review. When drm_gpusvm_get_pages() encounters an error during page mapping, it fails to properly unmap previously created device mappings. This oversight can lead to a device mapping leak, consuming system resources and potentially impacting system stability or performance over time. This issue affects drm/gpusvm GPU shared virtual memory. On page mapping errors, device mappings created earlier were not unmapped because dpagemap was only stored on the success path. Systems without gpusvm are not affected. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-772. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-68238] Release VFCT ACPI table reference
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Release VFCT ACPI table reference amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table() but never releases it. acpi_get_table() takes a reference on the table (incrementing its validation_count and mapping it on the 0->1 transition); without a paired acpi_put_table() the mapping is leaked on every call, whether or not a matching VBIOS image is found. Route all exit paths after the table is acquired through a common acpi_put_table(). The VBIOS image is copied out with kmemdup() before the table is released, so it remains valid for the caller. (cherry picked from commit ca5988682b4cba4cd125a0fa99b2de1239164ae4) This oversight leads to a resource leak, where memory allocated for the table mapping is not properly freed, potentially impacting system stability over time. Systems without AMD GPUs are not affected. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-772. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat Enterprise Linux for NVIDIA 26; Red Hat OpenShift Container Platform 4. Will not fix / out of support: Red Hat Enterprise Linux 6; Red Hat Enterprise Linux for NVIDIA 26.
Medium [CVE-2026-68237] fix indefinite fence wait during GPU reset
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/userq: fix indefinite fence wait during GPU reset pre_reset only force-completes fences of MAPPED queues. A queue in any other state (e.g. mid-eviction) keeps its last_fence pending; after a GPU reset that fence never signals, so the eviction/suspend worker and process teardown (amdgpu_evf_mgr_flush_suspend) wait on it forever and wedge the machine: INFO: task kworker/6:28 blocked for more than 120 seconds. Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu] Call Trace: dma_fence_wait_timeout+0x7e/0x130 amdgpu_userq_evict+0x67/0x140 [amdgpu] amdgpu_eviction_fence_suspend_worker+0xd8/0x160 [amdgpu] process_scheduled_works+0xa6/0x420 Force-complete every queue's fence regardless of state. The unmap and mark-hung step stays gated on MAPPED, since unmapping a queue that is not mapped is invalid. (cherry picked from commit 9102b39fa924dcc3dc75a3137bfa9633c40b88c0) This can cause the eviction/suspend worker and process teardown to wait indefinitely, leading to a system hang and a Denial of Service. Moderate: A flaw in the `amdgpu` kernel driver can cause a system to hang indefinitely during a GPU reset operation. This issue affects Red Hat In-Vehicle OS and specific versions of Red Hat Enterprise Linux, potentially leading to system unresponsiveness.
Medium [CVE-2026-68235] skip non-DP stream encoders for DP MST
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: dce100: skip non-DP stream encoders for DP MST On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; and 4 more.
Medium [CVE-2026-68233] Shut down BO cache timer before teardown
In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Shut down BO cache timer before teardown The BO cache timer callback schedules time_work, and time_work can rearm the timer through vc4_bo_cache_free_old(). vc4_bo_cache_destroy() deletes the timer and then cancels the work, which does not break that cycle: the work being cancelled can rearm the timer, and the timer then queues work again after teardown. Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the cycle ends with cancel_work_sync(). A logic error in the BO cache timer shutdown process allows the timer to be rearmed even after it has been destroyed. This can lead to work being queued again after teardown, potentially causing system instability or a denial of service (DoS) due to improper resource management. This issue affects Raspberry Pi vc4 DRM. Systems without vc4 are not affected. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-821. Affected Red Hat products: Red Hat Enterprise Linux for NVIDIA 26; Red Hat OpenShift Container Platform 4. Will not fix / out of support: Red Hat Enterprise Linux for NVIDIA 26. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel.
Medium [CVE-2026-68232] Fix MM reference leak in drm_gpusvm_range_evict
In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM reference acquired earlier is not released, resulting in a reference leak. Fix this by dropping the MM reference on the kvmalloc_array() failure path. When the `kvmalloc_array()` function fails within `drm_gpusvm_range_evict()`, a previously acquired memory management (MM) reference is not properly released. This oversight leads to a reference leak, which can result in resource exhaustion and a Denial of Service (DoS) condition for the system. This issue affects systems using the drm/gpusvm GPU shared virtual memory interface. If kvmalloc_array() fails in drm_gpusvm_range_evict(), an acquired MM reference is not dropped, leaking address-space references. Systems without gpusvm-capable GPU drivers are not affected. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-911. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-68228] Move src_buf Removal to finish_encode
In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Move src_buf Removal to finish_encode During encoder processing, there is a case where the IRQ response could return the buffer back to userspace via v4l2_m2m_buf_done call. In this time, userspace could queue up this same buffer before start_encode removes the index from the ready queue. This would then lead to a case where the buffer in the ready queue could be a self loop due to the WRITE_ONCE(prev->next, new) call in __list_add. When __list_del is finally called, the loop is already made so nothing points back to ready queue list head and pointers are poisoned. A buffer should not be marked as DONE before the buffer is removed from m2m ready queue. A local user could exploit a race condition during encoder processing, where a buffer is returned to userspace before being fully removed from the ready queue. This could lead to a corrupted buffer list, potentially causing a system crash and resulting in a denial of service. This issue affects Chips&Media wave5 video encoder. src_buf removed too early relative to IRQ buffer return race. Systems without wave5 encoder are not affected. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-367. Affected Red Hat products: Red Hat Enterprise Linux for NVIDIA 26.
Medium [CVE-2026-68218] Free allocated workqueue
In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak. This issue arises from the driver's failure to properly deallocate resources, specifically a workqueue, when the device is removed. This oversight can lead to a memory leak, which a local attacker could potentially exploit to cause a denial of service (DoS) by exhausting system memory. This issue affects systems using the dm1105 DVB PCI adapter driver. The driver allocates a workqueue on probe but does not destroy it on remove, leaking memory. Systems without dm1105 hardware are not affected. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-772. Affected Red Hat products: Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat OpenShift Container Platform 4. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-68217] Drain fill_buf on start_streaming failure
In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0],..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 ("[media] pwc: fix WARN_ON"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; and 2 more.
Medium [CVE-2026-68216] Return queued buffers on start_streaming failure
In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). When the `start_streaming()` function fails, it does not properly return queued buffers, leading to a resource leak. This can occur if the USB device is disconnected or if a mutex lock is interrupted. A local attacker could potentially exploit this to cause a Denial of Service (DoS) due to resource exhaustion. This issue affects systems using Philips WebCam (pwc) USB cameras. If start_streaming() fails after buffers are queued, those buffers are not returned to videobuf2, causing a buffer leak. Systems without pwc hardware are not affected.
Medium [CVE-2026-68214] fix use-after-free in rtl2832_remove
In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final. A timing issue during the removal of the `rtl2832` device can lead to a use-after-free vulnerability. This occurs when the system attempts to access memory that has already been released, which can cause system instability or a denial of service (DoS). A local attacker could potentially exploit this flaw.