⬢ DragonFlyBSD Kernel Audit
← triage · dashboard
DF-2887

uiomove/uiomovez/uiomove_fromphys/ureadc walk the iovec array with no uio_iovcnt guard — OOB iov walk on any inconsistent uio

Field Value
ID DF-2887
Status new
Severity Info
CVSS 3.1 CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N
CWE CWE-125 (defense-in-depth)
File sys/kern/kern_subr.c
Lines 120-124, 236-240, 297-301, 566-570
Area kern
Confidence speculative
Discovered 2026-09-02
Pass 2 (GLM 5.3 second pass)
Bucket base:kern
Reported pending
Known CVE none
CVE match novel

Summary

All four uio consumers advance uio_iov/uio_iovcnt on zero-length iovecs without checking uio_iovcnt > 0. They rely solely on the invariant uio_resid == sum(remaining iov_len); a uio left inconsistent by a consumer bug (the exact class DF-2626 exposed) walks the iov pointer past the end of the caller's array — reading iov_len/iov_base from adjacent kernel memory and copyin/copyouting through whatever it finds. No demonstrated path today; hardening: bail with EFAULT in the zero-length advance when iovcnt < 1 (never fires for consistent uios).

Timeline

  • 2026-09-02 Discovered during pass-2 audit of kern_subr.c (GLM 5.3).

Discussion (0)

No comments yet.

PoC verification

Evidence pack

findings/poc/DF-2887 · 10 files
FileTypeDescriptionSize
README.md — 809 B ↓ raw
VERDICT.md — 1.3 KB ↓ raw
build.sh — 50 B view raw
env.txt — 509 B view raw
fix.diff — 702 B view raw
h41.c — 14.9 KB view raw
harness.log — 2.0 KB view raw
manifest.json — 562 B view raw
run.sh — 104 B view raw
verdict.json — 2.3 KB view raw
README.md
↓ download raw

DF-2887 — uiomove family unguarded iov walk (ureadc already guarded) (Info-tier hardening verification)

What

uiomove family unguarded iov walk (ureadc already guarded)

Build

cd /root/h41 && make

Run

kldload ./h41.ko; sysctl -w debug.h41.cmd=8

Expected

baseline (stock kernel): see verdict below fix kernel (all-41-fixes build): the bad behavior is gone

A/B one-liner: baseline: ret 0 copied via OOB iov | fix: ret 14 EFAULT no copy

Files

README.md VERDICT.md build.sh env.txt fix.diff h41.c harness.log manifest.json run.sh verdict.json

Shared harness: h41.c (combined KLD, sysctl debug.h41.cmd=N driven). Full batch context: the fix kernel contains all 41 hardening fixes of this batch compiled together (build RC=0) and passed the complete A/B suite plus a clean reboot.

VERDICT.md
↓ download raw

DF-2887 — VERDICT

status: reproduced | reproduced: 1 | impact: none | confidence: certain

Confirmed with a SCOPE CORRECTION: uiomove (kern_subr.c:117-124), uiomovez (:234-241) and uiomove_fromphys (:562-571) all advance uio_iov/uio_iovcnt on zero-length iovecs with no iovcnt guard - the harness built a uio declaring ONE zero-length iov and uiomove read the SECOND iovec (lying past the declared array), iovcnt going to 0/-1, and copied 8 bytes through it: an unguarded out-of-bounds iov walk on any consumer-left-inconsistent uio. CORRECTION: ureadc (:293-301) DOES guard - it panics on uio_iovcnt==0 before advancing - so the finding's inclusion of ureadc is inaccurate; the defect is real in the three uiomove variants. The first fix attempt placed the guard inside the zero-length branch (after the first advance) and the A/B harness correctly showed the walk still succeeded; the shipped fix checks iovcnt at loop top - on the fix kernel the same uio returns EFAULT with no copy.

Fix-iteration note

Fix v1 placed the iovcnt guard inside the zero-length branch (after the first advance); the A/B harness correctly showed the walk still succeeding. v2 checks iovcnt at loop top - EFAULT.

Baseline vs fix kernel

baseline: baseline: ret 0 copied via OOB iov | fix: ret 14 EFAULT no copy fix: behavior changed as designed (see verdict)

Fix verification

fixed
baseline reproduced→ patch + rebuild →patched clean

A/B: baseline copies through the undeclared iov; fix kernel EFAULT at loop top. Fix-v1 guard placement bug caught by the A/B harness and corrected.

↓ fix.diffDragonFly dfbsd 6.5-DEVELOPMENT #1: Mon Oct 26 01:57:23 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64 (h41 fix kernel, all 41 hardening fixes applied)

Confirmed kernel references

Detail

Evidence (decisive lines)

harness.log T8: ret=0 dst[0]=A (copied through the out-of-array iov); fix kernel T8: ret=14, no copy

PoC changes

none

Verified recommended fix

Check uio_iovcnt >= 1 at the loop top of the three uiomove variants

Verdict

Confirmed with a SCOPE CORRECTION: uiomove (kern_subr.c:117-124), uiomovez (:234-241) and uiomove_fromphys (:562-571) all advance uio_iov/uio_iovcnt on zero-length iovecs with no iovcnt guard - the harness built a uio declaring ONE zero-length iov and uiomove read the SECOND iovec (lying past the declared array), iovcnt going to 0/-1, and copied 8 bytes through it: an unguarded out-of-bounds iov walk on any consumer-left-inconsistent uio. CORRECTION: ureadc (:293-301) DOES guard - it panics on uio_iovcnt==0 before advancing - so the findings inclusion of ureadc is inaccurate; the defect is real in the three uiomove variants. The first fix attempt placed the guard inside the zero-length branch (after the first advance) and the A/B harness correctly showed the walk still succeeded; the shipped fix checks iovcnt at loop top - on the fix kernel the same uio returns EFAULT with no copy.