DF-0243 — PoC evidence pack

Finding: alleged size_t underflow in exec_shell_imgact when argv[0] is longer than interpreter + fname → claimed kernel panic. File: sys/kern/imgact_shell.c:117-129 Severity claimed: High (local DoS / kernel panic).

Result: NOT REPRODUCED — FALSE POSITIVE

The size_t subtraction at imgact_shell.c:126 does wrap when strlen(argv[0]) > strlen(interp) + strlen(fname), but the wrap is mathematically equivalent to the intended signed subtraction:

• begin_envv / endp are char * — adding SIZE_MAX − K to a pointer is identical (mod 2⁶⁴) to subtracting K+1, which is the correct intended delta. The pointer lands safely inside the ARG_MAX + PATH_MAX args buffer.
• space is int — (int)((size_t)space − wrapped_offset) truncates back to the correct value because |length − offset| ≤ ARG_MAX + PAGE_SIZE ≪ INT_MAX.
• The bcopy at :123-124 is safe in the shrink branch (content only moves left, always within the buffer); the E2BIG guard at :120 correctly targets the grow branch.

Result: no wild pointer, no memory corruption, no panic. The script runs /bin/sh /tmp/df0243_s normally and prints DF0243_SCRIPT_RAN. This holds even with a large environment (trigger2) forcing the bcopy to shift real bytes — the sentinel env var survives intact.

See VERDICT.md for the full line-by-line mechanism walkthrough.

A defense-in-depth hardening fix.diff (signed-safe rewrite of :126-129) was authored and validated on a single-fix kernel (#1): it compiles, boots, and is behaviorally identical to the original. It is optional cleanup, not a security fix.

How to reproduce

./build.sh    # cc trigger/trigger2/math_proof, create the #!/bin/sh scripts
./run.sh      # math proof + argv[0] length sweep + large-env bcopy stress

Expected on the audited master DEV kernel (and on the single-fix kernel)

=== math proof ===
begin_envv   0x1016   0x1016   0x1016   ALL MATCH
endp         0x1016   0x1016   0x1016   ALL MATCH
space        262122   262122   262122   ALL MATCH
=> the size_t wrap is mathematically equivalent to the signed op.

=== argv[0] length = 256 (and 1024, 4096, 32768, 131072, 262140) ===
DF0243_SCRIPT_RAN
DF0243_NO_PANIC: script executed normally -- underflow did not crash

=== large-env bcopy stress ===
DF0243_ENV_OK argv=0 sentinel_intact

No panic at any length or env size. The guest stays up. No kernel warnings.

Optional defense-in-depth fix

fix.diff rewrites the 4 modular-arithmetic lines at :126-129 as an explicit grow/shrink branch with no size_t underflow. Validated: - git apply --check ✓ ; patch -p1 in-guest ✓ (hunk at line 123) - make -j6 nativekernel ✓ rc=0 ; make installkernel ✓ - boots to 6.5-DEVELOPMENT #1 clean; run.sh + trigger2 behave identically

This supersedes the finding markdown's ## Recommended fix proposal (same approach, cleaner variable names + justifying comment). Since the cited code is not actually vulnerable, the patch is optional hardening, not a required security fix.

Files

DF-0243 — VERDICT: NOT REPRODUCED / FALSE POSITIVE (defense-in-depth patch validated)

One-line verdict

The size_t subtraction at sys/kern/imgact_shell.c:126 does underflow when argv[0] is longer than interpreter_tokens + fname, but the wrap is mathematically harmless: C pointer arithmetic is modular over 2⁶⁴, so begin_envv/endp land at the correct intended offset, and space (truncated back to int) also ends up correct. There is no wild pointer, no memory corruption, and no panic. Reproduced-as-panic: no. Classification: false positive (reviewer error in modular-arithmetic reasoning). A defense-in-depth hardening fix.diff was authored and validated on a single-fix kernel (it is semantically equivalent — no behavior change).

Evidence (decisive)

Two independent triggers were run on the unpatched audit kernel (6.5-DEVELOPMENT #0, Thu Jul 2 06:02:54 UTC 2026):

(1) trigger — exec #!/bin/sh with argv[0] swept from 256 B to 262 140 B (≈ ARG_MAX). At every length the kernel never panicked, never logged a warning, and the guest stayed up. The script ran /bin/sh and printed DF0243_SCRIPT_RAN every time:

=== argv[0] length = 256 ===
DF0243_SCRIPT_RAN
DF0243_CHILD_EXIT code=0
DF0243_NO_PANIC: script executed normally -- underflow did not crash

(Same DF0243_NO_PANIC result for 1024, 4096, 32768, 131072, 262140.)

(2) trigger2 (NEW) — the original PoC used envp={NULL}, so the bcopy at imgact_shell.c:123-124 copied 0 bytes (n = endp - begin_argv - length = 0) and the env-shifting path was never exercised. trigger2 passes a large environment (hundreds of multi-KB env vars), forcing the bcopy to actually shift real bytes left by (length - offset) while the underflow branch is active. A sentinel env var (DF0243_SENTINEL=CANARY-7B3F) is checked post-exec:

=== underflow branch + large env: argv0=256, 200 env vars x 1024 bytes ===
DF0243_ENV_OK argv=0 sentinel_intact
DF0243_CHILD_EXIT code=0 (0=script ran with env intact)
DF0243_NO_PANIC: argv0=256 nenv=200 envlen=1024 -- bcopy+underflow harmless

(Same for argv0=4096/400×256, argv0=32768/100×512, argv0=5000/40×6000.)

The sentinel surviving intact post-bcopy proves the env block was shifted to the correct location — i.e. the underflow-adjusted pointers were right.

math_proof.c reproduces the exact arithmetic of imgact_shell.c:117-129 and shows the "buggy" path produces byte-for-byte the same begin_envv, endp, and space as the intended signed semantics:

field        buggy-path      intended        expected        verdict
begin_envv   0x1016         0x1016         0x1016         ALL MATCH
endp         0x1016         0x1016         0x1016         ALL MATCH
space        262122         262122         262122         ALL MATCH
=> the size_t wrap is mathematically equivalent to the signed op.

Mechanism walkthrough (why the reviewer was wrong)

The finding's claim hinges on this block (sys/kern/imgact_shell.c:117-129):

offset += strlen(imgp->args->fname) + 1;     /* :117 */
length = strlen(imgp->args->begin_argv) + 1; /* :118 */

if (offset > imgp->args->space + length)     /* :120 */
    return (E2BIG);

bcopy(imgp->args->begin_argv + length, imgp->args->begin_argv + offset,
      imgp->args->endp - (imgp->args->begin_argv + length));  /* :123-124 */

offset -= length;                             /* :126 -- UNDERFLOW (size_t) */
imgp->args->begin_envv += offset;             /* :127 */
imgp->args->endp += offset;                   /* :128 */
imgp->args->space -= offset;                  /* :129 */

For argv[0] = 256 'A's, #!/bin/sh, fname /tmp/df0243_s: - offset = 8 (interp) + 14 (fname+1) = 22 - length = 257 - offset -= length → 22 − 257 wraps to 0xFFFFFFFFFFFFFF15 (SIZE_MAX − 234).

The reviewer stopped here and concluded the wrapped value corrupts the pointers. But:

(1) The bcopy at :123-124 is safe in BOTH branches

n = endp - (begin_argv + length) ≥ 0 always (argv[0] is length bytes, endp is past all content). The destination range is [begin_argv + offset, begin_argv + offset + n). - Grow case (offset ≥ length): destination end = endp + (offset − length) could exceed the buffer → that is exactly what the E2BIG guard at :120 prevents (offset > space + length ⇒ E2BIG). - Shrink case (offset < length, the "underflow"): destination end = endp − (length − offset) < endp, always within the buffer — the content only moves left. The guard is irrelevant because no overflow is possible.

So the E2BIG check is correctly targeted at the grow case; the shrink case is inherently safe. The finding's note that "the guard cannot prevent the underflow" is true but irrelevant — the underflow does not need preventing.

(2) begin_envv / endp are char * — modular arithmetic saves them

Both are char * (sys/sys/imgact.h:42-44). Adding 0xFFFFFFFFFFFFFF15 to a pointer is equivalent, mod 2⁶⁴, to subtracting 235:

begin_envv_new = begin_envv + (SIZE_MAX − 234)
               = (begin_argv + 257) − 235
               = begin_argv + 22          ← correct, well inside the buffer

This is exactly what the code is trying to compute: the script's argument buffer shrank from 257 bytes (old argv[0]) to 22 bytes (/bin/sh\0/tmp/df0243_s\0), so begin_envv/endp must move back by length − offset = 235 bytes. The wrap produces precisely that result.

(3) space is int — truncation also saves it

space is declared int (sys/sys/imgact.h:46; initialized to ARG_MAX at sys/kern/kern_exec.c:1028). The expression space -= offset evaluates (size_t)space − offset and truncates back to int. The magnitude of the correction is |length − offset|, bounded by ARG_MAX + PAGE_SIZE ≈ 266 KB — comfortably inside int range. Result: space_new = (ARG_MAX − 257) + 235 = ARG_MAX − 22 = 262122 (exactly correct).

(4) Downstream exec_copyout_strings also works

After imgact returns 0, kern_exec.c:exec_copyout_strings uses ARG_MAX − imgp->args->space to size the copyout (kern_exec.c:1166, 1220). With the corrected values: ARG_MAX − space = 262144 − 262122 = 22 → copies exactly /bin/sh\0/tmp/df0243_s\0. The new process gets argv = ["/bin/sh", "/tmp/df0243_s"] — the intended, correct behavior.

Defense-in-depth hardening (fix.diff) — validated

Although there is no security bug (no panic, no corruption), the modular arithmetic trick at :126-129 is fragile: it relies on (size_t)wrap being added to a char * and int truncation both "happening to" produce the signed intent. This is hard to read and arguably relies on pointer arithmetic that, under a strict reading of the C standard, traverses an out-of-bounds intermediate value. A maintainer would reasonably want it written explicitly.

fix.diff rewrites the 4 underflow-prone lines as an explicit grow/shrink branch with no modular wrap:

if (offset >= length) {
    size_t grow = offset - length;
    imgp->args->begin_envv += grow;
    imgp->args->endp += grow;
    imgp->args->space -= (int)grow;
} else {
    size_t shrink = length - offset;
    imgp->args->begin_envv -= shrink;
    imgp->args->endp -= shrink;
    imgp->args->space += (int)shrink;
}

This is semantically identical to the original modular arithmetic (proven by math_proof.c and by identical runtime behavior on both kernels). It supersedes the finding markdown's ## Recommended fix proposal (same approach, cleaner variable names and a justifying comment).

Validation (Phase 8)

Conclusion: the hardening patch compiles, boots, and is behaviorally indistinguishable from the original on both the underflow and grow branches. It is a valid defense-in-depth cleanup, not a security fix (there was no bug to fix). Since no bad behavior ever manifested, fix_status = not_applicable for the security claim; the patch is provided as optional hardening.

PoC changes (this run vs. prior)

• trigger2.c (NEW): passes a large environment so the bcopy at imgact_shell.c:123-124 actually shifts real bytes (the original trigger used empty envp, so that bcopy copied 0 bytes and the env-shift path was never exercised). A sentinel env var verifies the shift landed correctly.
• setup2.sh (NEW): creates /tmp/df0243_s2, the #!/bin/sh script that checks the sentinel.
• build.sh / run.sh: extended to build/run trigger2.
• fix.diff (NEW): defense-in-depth signed-safe rewrite of :126-129, validated on a single-fix kernel.
• trigger.c, setup.sh, math_proof.c: unchanged from prior run.

Files in this evidence pack

No panic.txt (no panic occurred on either kernel). No dmesg.txt (no kernel warnings/corruption messages at any point).