skip_block_zeroing let a 4 KiB write return 60 KiB of another tenant's disk

Reads alone came up empty. For an unmapped region of a thin device, dm-thin returns zeroes and never allocates a physical block ^[14]. The proof of concept therefore had to write before it could read. It located 64 KiB-aligned regions that the guest's ext4 filesystem treated as free space, and wrote one aligned 4 KiB block into each ^[15]. That write forced dm-thin to allocate a physical 64 KiB block out of the shared pool, and the 4 KiB replaced only its own portion ^[16].

A 4 KiB write left 60 KiB of the newly allocated block still holding whatever the previous container had put there, which is 93.75 percent of the block ^[20]. A raw read of the device afterwards returned bytes the new container had never written ^[16].

Each container gets its own virtual machine under Firecracker, which presents the writable root disk to the guest as /dev/vdc ^[9]. Per-container isolation ends at that virtual disk. When the thin volume behind a root disk was deleted, its physical blocks went back to a pool serving workloads that belonged to multiple customer accounts ^[11]. skip_block_zeroing then does what the name says: dm-thin makes a newly allocated block accessible without zeroing it first ^[12].

Telling a stranger's bytes from your own is the hard part of proving any of this. Accomplish used ext4 directory block checksums, which under the metadata_csum feature incorporate values associated with the filesystem and inode, to separate blocks from their own test filesystem from blocks originating in other filesystems ^[18]. Their submission to Cloudflare carried counts, block offsets, sizes, checksum results and truncated hash prefixes, and no third-party filenames, credentials, hostnames or recovered content values; the researchers confirmed they securely deleted the data they had recovered ^[19].

The exposure could not be aimed. Cloudflare says the technique could not target a particular customer, workload, host or data, and that residual data was not guaranteed to be present ^[5]. Customers do not pick the host their container runs on; assignment is automatic across eligible servers ^[4]. Within the historical disk-I/O telemetry available to it, Cloudflare identified no evidence of malicious exploitation, and attributed the activity it did find to the researchers and to its own engineers running authorized validation ^[7].

The fix went out across the Containers fleet and required no customer-side configuration changes ^[6]. Cloudflare's post does not say what the change was or why the option had been set. For untrusted code in a managed sandbox, I would put two questions to a provider before trusting the boundary: are freed blocks zeroed or discarded before reallocation, and is the pool behind my container shared with other accounts. Cloudflare's own account answers the second one for the affected configuration, and the answer was yes ^[11].