{
  "finding_id": "DF-3151",
  "status": "untested",
  "reproduced": 0,
  "impact": "none",
  "confidence": "certain",
  "verdict": "Info/hardening, source-proven only. hammer_ioc_mirror_read never validates mirror->size (contrast the write paths explicit check at hammer_mirror.c:348) and neither mirror path validates the caller-supplied mirror->count on entry. The bounds guards at mirror.c:156/214/260 (read) and :424 (write) are computed in 32-bit arithmetic and can wrap for count near INT_MAX or negative, letting the kernel copyin/copyout at ubuf+count (~+-2GB). Not a kernel memory-safety bug: all accesses stay behind copyin/copyout user-address fault isolation and both ubuf and count come from the same SYSCAP_NOVFS_IOCTL-gated caller - impact is confined to the callers own address space plus protocol confusion. No guest run performed (nothing to demonstrate beyond the caller poking its own memory).",
  "exploit_chain": "",
  "evidence": [
    "VERDICT.md: full line-annotated analysis"
  ],
  "kernel_refs": [
    "sys/vfs/hammer/hammer_mirror.c:348",
    "sys/vfs/hammer/hammer_mirror.c:156",
    "sys/vfs/hammer/hammer_mirror.c:214",
    "sys/vfs/hammer/hammer_mirror.c:260",
    "sys/vfs/hammer/hammer_mirror.c:377",
    "sys/vfs/hammer/hammer_mirror.c:424"
  ],
  "poc_changes": "n/a (no PoC; source-analysis finding)",
  "attempts": 0,
  "guest_uname": "",
  "runtime_sec": 0,
  "guest_dirty": 0,
  "build_cmd": "",
  "run_cmd": "",
  "code_hash": "",
  "notes": "Filed as Info hardening: validate mirror->size in mirror_read like the write path, and reject count < 0 or count > size at entry to both ioctls.",
  "recommended_fix": "Validate mirror->size in hammer_ioc_mirror_read (same check as hammer_mirror.c:348) and reject out-of-range mirror->count at entry to both mirror ioctls.",
  "fix_status": "not_testable"
}