https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 08:11:13 +0000 https://cve.radiocsirt.org/vuln/bdu:2025-03177 bdu:2025-03177 https://cve.radiocsirt.org/vuln/bdu:2025-03177 https://cve.radiocsirt.org/vuln/bell-cve-2024-44956 <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2024-44956 https://cve.radiocsirt.org/vuln/certfr-2024-avi-1080 certfr-2024-avi-1080 https://cve.radiocsirt.org/vuln/certfr-2024-avi-1080 https://cve.radiocsirt.org/vuln/euvd-2026-313179 EUVD-2026-313179 https://cve.radiocsirt.org/vuln/euvd-2026-313179 https://cve.radiocsirt.org/vuln/fkie_cve-2024-44956 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/xe/preempt_fence: enlarge the fence critical section</p> <p>It is really easy to introduce subtle deadlocks in preempt_fence_work_func() since we operate on single global ordered-wq for signalling our preempt fences behind the scenes, so even though we signal a particular fence, everything in the callback should be in the fence critical section, since blocking in the callback will prevent other published fences from signalling. If we enlarge the fence critical section to cover the entire callback, then lockdep should be able to understand this better, and complain if we grab a sensitive lock like vm-&gt;lock, which is also held when waiting on preempt fences.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/xe/preempt_fence: enlarge the fence critical section</p> <p>It is really easy to introduce subtle deadlocks in preempt_fence_work_func() since we operate on single global ordered-wq for signalling our preempt fences behind the scenes, so even though we signal a particular fence, everything in the callback should be in the fence critical section, since blocking in the callback will prevent other published fences from signalling. If we enlarge the fence critical section to cover the entire callback, then lockdep should be able to understand this better, and complain if we grab a sensitive lock like vm-&gt;lock, which is also held when waiting on preempt fences.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2024-44956 https://cve.radiocsirt.org/vuln/ghsa-q2gx-5vc4-pjjw <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/xe/preempt_fence: enlarge the fence critical section</p> <p>It is really easy to introduce subtle deadlocks in preempt_fence_work_func() since we operate on single global ordered-wq for signalling our preempt fences behind the scenes, so even though we signal a particular fence, everything in the callback should be in the fence critical section, since blocking in the callback will prevent other published fences from signalling. If we enlarge the fence critical section to cover the entire callback, then lockdep should be able to understand this better, and complain if we grab a sensitive lock like vm-&gt;lock, which is also held when waiting on preempt fences.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/xe/preempt_fence: enlarge the fence critical section</p> <p>It is really easy to introduce subtle deadlocks in preempt_fence_work_func() since we operate on single global ordered-wq for signalling our preempt fences behind the scenes, so even though we signal a particular fence, everything in the callback should be in the fence critical section, since blocking in the callback will prevent other published fences from signalling. If we enlarge the fence critical section to cover the entire callback, then lockdep should be able to understand this better, and complain if we grab a sensitive lock like vm-&gt;lock, which is also held when waiting on preempt fences.</p> https://cve.radiocsirt.org/vuln/ghsa-q2gx-5vc4-pjjw https://cve.radiocsirt.org/vuln/msrc_cve-2024-44956 msrc_CVE-2024-44956 https://cve.radiocsirt.org/vuln/msrc_cve-2024-44956 https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-44956 <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 91 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: drm/xe/preempt_fence: enlarge the fence critical section It is really easy to introduce subtle deadlocks in preempt_fence_work_func() since we operate on single global ordered-wq for signalling our preempt fences behind the scenes, so even though we signal a particular fence, everything in the callback should be in the fence critical section, since blocking in the callback will prevent other published fences from signalling. If we enlarge the fence critical section to cover the entire callback, then lockdep should be able to understand this better, and complain if we grab a sensitive lock like vm-&gt;lock, which is also held when waiting on preempt fences.</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 91 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: drm/xe/preempt_fence: enlarge the fence critical section It is really easy to introduce subtle deadlocks in preempt_fence_work_func() since we operate on single global ordered-wq for signalling our preempt fences behind the scenes, so even though we signal a particular fence, everything in the callback should be in the fence critical section, since blocking in the callback will prevent other published fences from signalling. If we enlarge the fence critical section to cover the entire callback, then lockdep should be able to understand this better, and complain if we grab a sensitive lock like vm-&gt;lock, which is also held when waiting on preempt fences.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-44956 https://cve.radiocsirt.org/vuln/wid-sec-w-2024-2057 <p>Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder weitere unspezifische Angriffe durchzuführen.</p> <p>Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder weitere unspezifische Angriffe durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2024-2057