DF-3272 — reproduced (remote-peer heap out-of-bounds WRITE, contents verified
byte-exact); fix validated (corruption gone).

## Root cause (path:line)
* sys/net/sppp/if_spppsubr.c:2976 — `sl_compress_init(sp->pp_comp, p[4])` with
  `p[4]` = peer's IPCP VJ Max-Slot-Id byte, unclamped (same at :3167).
* sys/net/ppp_layer/slcompress.c sl_compress_init(): writes
  `tstate[i].cs_id=i; tstate[i].cs_next=&tstate[i-1]` for i=max_state..1,
  but `tstate` is `struct cstate tstate[MAX_STATES=16]`
  (sys/net/slcompress.h:153).  sizeof(struct cstate)=144.
* victim: `sp->pp_comp = kmalloc(sizeof(struct slcompress)=4656)`
  (if_spppsubr.c:964).  tstate[32..255] => up to ~32KB past the end.

## Reproduction (stock INVARIANTS kernel, guest uname in env.txt)
Peer modeled by frame injection (harness module; see DF-3273/README.md —
sppp code itself stock).  driver sequence (drive3.c):
  1. read kernel LCP CONF-REQ off the "wire", ACK it (id re-sync loop),
  2. send own CONF-REQ with a magic option only -> LCP OPENED, PHASE_NETWORK
     (no auth configured; CONF_ENABLE_VJ is the default, if_spppsubr.c:958),
  3. inject ONE IPCP CONF-REQ carrying `02 06 00 2d ff 01`.
Kernel-memory dumps around pp_comp before/after (harness ioctl, read-only):

  BEFORE: all zeros.
  AFTER (baseline, run.log):
    comp+3932 (&tstate[27]): 0xfffff801185bb4d0 (= &tstate[26] = comp+48+144*26)
                              followed by byte 0x1b (27)      <- cs_id == i
    comp+4672: 0xfffff801185bb7a0 (= &tstate[31]) + byte 0x20 (32)
      -> 16 bytes PAST the 4656-byte allocation: the ADJACENT heap chunk
         (a sprayed 4656-byte object modeling any same-size-class victim)
         was overwritten with exactly the predicted pointer+index.

So: unauthenticated peer -> kernel heap corruption, cross-object, repeatable
(every IPCP CONF-REQ/NAK re-negotiation re-runs the write).  No immediate
panic in a clean single-shot run (the write is sparse: 9 bytes per 144-byte
stride), consistent with the two deferred panics observed in an earlier
session (jump to ip=0x0; "vm_fault: fault on stack guard" in the
sppp_cp_input ICF clone) after the corrupted regions were later used.

## Exploit chain status
* Weaponized frame: done (pure peer frames, 4 total).
* Primitive: attacker-chosen extent (17..255 -> reach comp+2352..comp+36768);
  at each 144-byte step writes a VALID kernel heap pointer (offset +0) and a
  small integer (offset +10).  Pointer values are live kernel addresses, so
  the write both corrupts and (if any byte is ever reachable back) leaks
  kernel-heap layout — no KASLR break needed for the write itself.
* Cross-object corruption into the neighbouring chunk: PROVEN (tstate[32]).
* uid0 / remote code execution: NOT completed.  Hard blocker documented: the
  primitive's per-offset values are fixed by the offset (pointer = &tstate[i-1],
  id byte = i), so escalation needs a same-size-class (4097..5120-byte) victim
  whose pointer/length field sits exactly at a 144n+48 / 144n+58 offset from
  its chunk start and whose corruption yields control — plus heap grooming to
  place it after pp_comp.  On DFly's size-segregated slab allocator that is a
  research-scale effort; deferred, not impossible.

## Fix validation
fix.diff clamps: `if (p[4] >= MAX_STATES) { p[4] = sp->ipcp.max_state; break; }`
(NAK with our value) in sppp_ipcp_RCR, and skips the re-init in
sppp_ipcp_RCN_nak.  Rebuilt in-tree (cc -Werror clean), installed, rebooted,
same driver: AFTER dumps identical to BEFORE (all zeros), link negotiates
normally (run.fixed.log).  Baseline corruption gone.

## Known-findings residual (not re-reported)
DF-0269 (sppp_print_bytes VLA) and DF-0270 (PAP ACK/NAK debug OOB bound)
remain present in the audited source; both are debug-path (IFF_DEBUG) issues.

## Fix status (batch validation)
Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest `make -j6 nativekernel KERNCONF=X86_64_GENERIC` completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.