<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-15T15:12:58.379882+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/cve-2026-31706</id>
    <title>CVE-2026-31706 — ksmbd: validate num_aces and harden ACE walk in smb_inherit_dacl()</title>
    <updated>2026-10-15T15:12:58.464945+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>ksmbd: validate num_aces and harden ACE walk in smb_inherit_dacl()</p>
<p>smb_inherit_dacl() trusts the on-disk num_aces value from the parent
directory's DACL xattr and uses it to size a heap allocation:</p>
<p>aces_base = kmalloc(sizeof(struct smb_ace) * num_aces * 2, ...);</p>
<p>num_aces is a u16 read from le16_to_cpu(parent_pdacl-&gt;num_aces)
without checking that it is consistent with the declared pdacl_size.
An authenticated client whose parent directory'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.</p>
<p>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.</p>
<p>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()'s
hash check still passes.  A subsequent SMB2 CREATE of a child…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2026-31706"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/lsn-0122-1</id>
    <title>LSN-0122-1 — Kernel Live Patch Security Notice</title>
    <updated>2026-10-15T15:12:58.465062+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:Pro:18.04:LTS: linux-azure-4.15, Ubuntu:Pro:18.04:LTS: linux-gcp-4.15, Ubuntu:Pro:18.04:LTS: linux and 25 more</p>
<p>In the Linux kernel, the following vulnerability has been
resolved: fs: dlm: fix use after free in midcomms commit While working on
processing dlm message in softirq context I experienced the following KASAN
use-after-free warning: .</p>
<p>In the Linux kernel, the following vulnerability has been
resolved: wifi: brcmfmac: Fix oops due to NULL pointer dereference in
brcmf_sdiod_sglist_rw() This patch fixes a NULL pointer dereference bug in
brcmfmac that occurs when a high 'sd_sgentry_align' value applies (e.g.
512) and a lot of queued SKBs are sent from the pkt queue.</p>
<p>In the Linux kernel, the following vulnerability has been
resolved: padata: fix UAF in padata_reorder A bug was found when run ltp
test: BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read
of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206 CPU: 0
PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+
Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: &lt;TASK&gt;
dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0
print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0
padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0
process_one_work+0x2ec/0x5a0 If 'mdelay(10)' is added before calling
'padata_find_next' in the 'padata_reorder' function, this issue could be
reproduced easily with ltp test (pcrypt_aead01).</p>
<p>In the Linux kernel, the following vulnerability has been
resolved: geneve: Fix use-after-free in geneve_find_de…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/lsn-0122-1"/>
  </entry>
</feed>
