<?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>Wed, 14 Oct 2026 20:05:58 +0000</lastBuildDate>
    <item>
      <title>CVE-2024-35970 — af_unix: Clear stale u-&gt;oob_skb.</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2024-35970</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;af_unix: Clear stale u-&amp;gt;oob_skb.&lt;/p&gt;
&lt;p&gt;syzkaller started to report deadlock of unix_gc_lock after commit
4090fa373f0e (&amp;#34;af_unix: Replace garbage collection algorithm.&amp;#34;), but
it just uncovers the bug that has been there since commit 314001f0bf92
(&amp;#34;af_unix: Add OOB support&amp;#34;).&lt;/p&gt;
&lt;p&gt;The repro basically does the following.&lt;/p&gt;
&lt;p&gt;from socket import *
  from array import array&lt;/p&gt;
&lt;p&gt;c1, c2 = socketpair(AF_UNIX, SOCK_STREAM)
  c1.sendmsg([b&amp;#39;a&amp;#39;], [(SOL_SOCKET, SCM_RIGHTS, array(&amp;#34;i&amp;#34;, [c2.fileno()]))], MSG_OOB)
  c2.recv(1)  # blocked as no normal data in recv queue&lt;/p&gt;
&lt;p&gt;c2.close()  # done async and unblock recv()
  c1.close()  # done async and trigger GC&lt;/p&gt;
&lt;p&gt;A socket sends its file descriptor to itself as OOB data and tries to
receive normal data, but finally recv() fails due to async close().&lt;/p&gt;
&lt;p&gt;The problem here is wrong handling of OOB skb in manage_oob().  When
recvmsg() is called without MSG_OOB, manage_oob() is called to check
if the peeked skb is OOB skb.  In such a case, manage_oob() pops it
out of the receive queue but does not clear unix_sock(sk)-&amp;gt;oob_skb.
This is wrong in terms of uAPI.&lt;/p&gt;
&lt;p&gt;Let&amp;#39;s say we send &amp;#34;hello&amp;#34; with MSG_OOB, and &amp;#34;world&amp;#34; without MSG_OOB.
The &amp;#39;o&amp;#39; is handled as OOB data.  When recv() is called twice without
MSG_OOB, the OOB data should be lost.&lt;/p&gt;
&lt;p&gt;&amp;gt;&amp;gt;&amp;gt; from socket import *
  &amp;gt;&amp;gt;&amp;gt; c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0)
  &amp;gt;&amp;gt;&amp;gt; c1.send(b&amp;#39;hello&amp;#39;, MSG_OOB)  # &amp;#39;o&amp;#39; is OOB data
  5
  &amp;gt;&amp;gt;&amp;gt; c1.send(b&amp;#39;world&amp;#39;)
  5
  &amp;gt;&amp;gt;&amp;gt; c2…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;af_unix: Clear stale u-&amp;gt;oob_skb.&lt;/p&gt;
&lt;p&gt;syzkaller started to report deadlock of unix_gc_lock after commit
4090fa373f0e (&amp;#34;af_unix: Replace garbage collection algorithm.&amp;#34;), but
it just uncovers the bug that has been there since commit 314001f0bf92
(&amp;#34;af_unix: Add OOB support&amp;#34;).&lt;/p&gt;
&lt;p&gt;The repro basically does the following.&lt;/p&gt;
&lt;p&gt;from socket import *
  from array import array&lt;/p&gt;
&lt;p&gt;c1, c2 = socketpair(AF_UNIX, SOCK_STREAM)
  c1.sendmsg([b&amp;#39;a&amp;#39;], [(SOL_SOCKET, SCM_RIGHTS, array(&amp;#34;i&amp;#34;, [c2.fileno()]))], MSG_OOB)
  c2.recv(1)  # blocked as no normal data in recv queue&lt;/p&gt;
&lt;p&gt;c2.close()  # done async and unblock recv()
  c1.close()  # done async and trigger GC&lt;/p&gt;
&lt;p&gt;A socket sends its file descriptor to itself as OOB data and tries to
receive normal data, but finally recv() fails due to async close().&lt;/p&gt;
&lt;p&gt;The problem here is wrong handling of OOB skb in manage_oob().  When
recvmsg() is called without MSG_OOB, manage_oob() is called to check
if the peeked skb is OOB skb.  In such a case, manage_oob() pops it
out of the receive queue but does not clear unix_sock(sk)-&amp;gt;oob_skb.
This is wrong in terms of uAPI.&lt;/p&gt;
&lt;p&gt;Let&amp;#39;s say we send &amp;#34;hello&amp;#34; with MSG_OOB, and &amp;#34;world&amp;#34; without MSG_OOB.
The &amp;#39;o&amp;#39; is handled as OOB data.  When recv() is called twice without
MSG_OOB, the OOB data should be lost.&lt;/p&gt;
&lt;p&gt;&amp;gt;&amp;gt;&amp;gt; from socket import *
  &amp;gt;&amp;gt;&amp;gt; c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0)
  &amp;gt;&amp;gt;&amp;gt; c1.send(b&amp;#39;hello&amp;#39;, MSG_OOB)  # &amp;#39;o&amp;#39; is OOB data
  5
  &amp;gt;&amp;gt;&amp;gt; c1.send(b&amp;#39;world&amp;#39;)
  5
  &amp;gt;&amp;gt;&amp;gt; c2…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2024-35970</guid>
    </item>
    <item>
      <title>USN-6893-1 — linux, linux-azure, linux-gcp, linux-ibm, linux-intel, linux-lowlatency, linux-oem-6.8, linux-raspi vulnerabilities</title>
      <link>https://cve.radiocsirt.org/vuln/usn-6893-1</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:24.04:LTS: linux, Ubuntu:24.04:LTS: linux-azure, Ubuntu:24.04:LTS: linux-gcp, Ubuntu:24.04:LTS: linux-ibm, Ubuntu:24.04:LTS: linux-intel, Ubuntu:24.04:LTS: linux-lowlatency, Ubuntu:24.04:LTS: linux-oem-6.8, Ubuntu:24.04:LTS: linux-raspi&lt;/p&gt;
&lt;p&gt;It was discovered that a race condition existed in the Bluetooth subsystem
in the Linux kernel when modifying certain settings values through debugfs.
A privileged local attacker could use this to cause a denial of service.
(CVE-2024-24857, CVE-2024-24858, CVE-2024-24859)&lt;/p&gt;
&lt;p&gt;Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
  - ARM64 architecture;
  - RISC-V architecture;
  - S390 architecture;
  - x86 architecture;
  - Block layer subsystem;
  - Compute Acceleration Framework;
  - Accessibility subsystem;
  - Android drivers;
  - Drivers core;
  - Bluetooth drivers;
  - Clock framework and drivers;
  - Data acquisition framework and drivers;
  - Cryptographic API;
  - Buffer Sharing and Synchronization framework;
  - GPU drivers;
  - On-Chip Interconnect management framework;
  - IOMMU subsystem;
  - Multiple devices driver;
  - Media drivers;
  - VMware VMCI Driver;
  - Network drivers;
  - Microsoft Azure Network Adapter (MANA) driver;
  - Device tree and open firmware driver;
  - Chrome hardware platform drivers;
  - i.MX PM domains;
  - TI SCI PM domains driver;
  - S/390 drivers;
  - SCSI drivers;
  - SPI subsystem;
  - Thermal drivers;
  - TTY drivers;
  - USB subsystem;
  - Framebuffer layer;
  - BTRFS file system;
  - Network file system server daemon;
  - NILFS2 file system;
  - File systems infrastructure;
  - Pstore file system;
  - SMB…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:24.04:LTS: linux, Ubuntu:24.04:LTS: linux-azure, Ubuntu:24.04:LTS: linux-gcp, Ubuntu:24.04:LTS: linux-ibm, Ubuntu:24.04:LTS: linux-intel, Ubuntu:24.04:LTS: linux-lowlatency, Ubuntu:24.04:LTS: linux-oem-6.8, Ubuntu:24.04:LTS: linux-raspi&lt;/p&gt;
&lt;p&gt;It was discovered that a race condition existed in the Bluetooth subsystem
in the Linux kernel when modifying certain settings values through debugfs.
A privileged local attacker could use this to cause a denial of service.
(CVE-2024-24857, CVE-2024-24858, CVE-2024-24859)&lt;/p&gt;
&lt;p&gt;Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
  - ARM64 architecture;
  - RISC-V architecture;
  - S390 architecture;
  - x86 architecture;
  - Block layer subsystem;
  - Compute Acceleration Framework;
  - Accessibility subsystem;
  - Android drivers;
  - Drivers core;
  - Bluetooth drivers;
  - Clock framework and drivers;
  - Data acquisition framework and drivers;
  - Cryptographic API;
  - Buffer Sharing and Synchronization framework;
  - GPU drivers;
  - On-Chip Interconnect management framework;
  - IOMMU subsystem;
  - Multiple devices driver;
  - Media drivers;
  - VMware VMCI Driver;
  - Network drivers;
  - Microsoft Azure Network Adapter (MANA) driver;
  - Device tree and open firmware driver;
  - Chrome hardware platform drivers;
  - i.MX PM domains;
  - TI SCI PM domains driver;
  - S/390 drivers;
  - SCSI drivers;
  - SPI subsystem;
  - Thermal drivers;
  - TTY drivers;
  - USB subsystem;
  - Framebuffer layer;
  - BTRFS file system;
  - Network file system server daemon;
  - NILFS2 file system;
  - File systems infrastructure;
  - Pstore file system;
  - SMB…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/usn-6893-1</guid>
    </item>
  </channel>
</rss>
