# DF-0677 PoC — sl_compress_init heap overflow

## Build (as unprivileged user `maxx`, or root)
```
cd findings/poc/DF-0677
./build.sh        # -> slc_oob.ko   (compiles the real slcompress.c into the module)
```

## Run (as root — this is a primitive-proof harness for a remote-PPP bug)
```
./run.sh          # kldload ./slc_oob.ko ; watch dmesg
dmesg | grep DF0677
```

## Expected (bug present, unfixed kernel/module source)
```
DF0677: RESULT=OVERFLOW_DETECTED  2015 guard bytes clobbered, farthest write at +32123 bytes past struct
DF0677: guard[0..15]: a0 d1 44 18 01 f8 ff ff aa aa 20 aa aa aa aa aa
```
i.e. sl_compress_init(comp, 255) wrote ~32 KB past the 4656-byte struct slcompress,
depositing kernel pointers (cs_next) and a controlled byte (cs_id=0x20) into adjacent
kernel heap. (No panic — the corruption is silent; on a real sppp link this corrupts
M_TEMP neighbor objects.)

## Expected (after applying fix.diff to /usr/src/sys/net/ppp_layer/slcompress.c)
```
DF0677: RESULT=NO_OVERFLOW  guard region untouched (clamp held, max_state=255)
```

## Harness notes
- `slc_oob.c` replicates sppp's allocation exactly
  (`kmalloc(sizeof(struct slcompress), M_TEMP)`, `if_spppsubr.c:964`) and calls
  `sl_compress_init(comp, 255)` (`if_spppsubr.c:2976` with `p[4]=255`).
- A 64 KB guard region filled with 0xAA sits right after the struct; any byte that is
  not 0xAA after the call is an OOB write. The first 16 bytes are hexdumped to show
  the deposited pointer + controlled id.
- The real `slcompress.c` is compiled into the module (`.PATH: /usr/src/sys/net/ppp_layer`),
  so applying `fix.diff` to that file and rebuilding this module tests the exact fix.