sizeof(struct fnode)=520 > FNODESIZE=512: unconditional 8-byte out-of-bounds write past the buffer in hpfs_update, mirror OOB read in hpfs_vget — cross-file page-cache corruption with attacker-crafted content, or deterministic kernel page-fault panic

Summary

struct fnode is 520 bytes on amd64 (u_int64_t fn_readhist forces 8-byte alignment over a 516-byte field tail; fn_int[0x13c] at offset 200 ends at 516, padded to 520) while FNODESIZE=512. hpfs_update getblk's a 512-byte buffer and bcopy's sizeof(struct fnode)=520 bytes into it - an 8-byte heap/buffer-cache OOB write on every fnode writeback (any truncate/extend + vnode reclaim; trigger an unpriv ftruncate/pwrite). hpfs_vget mirror-reads 520 bytes out of the 512-byte buffer on every inode load, filling h_fn[512..519] with the neighboring sector's cached bytes - the exact content the write side later sprays. Because all DFly vnode buffers are VMIO with b_data at loffset&PAGE_MASK: LSN%8 in 0..6 -> the 8 OOB bytes land on the NEXT DISK SECTOR's cached bytes (cross-file data corruption; reaches disk when that page is dirty); LSN%8==7 -> the OOB access hits the next unmapped page of the buffer's MAXBSIZE KVA reservation -> Fatal trap 12 (deterministic panic from unpriv stat(2), works on RO mounts). VERIFIED corr variant: file A fnode LSN 0x48, file B's data sector 0x49 (same VMIO page); uid 1001 pwrite B 'YYYYYYYY' + ftruncate(A,0) + reclaim -> kernel-observed B tail8 changed to 'XXXXXXXX' (attacker content). VERIFIED panic variant: fnode at LSN 0x4F -> stat as uid 1001 -> Fatal trap 12 supervisor read at page+0x1000, guest dead. Fix validated (fn_int[0x13c]->[0x138], sizeof==512, rebuilt kernel): upd pre==post, B intact, stat clean.