# DF-5700 VERDICT

**Status: reproduced (userland rig on the exact kernel source) — impact `none` in DragonFlyBSD (dead code + page-contained).**

## Reproduced: what exactly

The over-read is real and was *measured*, not just argued. On the DFly guest
(DragonFly 6.5-DEVELOPMENT, cc 8.3), the pristine `sys/libkern/bcmp.c`
compiled verbatim:

1. **Instrumented measurement** (`bcmp_instr.c`, every load wrapped,
   control flow identical, 0 semantic mismatches vs memcmp over the whole
   sweep — instrumentation validity check): out-of-`[ptr,ptr+len)` loads
   occur in 14,788 of ~291k tracked longword loads — up to **7 bytes below
   the b2 start** (the `p2 -= shr; va = *(culp)p2` down-align at
   bcmp.c:81-85) and up to **7 bytes past either buffer's end** (tail loads
   bcmp.c:110-111 and bcmp.c:128-129; streaming loop `vb` load bcmp.c:89).
   These are the loads the 1994 comment at bcmp.c:53-56 self-admits
   ("this code will reference the entire longword").
2. **Guard-page containment** (`guard_harness.c`): 512,496 calls, each
   buffer inside a page flanked by PROT_NONE guards, including every
   page-corner placement — zero faults. Combined with the analytic argument
   (all longword loads naturally aligned; 8 | 4096 ⇒ a load never straddles
   a page; every load address holds ≥1 in-bounds byte), the over-read is
   **provably confined to the buffer's first/last valid page**: it cannot
   fault, and the extra bytes are masked out of the result (no disclosure).

## Why impact is `none` on DragonFlyBSD

- Build graph: `sys/conf/files:2199-2237` (libkern list) does not compile
  `libkern/bcmp.c`; `sys/platform/pc64/conf/files:131` compiles
  `platform/pc64/x86_64/bcmp.s`; `sys/platform/vkernel64/conf/files` has no
  bcmp entry (vkernel is a userland process linked against libc).
- Running-kernel proof: `logs/kernel_bcmp_disasm.txt` — the booted
  X86_64_GENERIC kernel's `bcmp` (0xffffffff80bcb800) is the mjg
  `MEMCMP` macro: `cmp $0x10,%rdx` then first/last loads
  `mov (%rdi),%r8` / `mov -0x8(%rdi,%rdx,1),%r8` — **strictly inside
  [b1,b1+len) and [b2,b2+len) at every step** (sys/cpu/x86_64/include/
  asm_mjgmacros.h:49-198). The shipped kernel bcmp adds zero over-read to
  any caller, including the DF-5676 MATCH() caller in libprop.

## Relation to DF-5676 (pass-2 checklist d)

DF-5676 cited bcmp.c:57-110 as the reason the kernel-side MATCH() read is
"page-contained". That citation points at dead code — the *correct*
containment argument for the running system is that the shipped bcmp
(bcmp.s/memcmp.s via asm_mjgmacros.h) never reads outside the caller's
arguments at all, so the only over-read in the DF-5676 chain is the
caller's own sentinel-bounded one. Nothing in bcmp.c can worsen DF-5676:
not compiled (reachability nil), and even if compiled its over-read is
page-contained by the proof above. The one way the DF-5676 *class* could
get worse from this file is the DF-5701 truncation (a ≥2^31 length turns a
bounded read into an unbounded forward walk) — equally dead code today.

## Exploit chain

None. Dead code; contained OOB read of discarded bytes; no kernel path.

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

`fix.diff` → align-both/longword-loop/bytewise-tail rewrite:
- 2,304,192 differential cases vs memcmp: 0 failures;
- instrumented out-of-region loads: **0 below-start, 0 past-end, max
  excursion 0 bytes** (was 7/7);
- guard sweep: still 0 faults.
Baseline reproduced=1, patched reproduced=0 (bad behavior gone).

## Attempts

3 (ASAN build failed on guest — no libasan; replaced by transparent load
instrumentation; one harness self-bug found via the rig itself and fixed).

## 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.