===== DF-0677 BASELINE (unfixed slcompress.c): kldload ./slc_oob.ko =====
KLDLOAD_EXIT=0
DF0677: sizeof(struct slcompress)=4656  sizeof(struct cstate)=144  MAX_STATES=16
DF0677: comp=0xfffff8011844c000 max_state=255  guard=[0xfffff8011844d230..0xfffff8011845d230) sentinel=0xaa
DF0677: RESULT=OVERFLOW_DETECTED  2015 guard bytes clobbered, farthest write at +32123 bytes past struct (tstate index ~240)
DF0677: guard[0..15]: a0 d1 44 18 01 f8 ff ff aa aa 20 aa aa aa aa aa
                              ^ kernel pointer 0xfffff8011844d1a0 (cs_next=&tstate[i-1]) ^
                                                           ^ cs_id=0x20=32 (attacker-controlled byte)

Interpretation:
- struct slcompress is 4656 bytes; comp->tstate[] has MAX_STATES(16) entries.
- sl_compress_init(comp, 255) writes tstate[i] for i=255..1.
- tstate[16..31] land in comp->rstate (in-struct), tstate[32..255] overflow PAST the
  struct into adjacent heap (here: the harness guard region).
- 2015 guard bytes were written in scattered 9-byte chunks (8-byte kernel pointer +
  1-byte controlled id) at a 144-byte stride across a 32123-byte span (~32KB overflow).
- No panic: the overflow lands in mapped slab/kmem pages, so on a real sppp interface the
  corruption is planted SILENTLY into adjacent M_TEMP kernel heap (sp->pp_comp is
  kmalloc'd as M_TEMP, sys/net/sppp/if_spppsubr.c:964).