FreeBSD ZFS: 64-to-32-bit size truncation in the heal receive path corrupts kernel memory

Impact

The heal receive path truncates a 64-bit payload size to 32 bits when allocating, then byteswaps using the untruncated 64-bit length - a classic undersized allocation followed by an oversized write. A local user holding the delegated ZFS receive permission can corrupt kernel memory with a crafted receive stream, which on a storage node means kernel-level compromise or a panic that takes the pool offline for everything mounting it. Storage servers backing a GPU fleet are exactly the machines where delegated zfs receive is handed to non-root replication accounts, and they are also the machines a fleet cannot lose quietly. The advisory does not state whether working exploitation beyond a panic has been demonstrated.

Who can reach it

A local user on the FreeBSD host who holds the delegated ZFS "receive" permission on a dataset. No remote or unauthenticated path is described, but note that replication endpoints frequently expose this permission over SSH to a dedicated account.

What to do

Apply the fix in FreeBSD-SA-26:40.zfs. This is a kernel change, so it takes a reboot of the storage host - schedule it with the pool's consumers drained or failed over, since clients will lose their mounts. As an interim measure, revoke the delegated receive permission from any account you do not fully trust.

References