In the Linux kernel, the following vulnerability has been resolved:

smb: client: bound dirent name against end of SMB response in cifs filldir

cifs filldir() copies the entry name out of an SMB1 TRANS2 FIND FIRST / FIND NEXT response using a length (de.namelen) supplied by the server. The kmalloc'd SMB response buffer is bounded, but nothing checks that de.name + de.namelen still lies inside that buffer before the eventual filldir64() -> verify dirent name() -> memchr() reads namelen bytes.

A hostile SMB1 server that returns an oversized FileNameLength in a directory entry therefore causes memchr() to read past the end of the response slab buffer. Reachable from any user who can list a directory on a CIFS mount served by an attacker-controlled server (getdents64() on the mounted directory):

BUG: KASAN: slab-out-of-bounds in memchr+0x71/0x80 Read of size 1 at addr ffff88800e0640cc by task poc/115 Call Trace: dump stack lvl+0x64/0x80 print report+0xce/0x620 kasan report+0xec/0x120 memchr+0x71/0x80 filldir64+0x4c/0x6a0 cifs filldir.constprop.0+0x9bb/0x1e00 cifs readdir+0x2101/0x3380 iterate dir+0x19c/0x520 x64 sys getdents64+0x126/0x210 do syscall 64+0x107/0x5a0 entry SYSCALL 64 after hwframe+0x77/0x7f

Pass the end-of-response pointer down to cifs filldir() and reject entries whose name would extend past that boundary.

This bug was discovered by Artiphishell's vTriage pipeline, which generated a userspace reproducer (an emulated hostile SMB1 server plus a getdents64() client) that reliably triggers the KASAN report on an unpatched kernel. The fix below was drafted with the Claude coding assistant; a userspace reproducer is available on request.