https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 16:34:32 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-06037 bdu:2026-06037 https://cve.radiocsirt.org/vuln/bdu:2026-06037 https://cve.radiocsirt.org/vuln/bell-cve-2023-53378 <p><strong>Affected:</strong> Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2023-53378 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0895 certfr-2025-avi-0895 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0895 https://cve.radiocsirt.org/vuln/euvd-2026-345195 EUVD-2026-345195 https://cve.radiocsirt.org/vuln/euvd-2026-345195 https://cve.radiocsirt.org/vuln/fkie_cve-2023-53378 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/i915/dpt: Treat the DPT BO as a framebuffer</p> <p>Currently i915_gem_object_is_framebuffer() doesn&#39;t treat the BO containing the framebuffer&#39;s DPT as a framebuffer itself. This means eg. that the shrinker can evict the DPT BO while leaving the actual FB BO bound, when the DPT is allocated from regular shmem.</p> <p>That causes an immediate oops during hibernate as we try to rewrite the PTEs inside the already evicted DPT obj.</p> <p>TODO: presumably this might also be the reason for the DPT related display faults under heavy memory pressure, but I&#39;m still not sure how that would happen as the object should be pinned by intel_dpt_pin() while in active use by the display engine...</p> <p>(cherry picked from commit 779cb5ba64ec7df80675a956c9022929514f517a)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/i915/dpt: Treat the DPT BO as a framebuffer</p> <p>Currently i915_gem_object_is_framebuffer() doesn&#39;t treat the BO containing the framebuffer&#39;s DPT as a framebuffer itself. This means eg. that the shrinker can evict the DPT BO while leaving the actual FB BO bound, when the DPT is allocated from regular shmem.</p> <p>That causes an immediate oops during hibernate as we try to rewrite the PTEs inside the already evicted DPT obj.</p> <p>TODO: presumably this might also be the reason for the DPT related display faults under heavy memory pressure, but I&#39;m still not sure how that would happen as the object should be pinned by intel_dpt_pin() while in active use by the display engine...</p> <p>(cherry picked from commit 779cb5ba64ec7df80675a956c9022929514f517a)</p> https://cve.radiocsirt.org/vuln/fkie_cve-2023-53378 https://cve.radiocsirt.org/vuln/ghsa-53wx-c6fx-gwfp <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/i915/dpt: Treat the DPT BO as a framebuffer</p> <p>Currently i915_gem_object_is_framebuffer() doesn&#39;t treat the BO containing the framebuffer&#39;s DPT as a framebuffer itself. This means eg. that the shrinker can evict the DPT BO while leaving the actual FB BO bound, when the DPT is allocated from regular shmem.</p> <p>That causes an immediate oops during hibernate as we try to rewrite the PTEs inside the already evicted DPT obj.</p> <p>TODO: presumably this might also be the reason for the DPT related display faults under heavy memory pressure, but I&#39;m still not sure how that would happen as the object should be pinned by intel_dpt_pin() while in active use by the display engine...</p> <p>(cherry picked from commit 779cb5ba64ec7df80675a956c9022929514f517a)</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/i915/dpt: Treat the DPT BO as a framebuffer</p> <p>Currently i915_gem_object_is_framebuffer() doesn&#39;t treat the BO containing the framebuffer&#39;s DPT as a framebuffer itself. This means eg. that the shrinker can evict the DPT BO while leaving the actual FB BO bound, when the DPT is allocated from regular shmem.</p> <p>That causes an immediate oops during hibernate as we try to rewrite the PTEs inside the already evicted DPT obj.</p> <p>TODO: presumably this might also be the reason for the DPT related display faults under heavy memory pressure, but I&#39;m still not sure how that would happen as the object should be pinned by intel_dpt_pin() while in active use by the display engine...</p> <p>(cherry picked from commit 779cb5ba64ec7df80675a956c9022929514f517a)</p> https://cve.radiocsirt.org/vuln/ghsa-53wx-c6fx-gwfp https://cve.radiocsirt.org/vuln/suse-su-2025:03615-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2025:03615-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53378 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 78 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: drm/i915/dpt: Treat the DPT BO as a framebuffer Currently i915_gem_object_is_framebuffer() doesn&#39;t treat the BO containing the framebuffer&#39;s DPT as a framebuffer itself. This means eg. that the shrinker can evict the DPT BO while leaving the actual FB BO bound, when the DPT is allocated from regular shmem. That causes an immediate oops during hibernate as we try to rewrite the PTEs inside the already evicted DPT obj. TODO: presumably this might also be the reason for the DPT related display faults under heavy memory pressure, but I&#39;m still not sure how that would happen as the object should be pinned by intel_dpt_pin() while in active use by the display engine... (cherry picked from commit 779cb5ba64ec7df80675a956c9022929514f517a)</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 78 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: drm/i915/dpt: Treat the DPT BO as a framebuffer Currently i915_gem_object_is_framebuffer() doesn&#39;t treat the BO containing the framebuffer&#39;s DPT as a framebuffer itself. This means eg. that the shrinker can evict the DPT BO while leaving the actual FB BO bound, when the DPT is allocated from regular shmem. That causes an immediate oops during hibernate as we try to rewrite the PTEs inside the already evicted DPT obj. TODO: presumably this might also be the reason for the DPT related display faults under heavy memory pressure, but I&#39;m still not sure how that would happen as the object should be pinned by intel_dpt_pin() while in active use by the display engine... (cherry picked from commit 779cb5ba64ec7df80675a956c9022929514f517a)</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53378 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2092 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen und um nicht nähere beschriebene Effekte zu verursachen.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen und um nicht nähere beschriebene Effekte zu verursachen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2092