<?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>Sun, 04 Oct 2026 03:12:09 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-64539</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-64539</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-64539</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0981 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Elles permettent à un attaquant de provo…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0981</link>
      <description>certfr-2026-avi-0981</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0981</guid>
    </item>
    <item>
      <title>EUVD-2026-353418</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-353418</link>
      <description>EUVD-2026-353418</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-353418</guid>
    </item>
    <item>
      <title>fkie_cve-2026-64539</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-64539</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;Bluetooth: eir: Fix stack OOB write when prepending the Flags AD&lt;/p&gt;
&lt;p&gt;eir_create_adv_data() builds the advertising data into a fixed-size
buffer (&amp;#34;size&amp;#34;, 31 for the legacy path). It may prepend a 3-byte &amp;#34;Flags&amp;#34;
AD structure (LE_AD_NO_BREDR on an LE-only controller) and then copies
the per-instance data without checking that it still fits:&lt;/p&gt;
&lt;p&gt;memcpy(ptr, adv-&amp;gt;adv_data, adv-&amp;gt;adv_data_len);&lt;/p&gt;
&lt;p&gt;tlv_data_max_len() only reserves those 3 bytes when the user-supplied
flags carry a managed-flags bit, so an instance added with flags == 0 is
accepted with adv_data_len up to the full buffer. At advertise time the
flags are still prepended, and the memcpy() writes 3 + adv_data_len
bytes into the size-byte buffer:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir.c:301)
  Write of size 31 at addr ffff88800a547bdc by task kworker/u9:0/65
  Workqueue: hci0 hci_cmd_sync_work
   __asan_memcpy (mm/kasan/shadow.c:106)
   eir_create_adv_data (net/bluetooth/eir.c:301)
   hci_update_adv_data_sync (net/bluetooth/hci_sync.c:1310)
   hci_schedule_adv_instance_sync (net/bluetooth/hci_sync.c:1817)
   hci_cmd_sync_work (net/bluetooth/hci_sync.c:332)
  This frame has 1 object:
   [32, 64) &amp;#39;cp&amp;#39;&lt;/p&gt;
&lt;p&gt;The &amp;#34;Flags&amp;#34; structure is added by the kernel, not requested by
userspace, so only prepend it when it fits together with the instance
advertising data; when there is no room for both, drop the flags rather
than the user-provide…&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;Bluetooth: eir: Fix stack OOB write when prepending the Flags AD&lt;/p&gt;
&lt;p&gt;eir_create_adv_data() builds the advertising data into a fixed-size
buffer (&amp;#34;size&amp;#34;, 31 for the legacy path). It may prepend a 3-byte &amp;#34;Flags&amp;#34;
AD structure (LE_AD_NO_BREDR on an LE-only controller) and then copies
the per-instance data without checking that it still fits:&lt;/p&gt;
&lt;p&gt;memcpy(ptr, adv-&amp;gt;adv_data, adv-&amp;gt;adv_data_len);&lt;/p&gt;
&lt;p&gt;tlv_data_max_len() only reserves those 3 bytes when the user-supplied
flags carry a managed-flags bit, so an instance added with flags == 0 is
accepted with adv_data_len up to the full buffer. At advertise time the
flags are still prepended, and the memcpy() writes 3 + adv_data_len
bytes into the size-byte buffer:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir.c:301)
  Write of size 31 at addr ffff88800a547bdc by task kworker/u9:0/65
  Workqueue: hci0 hci_cmd_sync_work
   __asan_memcpy (mm/kasan/shadow.c:106)
   eir_create_adv_data (net/bluetooth/eir.c:301)
   hci_update_adv_data_sync (net/bluetooth/hci_sync.c:1310)
   hci_schedule_adv_instance_sync (net/bluetooth/hci_sync.c:1817)
   hci_cmd_sync_work (net/bluetooth/hci_sync.c:332)
  This frame has 1 object:
   [32, 64) &amp;#39;cp&amp;#39;&lt;/p&gt;
&lt;p&gt;The &amp;#34;Flags&amp;#34; structure is added by the kernel, not requested by
userspace, so only prepend it when it fits together with the instance
advertising data; when there is no room for both, drop the flags rather
than the user-provide…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-64539</guid>
    </item>
    <item>
      <title>GHSA-rxg5-jr9r-8pc7</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-rxg5-jr9r-8pc7</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;Bluetooth: eir: Fix stack OOB write when prepending the Flags AD&lt;/p&gt;
&lt;p&gt;eir_create_adv_data() builds the advertising data into a fixed-size
buffer (&amp;#34;size&amp;#34;, 31 for the legacy path). It may prepend a 3-byte &amp;#34;Flags&amp;#34;
AD structure (LE_AD_NO_BREDR on an LE-only controller) and then copies
the per-instance data without checking that it still fits:&lt;/p&gt;
&lt;p&gt;memcpy(ptr, adv-&amp;gt;adv_data, adv-&amp;gt;adv_data_len);&lt;/p&gt;
&lt;p&gt;tlv_data_max_len() only reserves those 3 bytes when the user-supplied
flags carry a managed-flags bit, so an instance added with flags == 0 is
accepted with adv_data_len up to the full buffer. At advertise time the
flags are still prepended, and the memcpy() writes 3 + adv_data_len
bytes into the size-byte buffer:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir.c:301)
  Write of size 31 at addr ffff88800a547bdc by task kworker/u9:0/65
  Workqueue: hci0 hci_cmd_sync_work
   __asan_memcpy (mm/kasan/shadow.c:106)
   eir_create_adv_data (net/bluetooth/eir.c:301)
   hci_update_adv_data_sync (net/bluetooth/hci_sync.c:1310)
   hci_schedule_adv_instance_sync (net/bluetooth/hci_sync.c:1817)
   hci_cmd_sync_work (net/bluetooth/hci_sync.c:332)
  This frame has 1 object:
   [32, 64) &amp;#39;cp&amp;#39;&lt;/p&gt;
&lt;p&gt;The &amp;#34;Flags&amp;#34; structure is added by the kernel, not requested by
userspace, so only prepend it when it fits together with the instance
advertising data; when there is no room for both, drop the flags rather
than the user-provide…&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;Bluetooth: eir: Fix stack OOB write when prepending the Flags AD&lt;/p&gt;
&lt;p&gt;eir_create_adv_data() builds the advertising data into a fixed-size
buffer (&amp;#34;size&amp;#34;, 31 for the legacy path). It may prepend a 3-byte &amp;#34;Flags&amp;#34;
AD structure (LE_AD_NO_BREDR on an LE-only controller) and then copies
the per-instance data without checking that it still fits:&lt;/p&gt;
&lt;p&gt;memcpy(ptr, adv-&amp;gt;adv_data, adv-&amp;gt;adv_data_len);&lt;/p&gt;
&lt;p&gt;tlv_data_max_len() only reserves those 3 bytes when the user-supplied
flags carry a managed-flags bit, so an instance added with flags == 0 is
accepted with adv_data_len up to the full buffer. At advertise time the
flags are still prepended, and the memcpy() writes 3 + adv_data_len
bytes into the size-byte buffer:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir.c:301)
  Write of size 31 at addr ffff88800a547bdc by task kworker/u9:0/65
  Workqueue: hci0 hci_cmd_sync_work
   __asan_memcpy (mm/kasan/shadow.c:106)
   eir_create_adv_data (net/bluetooth/eir.c:301)
   hci_update_adv_data_sync (net/bluetooth/hci_sync.c:1310)
   hci_schedule_adv_instance_sync (net/bluetooth/hci_sync.c:1817)
   hci_cmd_sync_work (net/bluetooth/hci_sync.c:332)
  This frame has 1 object:
   [32, 64) &amp;#39;cp&amp;#39;&lt;/p&gt;
&lt;p&gt;The &amp;#34;Flags&amp;#34; structure is added by the kernel, not requested by
userspace, so only prepend it when it fits together with the instance
advertising data; when there is no room for both, drop the flags rather
than the user-provide…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-rxg5-jr9r-8pc7</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-64539 — Bluetooth: eir: Fix stack OOB write when prepending the Flags AD</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-64539</link>
      <description>msrc_CVE-2026-64539</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-64539</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:11476-1 — kernel-devel-7.1.7-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:11476-1</link>
      <description>&lt;p&gt;kernel-devel-7.1.7-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-7.1.7-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:11476-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:23477-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:23477-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:23477-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-64539</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-64539</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 245 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: Bluetooth: eir: Fix stack OOB write when prepending the Flags AD eir_create_adv_data() builds the advertising data into a fixed-size buffer (&amp;#34;size&amp;#34;, 31 for the legacy path). It may prepend a 3-byte &amp;#34;Flags&amp;#34; AD structure (LE_AD_NO_BREDR on an LE-only controller) and then copies the per-instance data without checking that it still fits: 	memcpy(ptr, adv-&amp;gt;adv_data, adv-&amp;gt;adv_data_len); tlv_data_max_len() only reserves those 3 bytes when the user-supplied flags carry a managed-flags bit, so an instance added with flags == 0 is accepted with adv_data_len up to the full buffer. At advertise time the flags are still prepended, and the memcpy() writes 3 + adv_data_len bytes into the size-byte buffer:   BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir.c:301)   Write of size 31 at addr ffff88800a547bdc by task kworker/u9:0/65   Workqueue: hci0 hci_cmd_sync_work    __asan_memcpy (mm/kasan/shadow.c:106)    eir_create_adv_data (net/bluetooth/eir.c:301)    hci_update_adv_data_sync (net/bluetooth/hci_sync.c:1310)    hci_schedule_adv_instance_sync (net/bluetooth/hci_sync.c:1817)    hci_cmd_sync_work (net/bluetooth/hci_sync.c:332)   This frame has 1 object:    [32, 64) &amp;#39;cp&amp;#39; The &amp;#34;Flags&amp;#34; structure is added by the kernel, not requested by userspace, so only prepend it when it fits together with the instance advertising data; when there is no room for both, drop the flags rather than the user-provided data…&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 245 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: Bluetooth: eir: Fix stack OOB write when prepending the Flags AD eir_create_adv_data() builds the advertising data into a fixed-size buffer (&amp;#34;size&amp;#34;, 31 for the legacy path). It may prepend a 3-byte &amp;#34;Flags&amp;#34; AD structure (LE_AD_NO_BREDR on an LE-only controller) and then copies the per-instance data without checking that it still fits: 	memcpy(ptr, adv-&amp;gt;adv_data, adv-&amp;gt;adv_data_len); tlv_data_max_len() only reserves those 3 bytes when the user-supplied flags carry a managed-flags bit, so an instance added with flags == 0 is accepted with adv_data_len up to the full buffer. At advertise time the flags are still prepended, and the memcpy() writes 3 + adv_data_len bytes into the size-byte buffer:   BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir.c:301)   Write of size 31 at addr ffff88800a547bdc by task kworker/u9:0/65   Workqueue: hci0 hci_cmd_sync_work    __asan_memcpy (mm/kasan/shadow.c:106)    eir_create_adv_data (net/bluetooth/eir.c:301)    hci_update_adv_data_sync (net/bluetooth/hci_sync.c:1310)    hci_schedule_adv_instance_sync (net/bluetooth/hci_sync.c:1817)    hci_cmd_sync_work (net/bluetooth/hci_sync.c:332)   This frame has 1 object:    [32, 64) &amp;#39;cp&amp;#39; The &amp;#34;Flags&amp;#34; structure is added by the kernel, not requested by userspace, so only prepend it when it fits together with the instance advertising data; when there is no room for both, drop the flags rather than the user-provided data…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-64539</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2536 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2536</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um den Speicher zu beschädigen, vertrauliche Informationen offenzulegen, Daten zu manipulieren oder einen Denial-of-Service-Zustand zu verursachen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um den Speicher zu beschädigen, vertrauliche Informationen offenzulegen, Daten zu manipulieren oder einen Denial-of-Service-Zustand zu verursachen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2536</guid>
    </item>
  </channel>
</rss>
