# DF-2837 — sysctl_handle_sb_max() maintains u_long sb_max through sizeof(int) operations

## What

`sys/kern/uipc_socket2.c:686-704`: the handler for `kern.ipc.maxsockbuf`
does `SYSCTL_OUT(req, arg1, sizeof(int))` / `SYSCTL_IN(req, arg1,
sizeof(int))` against the `u_long sb_max` (8 bytes on amd64, declared at
line 75). Type confusion with two observable consequences:

1. An 8-byte sysctl write is **silently accepted** and only its low 4 bytes
   are stored — the upper half is dropped without error.
2. `sb_max` can therefore never hold (nor report) a value ≥ 4 GiB; any
   attempted larger value silently wraps to its low-32 magnitude (subject
   only to the `sb_max < MSIZE + MCLBYTES` floor check applied *after*
   truncation).

Root-only writer; hardening/correctness finding, no security boundary
crossed (the high 32 bits are provably always 0 because this is the only
writer and it only writes the low half).

## Reproduce (root)

```
cc -O -o sbmax sbmax.c && ./sbmax
```

Observed (stock kernel, run.log):

```
write #1: 8-byte value 0x0000000100001000 -> sysctl returned 0 (ok)
after ... sb_max = 4096 (0x1000)   <-- low 32 bits kept, high half silently dropped
write #2: 8-byte 0x100080000 -> ret=0, sb_max = 524288 (0x80000)  <-- magnitude wrong by 4 GiB
restored: sb_max = 524288
```

## Fix

`fix.diff` — round-trip through an explicit `int` temporary so the stored
value is always the value that was validated and reported. (Behavior for
well-formed int-width sysctl use is unchanged, so no kernel rebuild
validation was performed for this Info finding; the diff is compile-checked
in-guest as part of the DF-2836/2838 validation build.)

## Files

* `sbmax.c`, `build.sh`, `run.sh`, `run.log`, `fix.diff`, `env.txt`