<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 02 Oct 2026 13:04:57 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-12569</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-12569</link>
      <description>bdu:2026-12569</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-12569</guid>
    </item>
    <item>
      <title>BELL-CVE-2026-31576</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-31576</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-31576</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0548 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Certaines d'entre elles permettent à un…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0548</link>
      <description>certfr-2026-avi-0548</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0548</guid>
    </item>
    <item>
      <title>EUVD-2026-327008</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-327008</link>
      <description>EUVD-2026-327008</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-327008</guid>
    </item>
    <item>
      <title>fkie_cve-2026-31576</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-31576</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: hackrf: fix to not free memory after the device is registered in hackrf_probe()&lt;/p&gt;
&lt;p&gt;In hackrf driver, the following race condition occurs:
```
		CPU0						CPU1
hackrf_probe()
  kzalloc(); // alloc hackrf_dev
  ....
  v4l2_device_register();
  ....
						fd = sys_open(&amp;#34;/path/to/dev&amp;#34;); // open hackrf fd
						....
  v4l2_device_unregister();
  ....
  kfree(); // free hackrf_dev
  ....
						sys_ioctl(fd, ...);
						  v4l2_ioctl();
						    video_is_registered() // UAF!!
						....
						sys_close(fd);
						  v4l2_release() // UAF!!
						    hackrf_video_release()
						      kfree(); // DFB!!
```&lt;/p&gt;
&lt;p&gt;When a V4L2 or video device is unregistered, the device node is removed so
new open() calls are blocked.&lt;/p&gt;
&lt;p&gt;However, file descriptors that are already open-and any in-flight I/O-do
not terminate immediately; they remain valid until the last reference is
dropped and the driver&amp;#39;s release() is invoked.&lt;/p&gt;
&lt;p&gt;Therefore, freeing device memory on the error path after hackrf_probe()
has registered dev it will lead to a race to use-after-free vuln, since
those already-open handles haven&amp;#39;t been released yet.&lt;/p&gt;
&lt;p&gt;And since release() free memory too, race to use-after-free and
double-free vuln occur.&lt;/p&gt;
&lt;p&gt;To prevent this, if device is registered from probe(), it should be
modified to free memory only through release() rather than calling
kfree() directly.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: hackrf: fix to not free memory after the device is registered in hackrf_probe()&lt;/p&gt;
&lt;p&gt;In hackrf driver, the following race condition occurs:
```
		CPU0						CPU1
hackrf_probe()
  kzalloc(); // alloc hackrf_dev
  ....
  v4l2_device_register();
  ....
						fd = sys_open(&amp;#34;/path/to/dev&amp;#34;); // open hackrf fd
						....
  v4l2_device_unregister();
  ....
  kfree(); // free hackrf_dev
  ....
						sys_ioctl(fd, ...);
						  v4l2_ioctl();
						    video_is_registered() // UAF!!
						....
						sys_close(fd);
						  v4l2_release() // UAF!!
						    hackrf_video_release()
						      kfree(); // DFB!!
```&lt;/p&gt;
&lt;p&gt;When a V4L2 or video device is unregistered, the device node is removed so
new open() calls are blocked.&lt;/p&gt;
&lt;p&gt;However, file descriptors that are already open-and any in-flight I/O-do
not terminate immediately; they remain valid until the last reference is
dropped and the driver&amp;#39;s release() is invoked.&lt;/p&gt;
&lt;p&gt;Therefore, freeing device memory on the error path after hackrf_probe()
has registered dev it will lead to a race to use-after-free vuln, since
those already-open handles haven&amp;#39;t been released yet.&lt;/p&gt;
&lt;p&gt;And since release() free memory too, race to use-after-free and
double-free vuln occur.&lt;/p&gt;
&lt;p&gt;To prevent this, if device is registered from probe(), it should be
modified to free memory only through release() rather than calling
kfree() directly.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-31576</guid>
    </item>
    <item>
      <title>GHSA-9h3v-wrpm-q7m5</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-9h3v-wrpm-q7m5</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: hackrf: fix to not free memory after the device is registered in hackrf_probe()&lt;/p&gt;
&lt;p&gt;In hackrf driver, the following race condition occurs:
```
		CPU0						CPU1
hackrf_probe()
  kzalloc(); // alloc hackrf_dev
  ....
  v4l2_device_register();
  ....
						fd = sys_open(&amp;#34;/path/to/dev&amp;#34;); // open hackrf fd
						....
  v4l2_device_unregister();
  ....
  kfree(); // free hackrf_dev
  ....
						sys_ioctl(fd, ...);
						  v4l2_ioctl();
						    video_is_registered() // UAF!!
						....
						sys_close(fd);
						  v4l2_release() // UAF!!
						    hackrf_video_release()
						      kfree(); // DFB!!
```&lt;/p&gt;
&lt;p&gt;When a V4L2 or video device is unregistered, the device node is removed so
new open() calls are blocked.&lt;/p&gt;
&lt;p&gt;However, file descriptors that are already open-and any in-flight I/O-do
not terminate immediately; they remain valid until the last reference is
dropped and the driver&amp;#39;s release() is invoked.&lt;/p&gt;
&lt;p&gt;Therefore, freeing device memory on the error path after hackrf_probe()
has registered dev it will lead to a race to use-after-free vuln, since
those already-open handles haven&amp;#39;t been released yet.&lt;/p&gt;
&lt;p&gt;And since release() free memory too, race to use-after-free and
double-free vuln occur.&lt;/p&gt;
&lt;p&gt;To prevent this, if device is registered from probe(), it should be
modified to free memory only through release() rather than calling
kfree() directly.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: hackrf: fix to not free memory after the device is registered in hackrf_probe()&lt;/p&gt;
&lt;p&gt;In hackrf driver, the following race condition occurs:
```
		CPU0						CPU1
hackrf_probe()
  kzalloc(); // alloc hackrf_dev
  ....
  v4l2_device_register();
  ....
						fd = sys_open(&amp;#34;/path/to/dev&amp;#34;); // open hackrf fd
						....
  v4l2_device_unregister();
  ....
  kfree(); // free hackrf_dev
  ....
						sys_ioctl(fd, ...);
						  v4l2_ioctl();
						    video_is_registered() // UAF!!
						....
						sys_close(fd);
						  v4l2_release() // UAF!!
						    hackrf_video_release()
						      kfree(); // DFB!!
```&lt;/p&gt;
&lt;p&gt;When a V4L2 or video device is unregistered, the device node is removed so
new open() calls are blocked.&lt;/p&gt;
&lt;p&gt;However, file descriptors that are already open-and any in-flight I/O-do
not terminate immediately; they remain valid until the last reference is
dropped and the driver&amp;#39;s release() is invoked.&lt;/p&gt;
&lt;p&gt;Therefore, freeing device memory on the error path after hackrf_probe()
has registered dev it will lead to a race to use-after-free vuln, since
those already-open handles haven&amp;#39;t been released yet.&lt;/p&gt;
&lt;p&gt;And since release() free memory too, race to use-after-free and
double-free vuln occur.&lt;/p&gt;
&lt;p&gt;To prevent this, if device is registered from probe(), it should be
modified to free memory only through release() rather than calling
kfree() directly.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-9h3v-wrpm-q7m5</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-31576 — media: hackrf: fix to not free memory after the device is registered in hackrf_probe()</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-31576</link>
      <description>msrc_CVE-2026-31576</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-31576</guid>
    </item>
    <item>
      <title>OESA-2026-3317 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-3317</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/amdgpu: prevent immediate PASID reuse case&lt;/p&gt;
&lt;p&gt;PASID resue could cause interrupt issue when process
immediately runs into hw state left by previous
process exited with the same PASID, it&amp;amp;apos;s possible that
page faults are still pending in the IH ring buffer when
the process exits and frees up its PASID. To prevent the
case, it uses idr cyclic allocator same as kernel pid&amp;amp;apos;s.&lt;/p&gt;
&lt;p&gt;(cherry picked from commit 8f1de51f49be692de137c8525106e0fce2d1912d)(CVE-2026-31462)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: hackrf: fix to not free memory after the device is registered in hackrf_probe()&lt;/p&gt;
&lt;p&gt;In hackrf driver, the following race condition occurs:
```
		CPU0						CPU1
hackrf_probe()
  kzalloc(); // alloc hackrf_dev
  ....
  v4l2_device_register();
  ....
						fd = sys_open(&amp;amp;quot;/path/to/dev&amp;amp;quot;); // open hackrf fd
						....
  v4l2_device_unregister();
  ....
  kfree(); // free hackrf_dev
  ....
						sys_ioctl(fd, ...);
						  v4l2_ioctl();
						    video_is_registered() // UAF!!
						....
						sys_close(fd);
						  v4l2_release() // UAF!!
						    hackrf_video_release()
						      kfree(); // DFB!!
```&lt;/p&gt;
&lt;p&gt;When a V4L2 or video device is unregistered, the device node is removed so
new open() calls are blocked.&lt;/p&gt;
&lt;p&gt;However, file descriptors that are already open-and any in-flight I/O-do
not terminate i…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/amdgpu: prevent immediate PASID reuse case&lt;/p&gt;
&lt;p&gt;PASID resue could cause interrupt issue when process
immediately runs into hw state left by previous
process exited with the same PASID, it&amp;amp;apos;s possible that
page faults are still pending in the IH ring buffer when
the process exits and frees up its PASID. To prevent the
case, it uses idr cyclic allocator same as kernel pid&amp;amp;apos;s.&lt;/p&gt;
&lt;p&gt;(cherry picked from commit 8f1de51f49be692de137c8525106e0fce2d1912d)(CVE-2026-31462)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: hackrf: fix to not free memory after the device is registered in hackrf_probe()&lt;/p&gt;
&lt;p&gt;In hackrf driver, the following race condition occurs:
```
		CPU0						CPU1
hackrf_probe()
  kzalloc(); // alloc hackrf_dev
  ....
  v4l2_device_register();
  ....
						fd = sys_open(&amp;amp;quot;/path/to/dev&amp;amp;quot;); // open hackrf fd
						....
  v4l2_device_unregister();
  ....
  kfree(); // free hackrf_dev
  ....
						sys_ioctl(fd, ...);
						  v4l2_ioctl();
						    video_is_registered() // UAF!!
						....
						sys_close(fd);
						  v4l2_release() // UAF!!
						    hackrf_video_release()
						      kfree(); // DFB!!
```&lt;/p&gt;
&lt;p&gt;When a V4L2 or video device is unregistered, the device node is removed so
new open() calls are blocked.&lt;/p&gt;
&lt;p&gt;However, file descriptors that are already open-and any in-flight I/O-do
not terminate i…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-3317</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:10703-1 — kernel-devel-7.0.3-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:10703-1</link>
      <description>&lt;p&gt;kernel-devel-7.0.3-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-7.0.3-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:10703-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:23066-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:23066-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2026:23066-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-31576</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31576</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:16.04:LTS: linux-hwe-edge and 243 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: media: hackrf: fix to not free memory after the device is registered in hackrf_probe() In hackrf driver, the following race condition occurs: ``` 		CPU0						CPU1 hackrf_probe()   kzalloc(); // alloc hackrf_dev   ....   v4l2_device_register();   .... 						fd = sys_open(&amp;#34;/path/to/dev&amp;#34;); // open hackrf fd 						....   v4l2_device_unregister();   ....   kfree(); // free hackrf_dev   .... 						sys_ioctl(fd, ...); 						  v4l2_ioctl(); 						    video_is_registered() // UAF!! 						.... 						sys_close(fd); 						  v4l2_release() // UAF!! 						    hackrf_video_release() 						      kfree(); // DFB!! ``` When a V4L2 or video device is unregistered, the device node is removed so new open() calls are blocked. However, file descriptors that are already open-and any in-flight I/O-do not terminate immediately; they remain valid until the last reference is dropped and the driver&amp;#39;s release() is invoked. Therefore, freeing device memory on the error path after hackrf_probe() has registered dev it will lead to a race to use-after-free vuln, since those already-open handles haven&amp;#39;t been released yet. And since release() free memory too, race to use-after-free and double-free vuln occur. To prevent this, if device is registered from probe(), it should be modified to free memory only through release() rather than calling kfree() directly.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:16.04:LTS: linux-hwe-edge and 243 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: media: hackrf: fix to not free memory after the device is registered in hackrf_probe() In hackrf driver, the following race condition occurs: ``` 		CPU0						CPU1 hackrf_probe()   kzalloc(); // alloc hackrf_dev   ....   v4l2_device_register();   .... 						fd = sys_open(&amp;#34;/path/to/dev&amp;#34;); // open hackrf fd 						....   v4l2_device_unregister();   ....   kfree(); // free hackrf_dev   .... 						sys_ioctl(fd, ...); 						  v4l2_ioctl(); 						    video_is_registered() // UAF!! 						.... 						sys_close(fd); 						  v4l2_release() // UAF!! 						    hackrf_video_release() 						      kfree(); // DFB!! ``` When a V4L2 or video device is unregistered, the device node is removed so new open() calls are blocked. However, file descriptors that are already open-and any in-flight I/O-do not terminate immediately; they remain valid until the last reference is dropped and the driver&amp;#39;s release() is invoked. Therefore, freeing device memory on the error path after hackrf_probe() has registered dev it will lead to a race to use-after-free vuln, since those already-open handles haven&amp;#39;t been released yet. And since release() free memory too, race to use-after-free and double-free vuln occur. To prevent this, if device is registered from probe(), it should be modified to free memory only through release() rather than calling kfree() directly.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31576</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1279 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1279</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, welche zu einem Denial-of-Service-Zustand, einer Rechteausweitung, der Ausführung von Code oder einer Speicherbeschädigung führen könnten.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, welche zu einem Denial-of-Service-Zustand, einer Rechteausweitung, der Ausführung von Code oder einer Speicherbeschädigung führen könnten.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1279</guid>
    </item>
  </channel>
</rss>
