<?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 07:22:19 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-31706</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-31706</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-31706</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-347771</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-347771</link>
      <description>EUVD-2026-347771</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-347771</guid>
    </item>
    <item>
      <title>fkie_cve-2026-31706</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-31706</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ksmbd: validate num_aces and harden ACE walk in smb_inherit_dacl()&lt;/p&gt;
&lt;p&gt;smb_inherit_dacl() trusts the on-disk num_aces value from the parent
directory&amp;#39;s DACL xattr and uses it to size a heap allocation:&lt;/p&gt;
&lt;p&gt;aces_base = kmalloc(sizeof(struct smb_ace) * num_aces * 2, ...);&lt;/p&gt;
&lt;p&gt;num_aces is a u16 read from le16_to_cpu(parent_pdacl-&amp;gt;num_aces)
without checking that it is consistent with the declared pdacl_size.
An authenticated client whose parent directory&amp;#39;s security.NTACL is
tampered (e.g. via offline xattr corruption or a concurrent path that
bypasses parse_dacl()) can present num_aces = 65535 with minimal
actual ACE data.  This causes a ~8 MB allocation (not kzalloc, so
uninitialized) that the subsequent loop only partially populates, and
may also overflow the three-way size_t multiply on 32-bit kernels.&lt;/p&gt;
&lt;p&gt;Additionally, the ACE walk loop uses the weaker
offsetof(struct smb_ace, access_req) minimum size check rather than
the minimum valid on-wire ACE size, and does not reject ACEs whose
declared size is below the minimum.&lt;/p&gt;
&lt;p&gt;Reproduced on UML + KASAN + LOCKDEP against the real ksmbd code path.
A legitimate mount.cifs client creates a parent directory over SMB
(ksmbd writes a valid security.NTACL xattr), then the NTACL blob on
the backing filesystem is rewritten to set num_aces = 0xFFFF while
keeping the posix_acl_hash bytes intact so ksmbd_vfs_get_sd_xattr()&amp;#39;s
hash check still passes.  A subsequent SMB2 CREATE of a child…&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;ksmbd: validate num_aces and harden ACE walk in smb_inherit_dacl()&lt;/p&gt;
&lt;p&gt;smb_inherit_dacl() trusts the on-disk num_aces value from the parent
directory&amp;#39;s DACL xattr and uses it to size a heap allocation:&lt;/p&gt;
&lt;p&gt;aces_base = kmalloc(sizeof(struct smb_ace) * num_aces * 2, ...);&lt;/p&gt;
&lt;p&gt;num_aces is a u16 read from le16_to_cpu(parent_pdacl-&amp;gt;num_aces)
without checking that it is consistent with the declared pdacl_size.
An authenticated client whose parent directory&amp;#39;s security.NTACL is
tampered (e.g. via offline xattr corruption or a concurrent path that
bypasses parse_dacl()) can present num_aces = 65535 with minimal
actual ACE data.  This causes a ~8 MB allocation (not kzalloc, so
uninitialized) that the subsequent loop only partially populates, and
may also overflow the three-way size_t multiply on 32-bit kernels.&lt;/p&gt;
&lt;p&gt;Additionally, the ACE walk loop uses the weaker
offsetof(struct smb_ace, access_req) minimum size check rather than
the minimum valid on-wire ACE size, and does not reject ACEs whose
declared size is below the minimum.&lt;/p&gt;
&lt;p&gt;Reproduced on UML + KASAN + LOCKDEP against the real ksmbd code path.
A legitimate mount.cifs client creates a parent directory over SMB
(ksmbd writes a valid security.NTACL xattr), then the NTACL blob on
the backing filesystem is rewritten to set num_aces = 0xFFFF while
keeping the posix_acl_hash bytes intact so ksmbd_vfs_get_sd_xattr()&amp;#39;s
hash check still passes.  A subsequent SMB2 CREATE of a child…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-31706</guid>
    </item>
    <item>
      <title>GHSA-8pq6-4w7p-qw4g</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-8pq6-4w7p-qw4g</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ksmbd: validate num_aces and harden ACE walk in smb_inherit_dacl()&lt;/p&gt;
&lt;p&gt;smb_inherit_dacl() trusts the on-disk num_aces value from the parent
directory&amp;#39;s DACL xattr and uses it to size a heap allocation:&lt;/p&gt;
&lt;p&gt;aces_base = kmalloc(sizeof(struct smb_ace) * num_aces * 2, ...);&lt;/p&gt;
&lt;p&gt;num_aces is a u16 read from le16_to_cpu(parent_pdacl-&amp;gt;num_aces)
without checking that it is consistent with the declared pdacl_size.
An authenticated client whose parent directory&amp;#39;s security.NTACL is
tampered (e.g. via offline xattr corruption or a concurrent path that
bypasses parse_dacl()) can present num_aces = 65535 with minimal
actual ACE data.  This causes a ~8 MB allocation (not kzalloc, so
uninitialized) that the subsequent loop only partially populates, and
may also overflow the three-way size_t multiply on 32-bit kernels.&lt;/p&gt;
&lt;p&gt;Additionally, the ACE walk loop uses the weaker
offsetof(struct smb_ace, access_req) minimum size check rather than
the minimum valid on-wire ACE size, and does not reject ACEs whose
declared size is below the minimum.&lt;/p&gt;
&lt;p&gt;Reproduced on UML + KASAN + LOCKDEP against the real ksmbd code path.
A legitimate mount.cifs client creates a parent directory over SMB
(ksmbd writes a valid security.NTACL xattr), then the NTACL blob on
the backing filesystem is rewritten to set num_aces = 0xFFFF while
keeping the posix_acl_hash bytes intact so ksmbd_vfs_get_sd_xattr()&amp;#39;s
hash check still passes.  A subsequent SMB2 CREATE of a child…&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;ksmbd: validate num_aces and harden ACE walk in smb_inherit_dacl()&lt;/p&gt;
&lt;p&gt;smb_inherit_dacl() trusts the on-disk num_aces value from the parent
directory&amp;#39;s DACL xattr and uses it to size a heap allocation:&lt;/p&gt;
&lt;p&gt;aces_base = kmalloc(sizeof(struct smb_ace) * num_aces * 2, ...);&lt;/p&gt;
&lt;p&gt;num_aces is a u16 read from le16_to_cpu(parent_pdacl-&amp;gt;num_aces)
without checking that it is consistent with the declared pdacl_size.
An authenticated client whose parent directory&amp;#39;s security.NTACL is
tampered (e.g. via offline xattr corruption or a concurrent path that
bypasses parse_dacl()) can present num_aces = 65535 with minimal
actual ACE data.  This causes a ~8 MB allocation (not kzalloc, so
uninitialized) that the subsequent loop only partially populates, and
may also overflow the three-way size_t multiply on 32-bit kernels.&lt;/p&gt;
&lt;p&gt;Additionally, the ACE walk loop uses the weaker
offsetof(struct smb_ace, access_req) minimum size check rather than
the minimum valid on-wire ACE size, and does not reject ACEs whose
declared size is below the minimum.&lt;/p&gt;
&lt;p&gt;Reproduced on UML + KASAN + LOCKDEP against the real ksmbd code path.
A legitimate mount.cifs client creates a parent directory over SMB
(ksmbd writes a valid security.NTACL xattr), then the NTACL blob on
the backing filesystem is rewritten to set num_aces = 0xFFFF while
keeping the posix_acl_hash bytes intact so ksmbd_vfs_get_sd_xattr()&amp;#39;s
hash check still passes.  A subsequent SMB2 CREATE of a child…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-8pq6-4w7p-qw4g</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-31706 — ksmbd: validate num_aces and harden ACE walk in smb_inherit_dacl()</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-31706</link>
      <description>msrc_CVE-2026-31706</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-31706</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:10793-1 — kernel-devel-7.0.7-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:10793-1</link>
      <description>&lt;p&gt;kernel-devel-7.0.7-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-7.0.7-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:10793-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-31706</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31706</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: ksmbd: validate num_aces and harden ACE walk in smb_inherit_dacl() smb_inherit_dacl() trusts the on-disk num_aces value from the parent directory&amp;#39;s DACL xattr and uses it to size a heap allocation:   aces_base = kmalloc(sizeof(struct smb_ace) * num_aces * 2, ...); num_aces is a u16 read from le16_to_cpu(parent_pdacl-&amp;gt;num_aces) without checking that it is consistent with the declared pdacl_size. An authenticated client whose parent directory&amp;#39;s security.NTACL is tampered (e.g. via offline xattr corruption or a concurrent path that bypasses parse_dacl()) can present num_aces = 65535 with minimal actual ACE data.  This causes a ~8 MB allocation (not kzalloc, so uninitialized) that the subsequent loop only partially populates, and may also overflow the three-way size_t multiply on 32-bit kernels. Additionally, the ACE walk loop uses the weaker offsetof(struct smb_ace, access_req) minimum size check rather than the minimum valid on-wire ACE size, and does not reject ACEs whose declared size is below the minimum. Reproduced on UML + KASAN + LOCKDEP against the real ksmbd code path. A legitimate mount.cifs client creates a parent directory over SMB (ksmbd writes a valid security.NTACL xattr), then the NTACL blob on the backing filesystem is rewritten to set num_aces = 0xFFFF while keeping the posix_acl_hash bytes intact so ksmbd_vfs_get_sd_xattr()&amp;#39;s hash check still passes.  A subsequent SMB2 CREATE of a child under…&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: ksmbd: validate num_aces and harden ACE walk in smb_inherit_dacl() smb_inherit_dacl() trusts the on-disk num_aces value from the parent directory&amp;#39;s DACL xattr and uses it to size a heap allocation:   aces_base = kmalloc(sizeof(struct smb_ace) * num_aces * 2, ...); num_aces is a u16 read from le16_to_cpu(parent_pdacl-&amp;gt;num_aces) without checking that it is consistent with the declared pdacl_size. An authenticated client whose parent directory&amp;#39;s security.NTACL is tampered (e.g. via offline xattr corruption or a concurrent path that bypasses parse_dacl()) can present num_aces = 65535 with minimal actual ACE data.  This causes a ~8 MB allocation (not kzalloc, so uninitialized) that the subsequent loop only partially populates, and may also overflow the three-way size_t multiply on 32-bit kernels. Additionally, the ACE walk loop uses the weaker offsetof(struct smb_ace, access_req) minimum size check rather than the minimum valid on-wire ACE size, and does not reject ACEs whose declared size is below the minimum. Reproduced on UML + KASAN + LOCKDEP against the real ksmbd code path. A legitimate mount.cifs client creates a parent directory over SMB (ksmbd writes a valid security.NTACL xattr), then the NTACL blob on the backing filesystem is rewritten to set num_aces = 0xFFFF while keeping the posix_acl_hash bytes intact so ksmbd_vfs_get_sd_xattr()&amp;#39;s hash check still passes.  A subsequent SMB2 CREATE of a child under…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31706</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1346 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1346</link>
      <description>&lt;p&gt;Ein entfernter Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um Root-Rechte zu erlangen, um Sicherheitsmechanismen zu umgehen, einen Denial-of-Service-Zustand herbeizuführen oder Auswirkungen unbestimmter Art zu erzielen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein entfernter Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um Root-Rechte zu erlangen, um Sicherheitsmechanismen zu umgehen, einen Denial-of-Service-Zustand herbeizuführen oder Auswirkungen unbestimmter Art zu erzielen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1346</guid>
    </item>
  </channel>
</rss>
