# DF-0704 — No length validation on received sync datagram

## Summary

`sys/net/ipfw3_basic/ip_fw3_sync.c:208-218` `edge_socket_handler`
casts `m->m_data` to `(int *)`, `(struct cmd_send_test *)`, and
`(struct cmd_send_state *)` without checking `m->m_len` is large enough.
A short datagram (even 1 byte with the right type tag) would cause OOB
reads in the `kprintf` paths or — if `ipfw_sync_install_state_prt` were
ever wired up — pass an undersized `cmd_send_state` struct to a future
state-install callback.

## How to reproduce

Cannot reproduce on a default kernel — see `VERDICT.md` and `run.log`.

The entire `ip_fw3_sync.c` is dead code: the dispatch pointer
`ip_fw3_ctl_sync_ptr` (sys/net/ipfw3/ip_fw3.c:133) is initialised to
NULL and **never assigned anywhere in the source tree**. The probe in
this folder issues all three relevant IP_FW_SYNC_* opcodes via `IP_FW_X`
setsockopt and confirms they all return `rc=0` with no effect.

```
./build.sh
ssh dfbsd 'sysctl net.filters_default_to_accept=1; kldload ipfw3.ko; kldload ipfw3_basic.ko'
ssh dfbsd 'cd /root/poc/DF-0704 && ./run.sh'
# expect: probe prints "All three returned without panic" — code is dead
```

## Preconditions

- root (`IP_FW_X` requires a raw IP socket, which requires
  `SYSCAP_NONET_RAW`).
- AND `ip_fw3_ctl_sync_ptr` must be non-NULL, which never happens in the
  default source.

## Impact

LATENT — currently zero. Would become a remote-firewall-bypass
possibility only after both (a) someone wires `ip_fw3_sync_modevent`
into `ipfw3_basic_modevent` and (b) the `install_state` TODO is
implemented.

## Fix

`fix.diff` adds per-type `m_len` validation in
`ip_fw3_sync_edge_socket_handler` (reject short datagrams with a
`kprintf` + `continue`). Hardening for whenever the code path is hooked
up.