Apple’s smbd has no FSCTL_SRV_COPYCHUNK limit enforcement: 256 bytes in, 64 GiB disk I/O out

Apple’s /usr/sbin/smbd (not Samba — Apple’s own implementation) processes FSCTL_SRV_COPYCHUNK without enforcing any of the three limits MS-SMB2 §3.3.5.15.6 requires: – MaxChunkCount: 256 → accepted 65,535 chunks – MaxChunkSize: 1 MiB → accepted 1,048,577 bytes – MaxDataSize: 16 MiB → accepted ~17 MiB All three tests returned STATUS_SUCCESS. The spec requires STATUS_INVALID_PARAMETER. Attack: one authenticated SMB session, one 256-byte IOCTL, smbd runs 65,535 × (read_file(1MiB) + write_file(1MiB)) = 64 GiB disk I/O. The allocator retry loop means it doesn’t fail cleanly — it just keeps going. Default macOS isn’t exposed (File Sharing off by default). If you have SMB sharing enabled, mitigations are in the disclosure. Disassembly shows the chunk_count extraction landing unmodified in the parsed struct (no bounds check), and the copy loop with a cbz-only guard (bail if zero, no cmp against 256). CVSS 3.1: 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Apple confirmed 25 April 2026, fix scheduled Fall 2026. Full write-up with disassembly, runtime captures, and PoC: https://stuart-thomas.com/research/smbd-copychunk-dos/ submitted by /u/Prize-Unlucky [link] [comments]Technical Information Security Content & DiscussionRead More