# DF-3382 — stale undersized BPF store buffers after interface destroy + BIOCSBLEN

## What
`BIOCSETBLEN` guards only against `d->bd_bif != NULL` (bpf.c:795), but the
buffer allocation in `bpf_setif()` guards on `d->bd_sbuf == NULL`
(bpf.c:1128).  After `bpfdetach()` (interface destroyed) a bound descriptor
keeps its allocated buffers with `bd_bif == NULL` (bpf_detachd, bpf.c:320-326
via bpfdetach bpf.c:1580-1583).  In that state:

1. `BIOCSBLEN(0x80000)` succeeds (guard passes) — `bd_bufsize` is raised to
   512 KiB while the kmalloc'd store/free buffers stay 4096 bytes
   (`BPF_DEFAULTBUFSIZE`).
2. `BIOCSETIF(newif)` sees `bd_sbuf != NULL` and **skips** `bpf_allocbufs()`.
3. `catchpacket()` now believes it has 512 KiB of store buffer and appends
   packets at `bd_sbuf + curlen` for ~512 KiB — writing hundreds of KiB of
   attacker packet data past the 4096-byte allocation.

## Reproduce (in guest)
```
ifconfig tun0 create
cc -O -o trigger trigger.c
./trigger
```
Expected: mass kernel heap corruption → panic/fatal trap shortly after the
loopback flood begins.

Observed: all 512 packets sent (lo0 tap appends ~1.4 KiB each into a
4096-byte buffer with `bd_bufsize=524288`), process printed "survived", and
the kernel died seconds later in the namecache path (see `panic.txt`):

```
Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; lapic id = 0
instruction pointer = 0x8:0xffffffff806dea20
Stopped at cache_nlookup_maybe_shared+0x100: cmpq %rax,0x48(%rbx)
```

The GPF'd `cmpq` was reading a corrupted namecache object — the overflow
had crossed into kernel slab memory filled with 0x41 ('A') payload bytes.

## Fix
Same `fix.diff` as DF-3381: `BIOCSETBLEN` is rejected once `bd_sbuf != NULL`.