Network Denial of Service on macOS — Public Disclosure SMB-01A Stuart Thomas Independent Security Research — Whitby, North Yorkshire, United Kingdom 13 May 2026 ·macOS / /usr/sbin/smbd·Vendor ref: OE1105668888438·Fix scheduled Fall 2026 / In progress·CVSS 3.1: 6.5 — AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H· ORCID:0009-0008-4518-0064·CC BY 4.0 Apple’s/usr/sbin/smbdprocesses theFSCTL_SRV_COPYCHUNKIOCTL request without enforcing any of the three limits mandated by MS-SMB2 §3.3.5.15.6:MaxChunkCount(256),MaxChunkSize(1 MiB), andMaxDataSize(16 MiB). An authenticated attacker — or a guest user where File Sharing is configured to permit guest access — can supply a single IOCTL request with 65,535 chunks each of 1 MiB, causingsmbdto perform 65,535 read-write pairs totalling up to 64 GiB of disk I/O. The author confirmed all three limits absent by sending crafted SMB3 IOCTL packets and observingSTATUS_SUCCESSfor inputs the specification requires to be rejected withSTATUS_INVALID_PARAMETER. The amplification ratio — 256 bytes in, up to 64 GiB of server I/O out — is the defining property of this bug class. Keywords:denial of service · amplification · SMB2 · FSCTL_SRV_COPYCHUNK · macOS smbd · MS-SMB2 · responsible disclosure · Apple Security Bounty macOS ships a built-in SMB server,/usr/sbin/smbd, as part of the File Sharing feature. It is Apple’s own in-tree implementation — not the Samba project’ssmbd— and it implements the SMB2/3 protocol, including server-side copy via theFSCTL_SRV_COPYCHUNKIOCTL. The MS-SMB2 specification (§3.3.5.15.6) requires that conformant servers enforce three per-request limits and, if any is exceeded, returnSTATUS_INVALID_PARAMETERwith a response body advertising the enforced limits. These limits exist precisely to bound server-side resource consumption per request. Apple’s implementation enforces none of them. The practical consequence is a network-reachable amplification primitive: an attacker with an authenticated session (or a guest session where guest access is enabled) can supply a 256-byte IOCTL request and cause the server to commit up to 64 GiB of disk I/O. This exhausts I/O resources, may hangsmbd, and can render the host unresponsive. This binary is Apple’s internal SMB server implementation and is not related to the Samba project’ssmbd. MS-SMB2 §3.3.5.15.6 (FSCTL_SRV_COPYCHUNK server processing) requires conformant servers to validate three limits and, if any is exceeded, returnSTATUS_INVALID_PARAMETERwith aSRV_COPYCHUNK_RESPONSEbody containing the enforced limits: Table 2.MS-SMB2 §3.3.5.15.6 required limits and Apple smbd enforcement status. Without these limits a single request can drive arbitrary disk and CPU work. The specification’s intent is explicit: these values are defined as server-protection guardrails. The author identified the missing checks by static analysis of the arm64e slice of/usr/sbin/smbdon macOS 26.4.1, then confirmed dynamically. Insmb::extract<srv_copychunk_copy>at offset0x100049668: The value lands unmodified in the parsed message structure. copy_chunksat0x100026b6c: The loop iterateschunk_counttimes; each iteration reads and writes up tobyte_countbytes. Neither value is bounded against the specification limits. platform::allocate: The new-handler retry loop means the daemon will not return quickly under low-memory conditions; the failure mode is prolonged unresponsiveness rather than a clean error response.