<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-03T01:49:23.614526+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bdu:2025-13905</id>
    <title>bdu:2025-13905</title>
    <updated>2026-10-03T01:49:23.799987+00:00</updated>
    <content>bdu:2025-13905</content>
    <link href="https://cve.radiocsirt.org/vuln/bdu:2025-13905"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bell-cve-2024-50144</id>
    <title>BELL-CVE-2024-50144</title>
    <updated>2026-10-03T01:49:23.800036+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/bell-cve-2024-50144"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0152</id>
    <title>certfr-2025-avi-0152 — De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un a…</title>
    <updated>2026-10-03T01:49:23.800067+00:00</updated>
    <content>certfr-2025-avi-0152</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2025-avi-0152"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/cnvd-2024-46399</id>
    <title>cnvd-2024-46399</title>
    <updated>2026-10-03T01:49:23.800085+00:00</updated>
    <content>cnvd-2024-46399</content>
    <link href="https://cve.radiocsirt.org/vuln/cnvd-2024-46399"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-313505</id>
    <title>EUVD-2026-313505</title>
    <updated>2026-10-03T01:49:23.800097+00:00</updated>
    <content>EUVD-2026-313505</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-313505"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2024-50144</id>
    <title>fkie_cve-2024-50144</title>
    <updated>2026-10-03T01:49:23.800108+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>drm/xe: fix unbalanced rpm put() with fence_fini()</p>
<p>Currently we can call fence_fini() twice if something goes wrong when
sending the GuC CT for the tlb request, since we signal the fence and
return an error, leading to the caller also calling fini() on the error
path in the case of stack version of the flow, which leads to an extra
rpm put() which might later cause device to enter suspend when it
shouldn't. It looks like we can just drop the fini() call since the
fence signaller side will already call this for us.</p>
<p>There are known mysterious splats with device going to sleep even with
an rpm ref, and this could be one candidate.</p>
<p>v2 (Matt B):
  - Prefer warning if we detect double fini()</p>
<p>(cherry picked from commit cfcbc0520d5055825f0647ab922b655688605183)</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2024-50144"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-cjjp-gcwg-8fxm</id>
    <title>GHSA-cjjp-gcwg-8fxm</title>
    <updated>2026-10-03T01:49:23.800140+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>drm/xe: fix unbalanced rpm put() with fence_fini()</p>
<p>Currently we can call fence_fini() twice if something goes wrong when
sending the GuC CT for the tlb request, since we signal the fence and
return an error, leading to the caller also calling fini() on the error
path in the case of stack version of the flow, which leads to an extra
rpm put() which might later cause device to enter suspend when it
shouldn't. It looks like we can just drop the fini() call since the
fence signaller side will already call this for us.</p>
<p>There are known mysterious splats with device going to sleep even with
an rpm ref, and this could be one candidate.</p>
<p>v2 (Matt B):
  - Prefer warning if we detect double fini()</p>
<p>(cherry picked from commit cfcbc0520d5055825f0647ab922b655688605183)</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-cjjp-gcwg-8fxm"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/opensuse-su-2024:14500-1</id>
    <title>openSUSE-SU-2024:14500-1 — kernel-devel-6.11.8-1.1 on GA media</title>
    <updated>2026-10-03T01:49:23.800163+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>kernel-devel-6.11.8-1.1 on GA media</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/opensuse-su-2024:14500-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-50144</id>
    <title>UBUNTU-CVE-2024-50144</title>
    <updated>2026-10-03T01:49:23.800446+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><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 67 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: drm/xe: fix unbalanced rpm put() with fence_fini() Currently we can call fence_fini() twice if something goes wrong when sending the GuC CT for the tlb request, since we signal the fence and return an error, leading to the caller also calling fini() on the error path in the case of stack version of the flow, which leads to an extra rpm put() which might later cause device to enter suspend when it shouldn't. It looks like we can just drop the fini() call since the fence signaller side will already call this for us. There are known mysterious splats with device going to sleep even with an rpm ref, and this could be one candidate. v2 (Matt B):   - Prefer warning if we detect double fini() (cherry picked from commit cfcbc0520d5055825f0647ab922b655688605183)</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-50144"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3367</id>
    <title>WID-SEC-W-2024-3367 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
    <updated>2026-10-03T01:49:23.800580+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht näher beschriebene Auswirkungen zu erzielen.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3367"/>
  </entry>
</feed>
