DF-2592 — leaked kernel heap bytes from ip_fw3_ctl_set_get (3 baseline runs, readlen 4096/2048/8192).
The first 4 bytes are the valid ctx->sets value (0x00000000). Everything past offset 4 is an
unbounded bcopy OOB read off the end of the 4-byte `sets` field through neighbouring slab chunks.

Identical residue across runs reflects a deterministic heap layout on this stable boot; the
leaked values are genuine kernel pointers (KASLR-off canonical 0xffff_ff8... addresses) into
kernel text/data, proving stale-heap disclosure, not a cosmetic/static buffer.

Run 1 (readlen=4096 -> got=4092 bytes; 477 nonzero past offset 4, 462 past offset 36):
offset 0x00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   <- sets=0 + 12B zeroed intra-chunk pad
offset 0x10: 80 98 0a 4f 00 f8 ff ff  -> 0xfffff8004f0a9880  (kernel direct-map pointer)
offset 0x18: 30 09 60 82 ff ff ff ff  -> 0xffffffff82600930  (inside ipfw3.ko text @base 0xffffffff82600000)
offset 0x20: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
offset 0x30: 00 00 00 00 00 00 00 00 20 21 0a 4f 00 f8 ff ff  -> 0xfffff8004f0a2120 (kmem ptr)
leak window [16..144):
  80980a4f00f8ffff 30096082ffffffff 0000000000000000 0100000000000000
  0000000000000000 20210a4f00f8ffff 200b6082ffffffff 0000000000000000
  0200000000000000 5053144f00f8ffff 80e5b08b00f8ffff 28dcb08b00f8ffff
  38e0b08b00f8ffff 0000000000000000 7853144f00f8ffff 88e7b08b00f8ffff

Run 2 (readlen=2048 -> got=2044): identical residue (477 nonzero past offset 4).
Run 3 (readlen=8192 -> got=8188): identical residue (477 nonzero past offset 4).

Conclusion: every getsockopt returns (readlen-4) bytes, of which the first 4 are the valid
sets field and the remaining (readlen-8) are an unbounded OOB read off the heap. The number
of leaked bytes is attacker-controlled (up to 65536 non-root / 32MB root). On the unpatched
kernel, kernel text/data pointers are disclosed on every call.