<?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-03T17:27:25.286070+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/bell-cve-2025-39941</id>
    <title>BELL-CVE-2025-39941</title>
    <updated>2026-10-03T17:27:25.373157+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p><strong>Affected:</strong> Alpaquita:stream: linux-lts</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/bell-cve-2025-39941"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-347260</id>
    <title>EUVD-2026-347260</title>
    <updated>2026-10-03T17:27:25.373212+00:00</updated>
    <content>EUVD-2026-347260</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-347260"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2025-39941</id>
    <title>fkie_cve-2025-39941</title>
    <updated>2026-10-03T17:27:25.373234+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>zram: fix slot write race condition</p>
<p>Parallel concurrent writes to the same zram index result in leaked
zsmalloc handles.  Schematically we can have something like this:</p>
<p>CPU0                              CPU1
zram_slot_lock()
zs_free(handle)
zram_slot_lock()
				zram_slot_lock()
				zs_free(handle)
				zram_slot_lock()</p>
<p>compress			compress
handle = zs_malloc()		handle = zs_malloc()
zram_slot_lock
zram_set_handle(handle)
zram_slot_lock
				zram_slot_lock
				zram_set_handle(handle)
				zram_slot_lock</p>
<p>Either CPU0 or CPU1 zsmalloc handle will leak because zs_free() is done
too early.  In fact, we need to reset zram entry right before we set its
new handle, all under the same slot lock scope.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2025-39941"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-mjg7-65xv-hcjw</id>
    <title>GHSA-mjg7-65xv-hcjw</title>
    <updated>2026-10-03T17:27:25.373299+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>zram: fix slot write race condition</p>
<p>Parallel concurrent writes to the same zram index result in leaked
zsmalloc handles.  Schematically we can have something like this:</p>
<p>CPU0                              CPU1
zram_slot_lock()
zs_free(handle)
zram_slot_lock()
				zram_slot_lock()
				zs_free(handle)
				zram_slot_lock()</p>
<p>compress			compress
handle = zs_malloc()		handle = zs_malloc()
zram_slot_lock
zram_set_handle(handle)
zram_slot_lock
				zram_slot_lock
				zram_set_handle(handle)
				zram_slot_lock</p>
<p>Either CPU0 or CPU1 zsmalloc handle will leak because zs_free() is done
too early.  In fact, we need to reset zram entry right before we set its
new handle, all under the same slot lock scope.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-mjg7-65xv-hcjw"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-39941</id>
    <title>UBUNTU-CVE-2025-39941</title>
    <updated>2026-10-03T17:27:25.373368+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 89 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: zram: fix slot write race condition Parallel concurrent writes to the same zram index result in leaked zsmalloc handles.  Schematically we can have something like this: CPU0                              CPU1 zram_slot_lock() zs_free(handle) zram_slot_lock() 				zram_slot_lock() 				zs_free(handle) 				zram_slot_lock() compress			compress handle = zs_malloc()		handle = zs_malloc() zram_slot_lock zram_set_handle(handle) zram_slot_lock 				zram_slot_lock 				zram_set_handle(handle) 				zram_slot_lock Either CPU0 or CPU1 zsmalloc handle will leak because zs_free() is done too early.  In fact, we need to reset zram entry right before we set its new handle, all under the same slot lock scope.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-39941"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2194</id>
    <title>WID-SEC-W-2025-2194 — Linux Kernel: Mehrere Schwachstellen</title>
    <updated>2026-10-03T17:27:25.373829+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2194"/>
  </entry>
</feed>
