DF-0895 OOB heap leak via FUSE_STATFS short reply — baseline (unpatched #0 kernel)
================================================================================
Each call: daemon writes 16-byte fuse_out_header only, claims ohd->len=96
(expected for fuse_statfs_out = 16 + 80). fuse_audit_length (BUGGY: uses
ohd->len, not actual buffer size) passes. fuse_statfs reads 80 bytes from
buf+16 into sbp->f_blocks/f_bfree/f_bavail/f_files/f_ffree, returned to
userspace via statfs(2). Non-zero = kernel heap leaked.

Note the recurring 0xffffffff82606ca0 — a kernel-image-region pointer
(.data/.bss of a kernel object in the adjacent slab chunk), stable across
runs. The 0xfffff800... values are direct-map (phys-to-virt) kernel heap
pointers; they shift run-to-run (different slab allocation addresses) —
exactly the signature of a genuine heap OOB info leak, not deterministic
output. KASLR is OFF on this guest, but the leak would defeat it on a
KASLR-enabled kernel.

=== baseline run (unpatched fuse.ko sha 680333bb...) ===
[iter 0]
  f_blocks = 0x0000000000000000
  f_bfree  = 0x0000000000000001
  f_bavail = 0xfffff8004f3308e0   <- direct-map kernel pointer
  f_files  = 0xffffffff82606ca0   <- kernel-image pointer (stable across runs)
  f_ffree  = 0x0000000800000001
[iter 1]
  f_blocks = 0xfffff8004f0a3960   <- direct-map kernel pointer
  f_bfree  = 0x0000000000000002
  f_bavail = 0x0000000000000000
  f_files  = 0x0000000000000001
  f_ffree  = 0xfffff8004f3308e0   <- direct-map kernel pointer
[iter 2]
  f_blocks = 0xfffff8004f0a3950
  f_bfree  = 0x0000000000000003
  f_bavail = 0xfffff8004f0a3960
  f_files  = 0x0000000000000002
  f_ffree  = 0x0000000000000000

=== patched run (fuse.ko sha 91d55743...) — fix validates ===
[iter 0..2]  ALL fields = 0x0000000000000000  (no leak)
  daemon's short write now rejected: actual_write=-1 (kernel returns EPROTO)