# DF-5701 VERDICT

**Status: reproduced (userland rig on the exact kernel source, -O2 and -O0) — impact `none` in DragonFlyBSD (dead code).**

## Reproduced: what exactly

On the DFly guest (DragonFly 6.5-DEVELOPMENT, cc 8.3), pristine
`sys/libkern/bcmp.c` compiled verbatim, buffers in guarded pages:

- **(A)** `bcmp(a, b, 0x100000000)` returns **0 — "equal" — comparing zero
  bytes** (`int len = length` at bcmp.c:58 truncates 2^32 to 0; the
  `len == 0` early-out at bcmp.c:62-63 fires). Any equality/security use of
  bcmp with a length that is an exact multiple of 2^32 becomes a trivial
  bypass.
- **(B)** `bcmp(a, b, 0x100000008)` returns 0 while the buffers differ at
  byte 8: the truncation keeps only the low 8, so bcmp compares 8 bytes of
  a 4 GiB+8 request.
- **(C)** `bcmp(a, b, 0x80000000)` SIGSEGVs: `len` = INT_MIN, and
  `len -= sizeof(long)` at bcmp.c:88 (shifted path) / bcmp.c:114 (aligned
  path) overflows signed int (UB); with the wrap the loop counter turns
  positive and the function walks FORWARD comparing longwords far past the
  buffers until the guard page faults. In a kernel this is an unbounded
  read scan ending in a page-fault panic.

All three at -O2 and -O0 (`logs/trunc2.out`, `logs/trunc0.out`); (A) and
(B) are plain defined-behavior truncation — optimization-independent. (C)
is UB whose exact manifestation varies by compiler (it is still a false
result at worst, a wild scan at best-case-for-the-attacker).

## Why impact is `none` on DragonFlyBSD

Same structural proof as DF-5700: the file is in no kernel build
(`sys/conf/files:2199-2237` excludes it; `sys/platform/pc64/conf/files:131`
uses `platform/pc64/x86_64/bcmp.s`; vkernel links libc). The shipped
assembly bcmp takes the full 64-bit length in `%rdx`
(`logs/kernel_bcmp_disasm.txt`) and has no truncation. The bug is latent
FreeBSD-heritage code designed when `size_t` was 32-bit (where `int len`
could hold every valid length).

## Exploit chain

None on DFly (dead code). If ever revived: (A)/(B) are an auth/equality
bypass primitive; (C) is a kernel-panic DoS from any attacker-influenced
≥2^31 length.

## Fix validation (rig-level; kernel rebuild N/A — file not in any kernel)

`fix.diff` (shared with DF-5700) makes `len` a `size_t` with explicit
`len >= sizeof(long)` loop conditions and a bytewise tail. Post-fix
(`trunc_fixed.c`, `logs/truncfix.out`): lengths 2^32 and 2^32+8 no longer
return a false equal — bcmp genuinely attempts the full comparison (SIGSEGV
on the guard page, exactly as memcmp would on a 3-page arena), and the
2.3M-case differential stays at 0 failures.
Baseline reproduced=1, patched reproduced=0 (false-equal gone).

## Attempts

2 (initial harness had a self-bug — its own memset crossed a guard page;
found via the rig, fixed; then clean reproduction at both opt levels).

## Fix status (batch validation)
Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest `make -j6 nativekernel KERNCONF=X86_64_GENERIC` completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.