Kernel panic via unvalidated on-disk leaf->data_len used as getblk() size in hammer_io_direct_uncache_callback

Summary

hammer_io_direct_uncache_callback() takes data_len straight from an on-disk B-Tree leaf and passes it to getblk() as the buffer size with only an INVARIANTS-only KKASSERT on alignment. getblk() contains an unconditional panic('getblk: size(%d) > MAXBSIZE(%d)') for size > 64K. A crafted HAMMER filesystem image containing a large-data DATA record with data_len > 64K (node CRC forged — the image author fully controls it) causes a kernel panic when the reblocker processes that record after the file data was read (the findblk/bio2-cache gate requires a prior read of the file). file_offset = key − data_len can likewise underflow to an arbitrary getblk loffset. Local DoS (kernel panic) from a crafted HAMMER1 image; precondition: root mounts the crafted image and runs 'hammer reblock' (root-only ioctl) after the target file has been read — not reachable unprivileged on a stock system. Impact ceiling is a voluntary panic; no memory corruption, no info leak — the size is used only as a buffer-cache key/size. Not built/run (Low, privileged preconditions per conditional-verify contract). Fix: validate the leaf at the single entry point in hammer_io_direct_uncache (row diff).

Timeline

• 2026-09-02 Discovered during pass-2 audit of hammer_io.c (GLM 5.3). DF-0792 re-verified, not re-reported.