CVE-2026-31706

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: validate num_aces and harden ACE walk in smb_inherit_dacl()<br /> <br /> smb_inherit_dacl() trusts the on-disk num_aces value from the parent<br /> directory&amp;#39;s DACL xattr and uses it to size a heap allocation:<br /> <br /> aces_base = kmalloc(sizeof(struct smb_ace) * num_aces * 2, ...);<br /> <br /> num_aces is a u16 read from le16_to_cpu(parent_pdacl-&gt;num_aces)<br /> without checking that it is consistent with the declared pdacl_size.<br /> An authenticated client whose parent directory&amp;#39;s security.NTACL is<br /> tampered (e.g. via offline xattr corruption or a concurrent path that<br /> bypasses parse_dacl()) can present num_aces = 65535 with minimal<br /> actual ACE data. This causes a ~8 MB allocation (not kzalloc, so<br /> uninitialized) that the subsequent loop only partially populates, and<br /> may also overflow the three-way size_t multiply on 32-bit kernels.<br /> <br /> Additionally, the ACE walk loop uses the weaker<br /> offsetof(struct smb_ace, access_req) minimum size check rather than<br /> the minimum valid on-wire ACE size, and does not reject ACEs whose<br /> declared size is below the minimum.<br /> <br /> Reproduced on UML + KASAN + LOCKDEP against the real ksmbd code path.<br /> A legitimate mount.cifs client creates a parent directory over SMB<br /> (ksmbd writes a valid security.NTACL xattr), then the NTACL blob on<br /> the backing filesystem is rewritten to set num_aces = 0xFFFF while<br /> keeping the posix_acl_hash bytes intact so ksmbd_vfs_get_sd_xattr()&amp;#39;s<br /> hash check still passes. A subsequent SMB2 CREATE of a child under<br /> that parent drives smb2_open() into smb_inherit_dacl() (share has<br /> "vfs objects = acl_xattr" set), which fails the page allocator:<br /> <br /> WARNING: mm/page_alloc.c:5226 at __alloc_frozen_pages_noprof+0x46c/0x9c0<br /> Workqueue: ksmbd-io handle_ksmbd_work<br /> __alloc_frozen_pages_noprof+0x46c/0x9c0<br /> ___kmalloc_large_node+0x68/0x130<br /> __kmalloc_large_node_noprof+0x24/0x70<br /> __kmalloc_noprof+0x4c9/0x690<br /> smb_inherit_dacl+0x394/0x2430<br /> smb2_open+0x595d/0xabe0<br /> handle_ksmbd_work+0x3d3/0x1140<br /> <br /> With the patch applied the added guard rejects the tampered value<br /> with -EINVAL before any large allocation runs, smb2_open() falls back<br /> to smb2_create_sd_buffer(), and the child is created with a default<br /> SD. No warning, no splat.<br /> <br /> Fix by:<br /> <br /> 1. Validating num_aces against pdacl_size using the same formula<br /> applied in parse_dacl().<br /> <br /> 2. Replacing the raw kmalloc(sizeof * num_aces * 2) with<br /> kmalloc_array(num_aces * 2, sizeof(...)) for overflow-safe<br /> allocation.<br /> <br /> 3. Tightening the per-ACE loop guard to require the minimum valid<br /> ACE size (offsetof(smb_ace, sid) + CIFS_SID_BASE_SIZE) and<br /> rejecting under-sized ACEs, matching the hardening in<br /> smb_check_perm_dacl() and parse_dacl().<br /> <br /> v1 -&gt; v2:<br /> - Replace the synthetic test-module splat in the changelog with a<br /> real-path UML + KASAN reproduction driven through mount.cifs and<br /> SMB2 CREATE; Namjae flagged the kcifs3_test_inherit_dacl_old name<br /> in v1 since it does not exist in ksmbd.<br /> - Drop the commit-hash citation from the code comment per Namjae&amp;#39;s<br /> review; keep the parse_dacl() pointer.