<?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 06:11:12 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-46041</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-46041</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-46041</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0831 — De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un a…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0831</link>
      <description>certfr-2026-avi-0831</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0831</guid>
    </item>
    <item>
      <title>EUVD-2026-327094</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-327094</link>
      <description>EUVD-2026-327094</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-327094</guid>
    </item>
    <item>
      <title>fkie_cve-2026-46041</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-46041</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;greybus: gb-beagleplay: fix sleep in atomic context in hdlc_tx_frames()&lt;/p&gt;
&lt;p&gt;hdlc_append() calls usleep_range() to wait for circular buffer space,
but it is called with tx_producer_lock (a spinlock) held via
hdlc_tx_frames() -&amp;gt; hdlc_append_tx_frame()/hdlc_append_tx_u8()/etc.
Sleeping while holding a spinlock is illegal and can trigger
&amp;#34;BUG: scheduling while atomic&amp;#34;.&lt;/p&gt;
&lt;p&gt;Fix this by moving the buffer-space wait out of hdlc_append() and into
hdlc_tx_frames(), before the spinlock is acquired.  The new flow:&lt;/p&gt;
&lt;p&gt;1. Pre-calculate the worst-case encoded frame length.
 2. Wait (with sleep) outside the lock until enough space is available,
    kicking the TX consumer work to drain the buffer.
 3. Acquire the spinlock, re-verify space, and write the entire frame
    atomically.&lt;/p&gt;
&lt;p&gt;This ensures that sleeping only happens without any lock held, and
that frames are either fully enqueued or not written at all.&lt;/p&gt;
&lt;p&gt;This bug is found by CodeQL static analysis tool (interprocedural
sleep-in-atomic query) and my code review.&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;greybus: gb-beagleplay: fix sleep in atomic context in hdlc_tx_frames()&lt;/p&gt;
&lt;p&gt;hdlc_append() calls usleep_range() to wait for circular buffer space,
but it is called with tx_producer_lock (a spinlock) held via
hdlc_tx_frames() -&amp;gt; hdlc_append_tx_frame()/hdlc_append_tx_u8()/etc.
Sleeping while holding a spinlock is illegal and can trigger
&amp;#34;BUG: scheduling while atomic&amp;#34;.&lt;/p&gt;
&lt;p&gt;Fix this by moving the buffer-space wait out of hdlc_append() and into
hdlc_tx_frames(), before the spinlock is acquired.  The new flow:&lt;/p&gt;
&lt;p&gt;1. Pre-calculate the worst-case encoded frame length.
 2. Wait (with sleep) outside the lock until enough space is available,
    kicking the TX consumer work to drain the buffer.
 3. Acquire the spinlock, re-verify space, and write the entire frame
    atomically.&lt;/p&gt;
&lt;p&gt;This ensures that sleeping only happens without any lock held, and
that frames are either fully enqueued or not written at all.&lt;/p&gt;
&lt;p&gt;This bug is found by CodeQL static analysis tool (interprocedural
sleep-in-atomic query) and my code review.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-46041</guid>
    </item>
    <item>
      <title>GHSA-f857-h46c-q655</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-f857-h46c-q655</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;greybus: gb-beagleplay: fix sleep in atomic context in hdlc_tx_frames()&lt;/p&gt;
&lt;p&gt;hdlc_append() calls usleep_range() to wait for circular buffer space,
but it is called with tx_producer_lock (a spinlock) held via
hdlc_tx_frames() -&amp;gt; hdlc_append_tx_frame()/hdlc_append_tx_u8()/etc.
Sleeping while holding a spinlock is illegal and can trigger
&amp;#34;BUG: scheduling while atomic&amp;#34;.&lt;/p&gt;
&lt;p&gt;Fix this by moving the buffer-space wait out of hdlc_append() and into
hdlc_tx_frames(), before the spinlock is acquired.  The new flow:&lt;/p&gt;
&lt;p&gt;1. Pre-calculate the worst-case encoded frame length.
 2. Wait (with sleep) outside the lock until enough space is available,
    kicking the TX consumer work to drain the buffer.
 3. Acquire the spinlock, re-verify space, and write the entire frame
    atomically.&lt;/p&gt;
&lt;p&gt;This ensures that sleeping only happens without any lock held, and
that frames are either fully enqueued or not written at all.&lt;/p&gt;
&lt;p&gt;This bug is found by CodeQL static analysis tool (interprocedural
sleep-in-atomic query) and my code review.&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;greybus: gb-beagleplay: fix sleep in atomic context in hdlc_tx_frames()&lt;/p&gt;
&lt;p&gt;hdlc_append() calls usleep_range() to wait for circular buffer space,
but it is called with tx_producer_lock (a spinlock) held via
hdlc_tx_frames() -&amp;gt; hdlc_append_tx_frame()/hdlc_append_tx_u8()/etc.
Sleeping while holding a spinlock is illegal and can trigger
&amp;#34;BUG: scheduling while atomic&amp;#34;.&lt;/p&gt;
&lt;p&gt;Fix this by moving the buffer-space wait out of hdlc_append() and into
hdlc_tx_frames(), before the spinlock is acquired.  The new flow:&lt;/p&gt;
&lt;p&gt;1. Pre-calculate the worst-case encoded frame length.
 2. Wait (with sleep) outside the lock until enough space is available,
    kicking the TX consumer work to drain the buffer.
 3. Acquire the spinlock, re-verify space, and write the entire frame
    atomically.&lt;/p&gt;
&lt;p&gt;This ensures that sleeping only happens without any lock held, and
that frames are either fully enqueued or not written at all.&lt;/p&gt;
&lt;p&gt;This bug is found by CodeQL static analysis tool (interprocedural
sleep-in-atomic query) and my code review.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-f857-h46c-q655</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:10954-1 — kernel-devel-7.0.11-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:10954-1</link>
      <description>&lt;p&gt;kernel-devel-7.0.11-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-7.0.11-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:10954-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-46041</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-46041</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 153 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: greybus: gb-beagleplay: fix sleep in atomic context in hdlc_tx_frames() hdlc_append() calls usleep_range() to wait for circular buffer space, but it is called with tx_producer_lock (a spinlock) held via hdlc_tx_frames() -&amp;gt; hdlc_append_tx_frame()/hdlc_append_tx_u8()/etc. Sleeping while holding a spinlock is illegal and can trigger &amp;#34;BUG: scheduling while atomic&amp;#34;. Fix this by moving the buffer-space wait out of hdlc_append() and into hdlc_tx_frames(), before the spinlock is acquired.  The new flow:  1. Pre-calculate the worst-case encoded frame length.  2. Wait (with sleep) outside the lock until enough space is available,     kicking the TX consumer work to drain the buffer.  3. Acquire the spinlock, re-verify space, and write the entire frame     atomically. This ensures that sleeping only happens without any lock held, and that frames are either fully enqueued or not written at all. This bug is found by CodeQL static analysis tool (interprocedural sleep-in-atomic query) and my code review.&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 153 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: greybus: gb-beagleplay: fix sleep in atomic context in hdlc_tx_frames() hdlc_append() calls usleep_range() to wait for circular buffer space, but it is called with tx_producer_lock (a spinlock) held via hdlc_tx_frames() -&amp;gt; hdlc_append_tx_frame()/hdlc_append_tx_u8()/etc. Sleeping while holding a spinlock is illegal and can trigger &amp;#34;BUG: scheduling while atomic&amp;#34;. Fix this by moving the buffer-space wait out of hdlc_append() and into hdlc_tx_frames(), before the spinlock is acquired.  The new flow:  1. Pre-calculate the worst-case encoded frame length.  2. Wait (with sleep) outside the lock until enough space is available,     kicking the TX consumer work to drain the buffer.  3. Acquire the spinlock, re-verify space, and write the entire frame     atomically. This ensures that sleeping only happens without any lock held, and that frames are either fully enqueued or not written at all. This bug is found by CodeQL static analysis tool (interprocedural sleep-in-atomic query) and my code review.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-46041</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1700 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1700</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht näher spezifizierte Auswirkungen zu erzielen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht näher spezifizierte Auswirkungen zu erzielen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1700</guid>
    </item>
  </channel>
</rss>
