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

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.