DF-0149 — Signed-integer truncation in TLV walk size math (subr_module.c)

Verdict: REPRODUCED (code-defect confirmed; boot-time-only, not runtime-triggerable)

The signed-truncation defect is real and confirmed by code inspection and a standalone arithmetic harness. The vulnerable walk functions (preload_search_by_name / _by_type / _next_name / _info, preload_delete_name, preload_bootstrap_relocate) all run at boot over preload_metadata, a blob handed to the kernel by the boot loader from the kernel + preloaded-module image. There is no unprivileged-userspace trigger: preload_metadata is immutable after boot, and the only runtime-reachable walker (sysctl debug.dump_modinfo, preload_dump_internal) uses unsigned math (bptr += roundup(len, sizeof(u_long)) / sizeof(uint32_t) with uint32_t len) and is therefore not affected.

The bug (sys/kern/subr_module.c, every walk, e.g. :79-81)

int  next;                                   /* SIGNED */
...
next = sizeof(u_int32_t) * 2 + hdr[1];       /* hdr[1] is u_int32_t */
next = roundup(next, sizeof(u_long));        /* roundup is division-based, sign-preserving */
curp += next;

sizeof(u_int32_t) * 2 + hdr[1] is computed in size_t (unsigned 64-bit: 8 + hdr[1]), then truncated to int on assignment to next. roundup(x,y) = ((((x)+((y)-1))/(y))*(y)) (sys/sys/param.h:402) is sign-preserving, so:

• hdr[1] == 0x80000000 → 8 + 0x80000000 = 0x80000008 → int = -2147483640 → curp walks BACKWARD past preload_metadata → OOB read of memory before the blob (and, in preload_delete_name/_bootstrap_relocate, OOB write).
• hdr[1] == 0xFFFFFFF8 → 8 + 0xFFFFFFF8 = 0x100000000 → truncated int = 0 → roundup(0,8)=0 → curp never advances → infinite loop / boot hang.

Evidence (harness)

tlv_truncation.c replicates the exact kernel arithmetic over three crafted metadata blobs:

A: benign (hdr[1]=6)         -> next=16  -> forward walk, hits terminator OK
B: hdr[1]=0x80000000         -> next=-2147483640 (0x80000008) -> BACKWARD walk
   step 1: WOULD READ at offset -2147483640 -- *** BEFORE *** the 16-byte blob
C: hdr[1]=0xFFFFFFF8         -> next=0  -> INFINITE LOOP (boot hang), never advances

(The harness bounds-checks its reads so it reports the divergence instead of segfaulting; the real kernel performs no such check.)

Exploit chain

none — boot-time-only code defect. preload_metadata originates from the trusted boot loader / preloaded-module image; triggering requires a tampered preloaded module or bootloader compromise (CVSS PR:H/AC:H, matching the finding). No unprivileged-userspace path exists, so there is no escalation chain to develop. The realistic impact ceiling is boot failure / hang / OOB kernel memory access during early boot when a malicious module is preloaded.

Fix

fix.diff changes the per-record advance variable from int next to size_t next in all six walk functions (the same defect pattern repeats in each). With an unsigned type the truncation cannot produce a negative value, so curp can never walk backward and next==0 (from 0x100000000 truncation) becomes the true large forward advance instead. git apply --check passes.

Fix validation

not_testable: the vulnerable paths run only at boot over boot-loader-supplied metadata; there is no runtime syscall/sysctl that re-walks with signed math (the sole runtime walker, debug.dump_modinfo, uses unsigned math and is unaffected). Validated by git apply --check (clean) plus the harness showing the arithmetic root cause. A patched kernel would exhibit identical runtime behavior on a legitimate boot; the fix is a hardening of the boot-metadata trust boundary.