<?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 11:54:29 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-12575</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-12575</link>
      <description>bdu:2026-12575</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-12575</guid>
    </item>
    <item>
      <title>BELL-CVE-2026-31585</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-31585</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-31585</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0526 — De multiples vulnérabilités ont été découvertes dans les produits Microsoft. Elles permettent à un attaquant de provoqu…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0526</link>
      <description>certfr-2026-avi-0526</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0526</guid>
    </item>
    <item>
      <title>EUVD-2026-327016</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-327016</link>
      <description>EUVD-2026-327016</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-327016</guid>
    </item>
    <item>
      <title>fkie_cve-2026-31585</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-31585</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: vidtv: fix nfeeds state corruption on start_streaming failure&lt;/p&gt;
&lt;p&gt;syzbot reported a memory leak in vidtv_psi_service_desc_init [1].&lt;/p&gt;
&lt;p&gt;When vidtv_start_streaming() fails inside vidtv_start_feed(), the
nfeeds counter is left incremented even though no feed was actually
started. This corrupts the driver state: subsequent start_feed calls
see nfeeds &amp;gt; 1 and skip starting the mux, while stop_feed calls
eventually try to stop a non-existent stream.&lt;/p&gt;
&lt;p&gt;This state corruption can also lead to memory leaks, since the mux
and channel resources may be partially allocated during a failed
start_streaming but never cleaned up, as the stop path finds
dvb-&amp;gt;streaming == false and returns early.&lt;/p&gt;
&lt;p&gt;Fix by decrementing nfeeds back when start_streaming fails, keeping
the counter in sync with the actual number of active feeds.&lt;/p&gt;
&lt;p&gt;[1]
BUG: memory leak
unreferenced object 0xffff888145b50820 (size 32):
 comm &amp;#34;syz.0.17&amp;#34;, pid 6068, jiffies 4294944486
 backtrace (crc 90a0c7d4):
  vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c:288
  vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83
  vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524
  vidtv_mux_init+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:518
  vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline]
  vidtv_start_feed+0x33e/0x4d0 drivers/m…&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: vidtv: fix nfeeds state corruption on start_streaming failure&lt;/p&gt;
&lt;p&gt;syzbot reported a memory leak in vidtv_psi_service_desc_init [1].&lt;/p&gt;
&lt;p&gt;When vidtv_start_streaming() fails inside vidtv_start_feed(), the
nfeeds counter is left incremented even though no feed was actually
started. This corrupts the driver state: subsequent start_feed calls
see nfeeds &amp;gt; 1 and skip starting the mux, while stop_feed calls
eventually try to stop a non-existent stream.&lt;/p&gt;
&lt;p&gt;This state corruption can also lead to memory leaks, since the mux
and channel resources may be partially allocated during a failed
start_streaming but never cleaned up, as the stop path finds
dvb-&amp;gt;streaming == false and returns early.&lt;/p&gt;
&lt;p&gt;Fix by decrementing nfeeds back when start_streaming fails, keeping
the counter in sync with the actual number of active feeds.&lt;/p&gt;
&lt;p&gt;[1]
BUG: memory leak
unreferenced object 0xffff888145b50820 (size 32):
 comm &amp;#34;syz.0.17&amp;#34;, pid 6068, jiffies 4294944486
 backtrace (crc 90a0c7d4):
  vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c:288
  vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83
  vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524
  vidtv_mux_init+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:518
  vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline]
  vidtv_start_feed+0x33e/0x4d0 drivers/m…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-31585</guid>
    </item>
    <item>
      <title>GHSA-vmqh-6ghr-6c6p</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-vmqh-6ghr-6c6p</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: vidtv: fix nfeeds state corruption on start_streaming failure&lt;/p&gt;
&lt;p&gt;syzbot reported a memory leak in vidtv_psi_service_desc_init [1].&lt;/p&gt;
&lt;p&gt;When vidtv_start_streaming() fails inside vidtv_start_feed(), the
nfeeds counter is left incremented even though no feed was actually
started. This corrupts the driver state: subsequent start_feed calls
see nfeeds &amp;gt; 1 and skip starting the mux, while stop_feed calls
eventually try to stop a non-existent stream.&lt;/p&gt;
&lt;p&gt;This state corruption can also lead to memory leaks, since the mux
and channel resources may be partially allocated during a failed
start_streaming but never cleaned up, as the stop path finds
dvb-&amp;gt;streaming == false and returns early.&lt;/p&gt;
&lt;p&gt;Fix by decrementing nfeeds back when start_streaming fails, keeping
the counter in sync with the actual number of active feeds.&lt;/p&gt;
&lt;p&gt;[1]
BUG: memory leak
unreferenced object 0xffff888145b50820 (size 32):
 comm &amp;#34;syz.0.17&amp;#34;, pid 6068, jiffies 4294944486
 backtrace (crc 90a0c7d4):
  vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c:288
  vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83
  vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524
  vidtv_mux_init+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:518
  vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline]
  vidtv_start_feed+0x33e/0x4d0 drivers/m…&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: vidtv: fix nfeeds state corruption on start_streaming failure&lt;/p&gt;
&lt;p&gt;syzbot reported a memory leak in vidtv_psi_service_desc_init [1].&lt;/p&gt;
&lt;p&gt;When vidtv_start_streaming() fails inside vidtv_start_feed(), the
nfeeds counter is left incremented even though no feed was actually
started. This corrupts the driver state: subsequent start_feed calls
see nfeeds &amp;gt; 1 and skip starting the mux, while stop_feed calls
eventually try to stop a non-existent stream.&lt;/p&gt;
&lt;p&gt;This state corruption can also lead to memory leaks, since the mux
and channel resources may be partially allocated during a failed
start_streaming but never cleaned up, as the stop path finds
dvb-&amp;gt;streaming == false and returns early.&lt;/p&gt;
&lt;p&gt;Fix by decrementing nfeeds back when start_streaming fails, keeping
the counter in sync with the actual number of active feeds.&lt;/p&gt;
&lt;p&gt;[1]
BUG: memory leak
unreferenced object 0xffff888145b50820 (size 32):
 comm &amp;#34;syz.0.17&amp;#34;, pid 6068, jiffies 4294944486
 backtrace (crc 90a0c7d4):
  vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c:288
  vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83
  vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524
  vidtv_mux_init+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:518
  vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline]
  vidtv_start_feed+0x33e/0x4d0 drivers/m…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-vmqh-6ghr-6c6p</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-31585 — media: vidtv: fix nfeeds state corruption on start_streaming failure</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-31585</link>
      <description>msrc_CVE-2026-31585</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-31585</guid>
    </item>
    <item>
      <title>OESA-2026-2754 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-2754</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;fbdev: fix potential buffer overflow in do_register_framebuffer()&lt;/p&gt;
&lt;p&gt;The current implementation may lead to buffer overflow when:
1.  Unregistration creates NULL gaps in registered_fb[]
2.  All array slots become occupied despite num_registered_fb &amp;amp;lt; FB_MAX
3.  The registration loop exceeds array bounds&lt;/p&gt;
&lt;p&gt;Add boundary check to prevent registered_fb[FB_MAX] access.(CVE-2025-38702)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;hfs: validate record offset in hfsplus_bmap_alloc&lt;/p&gt;
&lt;p&gt;hfsplus_bmap_alloc can trigger a crash if a
record offset or length is larger than node_size&lt;/p&gt;
&lt;p&gt;[   15.264282] BUG: KASAN: slab-out-of-bounds in hfsplus_bmap_alloc+0x887/0x8b0
[   15.265192] Read of size 8 at addr ffff8881085ca188 by task test/183
[   15.265949]
[   15.266163] CPU: 0 UID: 0 PID: 183 Comm: test Not tainted 6.17.0-rc2-gc17b750b3ad9 #14 PREEMPT(voluntary)
[   15.266165] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[   15.266167] Call Trace:
[   15.266168]  &amp;amp;lt;TASK&amp;amp;gt;
[   15.266169]  dump_stack_lvl+0x53/0x70
[   15.266173]  print_report+0xd0/0x660
[   15.266181]  kasan_report+0xce/0x100
[   15.266185]  hfsplus_bmap_alloc+0x887/0x8b0
[   15.266208]  hfs_btree_inc_height.isra.0+0xd5/0x7c0
[   15.266217]  hfsplus_brec_insert+0x870/0xb00
[   15.266222]  __hfsplus_ext_write_extent+…&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;fbdev: fix potential buffer overflow in do_register_framebuffer()&lt;/p&gt;
&lt;p&gt;The current implementation may lead to buffer overflow when:
1.  Unregistration creates NULL gaps in registered_fb[]
2.  All array slots become occupied despite num_registered_fb &amp;amp;lt; FB_MAX
3.  The registration loop exceeds array bounds&lt;/p&gt;
&lt;p&gt;Add boundary check to prevent registered_fb[FB_MAX] access.(CVE-2025-38702)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;hfs: validate record offset in hfsplus_bmap_alloc&lt;/p&gt;
&lt;p&gt;hfsplus_bmap_alloc can trigger a crash if a
record offset or length is larger than node_size&lt;/p&gt;
&lt;p&gt;[   15.264282] BUG: KASAN: slab-out-of-bounds in hfsplus_bmap_alloc+0x887/0x8b0
[   15.265192] Read of size 8 at addr ffff8881085ca188 by task test/183
[   15.265949]
[   15.266163] CPU: 0 UID: 0 PID: 183 Comm: test Not tainted 6.17.0-rc2-gc17b750b3ad9 #14 PREEMPT(voluntary)
[   15.266165] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[   15.266167] Call Trace:
[   15.266168]  &amp;amp;lt;TASK&amp;amp;gt;
[   15.266169]  dump_stack_lvl+0x53/0x70
[   15.266173]  print_report+0xd0/0x660
[   15.266181]  kasan_report+0xce/0x100
[   15.266185]  hfsplus_bmap_alloc+0x887/0x8b0
[   15.266208]  hfs_btree_inc_height.isra.0+0xd5/0x7c0
[   15.266217]  hfsplus_brec_insert+0x870/0xb00
[   15.266222]  __hfsplus_ext_write_extent+…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-2754</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-31585</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31585</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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 191 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix nfeeds state corruption on start_streaming failure syzbot reported a memory leak in vidtv_psi_service_desc_init [1]. When vidtv_start_streaming() fails inside vidtv_start_feed(), the nfeeds counter is left incremented even though no feed was actually started. This corrupts the driver state: subsequent start_feed calls see nfeeds &amp;gt; 1 and skip starting the mux, while stop_feed calls eventually try to stop a non-existent stream. This state corruption can also lead to memory leaks, since the mux and channel resources may be partially allocated during a failed start_streaming but never cleaned up, as the stop path finds dvb-&amp;gt;streaming == false and returns early. Fix by decrementing nfeeds back when start_streaming fails, keeping the counter in sync with the actual number of active feeds. [1] BUG: memory leak unreferenced object 0xffff888145b50820 (size 32):  comm &amp;#34;syz.0.17&amp;#34;, pid 6068, jiffies 4294944486  backtrace (crc 90a0c7d4):   vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c:288   vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83   vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524   vidtv_mux_init+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:518   vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline]   vidtv_start_feed+0x33e/0x4d0 drivers/media/t…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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 191 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix nfeeds state corruption on start_streaming failure syzbot reported a memory leak in vidtv_psi_service_desc_init [1]. When vidtv_start_streaming() fails inside vidtv_start_feed(), the nfeeds counter is left incremented even though no feed was actually started. This corrupts the driver state: subsequent start_feed calls see nfeeds &amp;gt; 1 and skip starting the mux, while stop_feed calls eventually try to stop a non-existent stream. This state corruption can also lead to memory leaks, since the mux and channel resources may be partially allocated during a failed start_streaming but never cleaned up, as the stop path finds dvb-&amp;gt;streaming == false and returns early. Fix by decrementing nfeeds back when start_streaming fails, keeping the counter in sync with the actual number of active feeds. [1] BUG: memory leak unreferenced object 0xffff888145b50820 (size 32):  comm &amp;#34;syz.0.17&amp;#34;, pid 6068, jiffies 4294944486  backtrace (crc 90a0c7d4):   vidtv_psi_service_desc_init+0x74/0x1b0 drivers/media/test-drivers/vidtv/vidtv_psi.c:288   vidtv_channel_s302m_init+0xb1/0x2a0 drivers/media/test-drivers/vidtv/vidtv_channel.c:83   vidtv_channels_init+0x1b/0x40 drivers/media/test-drivers/vidtv/vidtv_channel.c:524   vidtv_mux_init+0x516/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:518   vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 [inline]   vidtv_start_feed+0x33e/0x4d0 drivers/media/t…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31585</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>
