# DF-2837 VERDICT

**Status: reproduced** (type confusion manifests exactly as derived; root-only
writer)
**Impact: none** — hardening/correctness; no security boundary crossed.

## Root cause (path:line)

`sys/kern/uipc_socket2.c:686-704` — `sysctl_handle_sb_max()` operates on the
`u_long sb_max` (declared at line 75) with `sizeof(int)` (4-byte)
`SYSCTL_OUT`/`SYSCTL_IN` transfers:

* an 8-byte write is accepted silently and only its low 4 bytes stored;
* `sb_max` can never represent or report a value ≥ 4 GiB — attempted larger
  values silently take their low-32 magnitude (the `sb_max < MSIZE+MCLBYTES`
  floor is applied *after* truncation);
* the read side reports only the low 32 bits.

Because this handler is `sb_max`'s only writer, the high 32 bits stay 0
forever, so the confusion cannot be turned into an out-of-bounds `sb_max` —
the demonstrated impact is silent magnitude corruption of a root-settable
limit (run.log: writing `0x100080000` yields `sb_max=0x80000`, wrong by
exactly 4 GiB, with return code 0).

## Reproduction

`./sbmax` as root (run.log, restored afterwards). Behavior on the stock
kernel matches the derivation exactly.

## Fix

`fix.diff` round-trips the value through an explicit `int` temporary so what
is validated, stored and reported are the same quantity. No kernel-rebuild
validation was performed for this Info finding (behavior for well-formed
int-width use is identical by construction); the diff compiles in-guest as
part of the DF-2836/DF-2838 validation build.