DF-0781 leaked kernel heap bytes captured from maxx's getdents buffer
====================================================================

Daemon sent a FUSE_READDIR reply with fuse_dirent.namelen = 32000 but only
8 actual name bytes ("ABCDEFGH").  fuse_vop_readdir passed namelen straight
to vop_write_dirent, which did bcopy(fde->name, dp->d_name, 32000) reading
32000 bytes from the daemon's 48-byte kmalloc'd reply buffer.

Bytes 0..7 of the leaked window are "ABCDEFGH" (real name).
Bytes 8..31999 of the leaked window are KERNEL HEAP that was adjacent to
the reply buffer in the M_FUSE_BUF slab.

Sample of the leaked kernel heap bytes (hex, little-endian qwords):
------------------------------------------------------------------

0100000008000000 f021628d00f8ffff f921628d00f8ffff 72636e675f6c766d
|               |               |               |               |
|               |               |               ascii: "rcng_lvm"
|               |               |
|               |               kernel pointer 0xfffff8008d6221f9
|               |
|               kernel pointer 0xfffff8008d6221f0
|
struct field (refcount=1, length=8)

0064697361626c65 6400000000000000 0000000000000000 0400000000000000
|               |
ascii: "\0disabled"

0200000000000000 0000000000000000 007d000008000000 4142434445464748
                                                |               |
                                                ascii: "ABCDEFGH"
                                                (start of NEXT readdir dirent
                                                 being assembled by the kernel
                                                 from wild-pointer garbage
                                                 after the len underflow)

010000000f000000 5022628d00f8ffff 6022628d00f8ffff 72636e675f637279
                                                |               |
                                                ascii: "rcng_cry..."

70746469736b7300 72756e6e696e6700 0822628d00f8ffff 0800000000000000
|               |
ascii: "ptdisks\0"   (completes "rcng_cryptdisks")
"running\0"

010000000f000000 b022628d00f8ffff c022628d00f8ffff 72636e675f696e69
                                                ascii: "rcng_ini..."

7472616e646f6d00 72756e6e696e6700 0100000009000000 e022628d00f8ffff
|               |
ascii: "trandom\0"  (completes "rcng_initrandom")
"running\0"

ea22628d00f8ffff 72636e675f667363 6b0072756e6e696e 6700000000000000
                    |               |
                    ascii: "rcng_fsck\0"   "runnin" (+ "g\0")

6822628d00f8ffff ...
7023628d00f8ffff ... 72636e675f646863 7064006469736162
                                ascii: "rcng_dhcpd\0disab" (+ "led\0")

Decoded kernel pointers (little-endian uint64):
-----------------------------------------------
  0xfffff8008d6221f0    0xfffff8008d6221f9
  0xfffff8008d622250    0xfffff8008d622260
  0xfffff8008d6222b0    0xfffff8008d6222c0
  0xfffff8008d6222e0    0xfffff8008d6222ea
  0xfffff8008d6222f8    0xfffff8008d622368
  0xfffff8008d622370    0xfffff8008d62237b

These are kernel heap addresses in the 0xfffff800... KVA range — a clear
kernel info leak.  The leaked ASCII strings ("rcng_lvm", "rcng_cryptdisks",
"rcng_initrandom", "rcng_fsck", "rcng_dhcpd", "running", "disabled")
are rcNG service-name strings from kernel memory, demonstrating that the
adjacent slab objects contain real kernel data.

Across 5 consecutive runs (same mount) the count of non-zero leaked bytes
varied: 281, 366, 385, 404, 0, 262 — i.e. the leak content varies with
slab state, confirming this is genuine heap residue and not deterministic
zero-fill.