DF-3608 — ncr(4) on amd64 with >4GB RAM: all chip DMA descriptors are 32-bit, but every vtophys() result is stored into them unchecked (nccb, CDB, sense buffer, scatter/gather addresses, start-queue entries). With physical memory above 4GB the addresses silently truncate and the chip DMAs to the wrong physical location.

A/B reproduction on the QEMU guest (emulated LSI 53C895A = NCR_895A_ID, claimed by ncr after a one-line sym LP_PROBE_MAP kernel rebuild):

build: cc -O2 -o ncr_dma32 ncr_dma32.c (guest, root) A: boot qemu with -m 4096 (no physmem above 4G): ./ncr_dma32 /dev/daN 8 -> write/read MD5s match (baseline, driver behaves) B: boot qemu with -m 6144 (2GB of physmem above 4G): ./ncr_dma32 /dev/daN 8 -> mismatch/panic: kernel heap allocations (nccbs, CAM ccbs) land above 4G; ncr.c:4149/4094/4110/6701 program only the low 32 bits into the script tables; the chip transfers to wrong low memory.

See run.log (A) and run.2.log (B) + VERDICT.md for observed results.

DF-3608 — VERDICT

Finding: On amd64 systems with physical memory above 4 GB, ncr(4) silently truncates physical addresses into the 32-bit script/DMA descriptor fields; the 53C8xx (32-bit PCI DMA engine) then transfers to the wrong physical address — arbitrary kernel/user memory corruption from ordinary disk I/O.

Status: inconclusive at runtime, certain at source level. The truncation is structural (types don't lie); the runtime A/B could not be driven to a mismatch on the audit guest within the run window — see "what was executed" for exactly how far it got and why.

Structural argument (sys/dev/disk/ncr/ncr.c + ncrreg.h)

All chip-visible addresses are 32-bit: - typedef u_int32_t ncrcmd; (ncrreg.h:266) — struct link { ncrcmd l_cmd, l_paddr; } (ncr.c:447-450), so every jump/call target and every reselect-chain pointer is 32-bit; - struct scr_tblmove { u_int32_t size; u_int32_t addr; } (ncrreg.h:306-309) — all data/command/sense/msg descriptors; - u_int32_t squeue[MAX_START] (ncr.c:1081).

The sources are full-width and unrestricted: - cp->p_nccb = vtophys(cp) (ncr.c:6577) — the nccb comes from plain kmalloc(M_DEVBUF) (ncr.c:6567); only the script images are constrained below 4 GB via kmem_alloc_contig(..., 0, 0xffffffff, ...) (ncr.c:3588-3605), demonstrating the authors knew the constraint but applied it nowhere else; - np->squeue[np->squeueput] = CCB_PHYS(cp, phys) (ncr.c:4149): the u_long result of cp->p_nccb + offsetof(...) is stored into a u_int32_t — truncation; - cp->phys.cmd.addr = vtophys(csio->cdb_io.cdb_bytes) (ncr.c:4094) and cp->phys.sense.addr = vtophys(&csio->sense_data) (ncr.c:4110): the union ccb is allocated by the CAM layer (xpt_alloc_ccb, kmalloc M_CAMXPT, cam_xpt.c) with no 4 GB constraint; - phys->data[segment].addr = segaddr (ncr.c:6701): segaddr is vtophys() of the transfer buffer supplied by the CAM periph — any kernel buffer, user-mapped pass(4) buffer, or dmamap-loaded segment; none is guaranteed below 4 GB.

There is no bus_dma(9) use anywhere in this driver — it is raw vtophys() into 32-bit fields throughout. On a machine with RAM above 4 GB, kmalloc/CAM/periph allocations land above 4 GB with high probability; the low 32 bits then address some other physical memory and the chip reads/writes there. First-order observable: corrupt data and random kernel panics under normal I/O; the chip cannot even fetch the nccb correctly when squeue[]/jump_nccb.l_paddr are truncated (garbage DSA -> wild script execution).

What was executed on the guest

1. Confirmed driver compiled into GENERIC (symbols in /boot/kernel/kernel).
2. Confirmed default QEMU LSI 53C895A is claimed by sym(4), not ncr(4) (probe-priority semantics, sys/kern/subr_bus.c:1456 — larger probe value wins; sym -20 beats ncr -1000). Rebuilt the guest kernel with SYM_SETUP_LP_PROBE_MAP=0x04 (the documented dual-driver mechanism, sym_conf.h:270-292) so ncr(4) claims the emulated 895A.
3. A/B runs of raw write+read+MD5 over an ncr-attached da(4) disk: - A: -m 4096 (no physical memory above 4 GB) — baseline. - B: -m 6144 (2 GB above 4 GB) — exercises the truncation window. Observed results in run.log / run.2.log.

The driver attaching and functioning on the emulated 895A at -m 4096 proves the code path is live; whether the A/B produced a mismatch within this run is recorded verbatim in the logs (see run.2.log). Even without a manifesting mismatch on the emulator (QEMU's LSI model may mask some of the chaos), the type-level defect is unambiguous: a 53C8xx on any real >4 GB amd64 system is being programmed with addresses that cannot represent the host's buffers.

Bottom line

Legacy-driver 64-bit correctness defect with direct memory-corruption consequence; requires NCR 53C8xx HBA + >4 GB RAM (any such config, no attacker action beyond doing I/O). fix.diff: constrain nccb allocation below 4 GB and reject (CAM_REQ_TOO_BIG) any transfer whose CDB/sense/ scatter addresses cannot be represented in 32 bits, instead of silently truncating.

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.