<?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>Sat, 03 Oct 2026 10:31:41 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-68217</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-68217</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-68217</guid>
    </item>
    <item>
      <title>certfr-2026-avi-1069 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Elles permettent à un attaquant de p…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-1069</link>
      <description>certfr-2026-avi-1069</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-1069</guid>
    </item>
    <item>
      <title>EUVD-2026-356141</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-356141</link>
      <description>EUVD-2026-356141</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-356141</guid>
    </item>
    <item>
      <title>fkie_cve-2026-68217</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-68217</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: pwc: Drain fill_buf on start_streaming() failure&lt;/p&gt;
&lt;p&gt;pwc_isoc_init() submits its isochronous URBs with
usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is
submitted, its completion handler pwc_isoc_handler() can run on another
CPU before the loop finishes:&lt;/p&gt;
&lt;p&gt;start_streaming()
    pwc_isoc_init()
      usb_submit_urb(urbs[0], GFP_KERNEL)
                                  pwc_isoc_handler(urbs[0])
                                    pdev-&amp;gt;fill_buf =
                                      pwc_get_next_fill_buf(pdev)
      usb_submit_urb(urbs[i&amp;gt;0], ..)  -&amp;gt; fails
      pwc_isoc_cleanup(pdev)           /* kills URBs */
      return ret;
    pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED)&lt;/p&gt;
&lt;p&gt;pwc_get_next_fill_buf() detaches a buffer from pdev-&amp;gt;queued_bufs and
stores it in pdev-&amp;gt;fill_buf. The error path in start_streaming() only
drains pdev-&amp;gt;queued_bufs, so the buffer parked in pdev-&amp;gt;fill_buf is
leaked. vb2_start_streaming() then triggers
WARN_ON(owned_by_drv_count).&lt;/p&gt;
&lt;p&gt;stop_streaming() already handles this since commit 80b0963e1698
(&amp;#34;[media] pwc: fix WARN_ON&amp;#34;), which added the fill_buf drain in the
teardown path but not in the start_streaming() error path. Mirror that
handling on failure so start_streaming() returns with no buffer owned
by the driver.&lt;/p&gt;
&lt;p&gt;Issue identified by automated review of the INV-003 series at
https://sashiko.dev/&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: pwc: Drain fill_buf on start_streaming() failure&lt;/p&gt;
&lt;p&gt;pwc_isoc_init() submits its isochronous URBs with
usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is
submitted, its completion handler pwc_isoc_handler() can run on another
CPU before the loop finishes:&lt;/p&gt;
&lt;p&gt;start_streaming()
    pwc_isoc_init()
      usb_submit_urb(urbs[0], GFP_KERNEL)
                                  pwc_isoc_handler(urbs[0])
                                    pdev-&amp;gt;fill_buf =
                                      pwc_get_next_fill_buf(pdev)
      usb_submit_urb(urbs[i&amp;gt;0], ..)  -&amp;gt; fails
      pwc_isoc_cleanup(pdev)           /* kills URBs */
      return ret;
    pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED)&lt;/p&gt;
&lt;p&gt;pwc_get_next_fill_buf() detaches a buffer from pdev-&amp;gt;queued_bufs and
stores it in pdev-&amp;gt;fill_buf. The error path in start_streaming() only
drains pdev-&amp;gt;queued_bufs, so the buffer parked in pdev-&amp;gt;fill_buf is
leaked. vb2_start_streaming() then triggers
WARN_ON(owned_by_drv_count).&lt;/p&gt;
&lt;p&gt;stop_streaming() already handles this since commit 80b0963e1698
(&amp;#34;[media] pwc: fix WARN_ON&amp;#34;), which added the fill_buf drain in the
teardown path but not in the start_streaming() error path. Mirror that
handling on failure so start_streaming() returns with no buffer owned
by the driver.&lt;/p&gt;
&lt;p&gt;Issue identified by automated review of the INV-003 series at
https://sashiko.dev/&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-68217</guid>
    </item>
    <item>
      <title>GHSA-mj4m-5r47-3f8j</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-mj4m-5r47-3f8j</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: pwc: Drain fill_buf on start_streaming() failure&lt;/p&gt;
&lt;p&gt;pwc_isoc_init() submits its isochronous URBs with
usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is
submitted, its completion handler pwc_isoc_handler() can run on another
CPU before the loop finishes:&lt;/p&gt;
&lt;p&gt;start_streaming()
    pwc_isoc_init()
      usb_submit_urb(urbs[0], GFP_KERNEL)
                                  pwc_isoc_handler(urbs[0])
                                    pdev-&amp;gt;fill_buf =
                                      pwc_get_next_fill_buf(pdev)
      usb_submit_urb(urbs[i&amp;gt;0], ..)  -&amp;gt; fails
      pwc_isoc_cleanup(pdev)           /* kills URBs */
      return ret;
    pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED)&lt;/p&gt;
&lt;p&gt;pwc_get_next_fill_buf() detaches a buffer from pdev-&amp;gt;queued_bufs and
stores it in pdev-&amp;gt;fill_buf. The error path in start_streaming() only
drains pdev-&amp;gt;queued_bufs, so the buffer parked in pdev-&amp;gt;fill_buf is
leaked. vb2_start_streaming() then triggers
WARN_ON(owned_by_drv_count).&lt;/p&gt;
&lt;p&gt;stop_streaming() already handles this since commit 80b0963e1698
(&amp;#34;[media] pwc: fix WARN_ON&amp;#34;), which added the fill_buf drain in the
teardown path but not in the start_streaming() error path. Mirror that
handling on failure so start_streaming() returns with no buffer owned
by the driver.&lt;/p&gt;
&lt;p&gt;Issue identified by automated review of the INV-003 series at
https://sashiko.dev/&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: pwc: Drain fill_buf on start_streaming() failure&lt;/p&gt;
&lt;p&gt;pwc_isoc_init() submits its isochronous URBs with
usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is
submitted, its completion handler pwc_isoc_handler() can run on another
CPU before the loop finishes:&lt;/p&gt;
&lt;p&gt;start_streaming()
    pwc_isoc_init()
      usb_submit_urb(urbs[0], GFP_KERNEL)
                                  pwc_isoc_handler(urbs[0])
                                    pdev-&amp;gt;fill_buf =
                                      pwc_get_next_fill_buf(pdev)
      usb_submit_urb(urbs[i&amp;gt;0], ..)  -&amp;gt; fails
      pwc_isoc_cleanup(pdev)           /* kills URBs */
      return ret;
    pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED)&lt;/p&gt;
&lt;p&gt;pwc_get_next_fill_buf() detaches a buffer from pdev-&amp;gt;queued_bufs and
stores it in pdev-&amp;gt;fill_buf. The error path in start_streaming() only
drains pdev-&amp;gt;queued_bufs, so the buffer parked in pdev-&amp;gt;fill_buf is
leaked. vb2_start_streaming() then triggers
WARN_ON(owned_by_drv_count).&lt;/p&gt;
&lt;p&gt;stop_streaming() already handles this since commit 80b0963e1698
(&amp;#34;[media] pwc: fix WARN_ON&amp;#34;), which added the fill_buf drain in the
teardown path but not in the start_streaming() error path. Mirror that
handling on failure so start_streaming() returns with no buffer owned
by the driver.&lt;/p&gt;
&lt;p&gt;Issue identified by automated review of the INV-003 series at
https://sashiko.dev/&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-mj4m-5r47-3f8j</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-68217 — media: pwc: Drain fill_buf on start_streaming() failure</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-68217</link>
      <description>msrc_CVE-2026-68217</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-68217</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:21910-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:21910-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/opensuse-su-2026:21910-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-68217</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-68217</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, 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 and 246 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes:   start_streaming()     pwc_isoc_init()       usb_submit_urb(urbs[0], GFP_KERNEL)                                   pwc_isoc_handler(urbs[0])                                     pdev-&amp;gt;fill_buf =                                       pwc_get_next_fill_buf(pdev)       usb_submit_urb(urbs[i&amp;gt;0], ..)  -&amp;gt; fails       pwc_isoc_cleanup(pdev)           /* kills URBs */       return ret;     pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev-&amp;gt;queued_bufs and stores it in pdev-&amp;gt;fill_buf. The error path in start_streaming() only drains pdev-&amp;gt;queued_bufs, so the buffer parked in pdev-&amp;gt;fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (&amp;#34;[media] pwc: fix WARN_ON&amp;#34;), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, 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 and 246 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes:   start_streaming()     pwc_isoc_init()       usb_submit_urb(urbs[0], GFP_KERNEL)                                   pwc_isoc_handler(urbs[0])                                     pdev-&amp;gt;fill_buf =                                       pwc_get_next_fill_buf(pdev)       usb_submit_urb(urbs[i&amp;gt;0], ..)  -&amp;gt; fails       pwc_isoc_cleanup(pdev)           /* kills URBs */       return ret;     pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev-&amp;gt;queued_bufs and stores it in pdev-&amp;gt;fill_buf. The error path in start_streaming() only drains pdev-&amp;gt;queued_bufs, so the buffer parked in pdev-&amp;gt;fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (&amp;#34;[media] pwc: fix WARN_ON&amp;#34;), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-68217</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2730 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2730</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, darunter möglicherweise die Ausführung von beliebigem Code, die Ausweitung von Berechtigungen, die Offenlegung von Informationen, die Manipulation von Daten oder Denial-of-Service-Zustände.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, darunter möglicherweise die Ausführung von beliebigem Code, die Ausweitung von Berechtigungen, die Offenlegung von Informationen, die Manipulation von Daten oder Denial-of-Service-Zustände.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2730</guid>
    </item>
  </channel>
</rss>
