DF-5227 VERDICT — dma_alloc_coherent() returns stale kernel memory

Status: REPRODUCED (impact: leak) — on the guest, against the stock /boot/kernel/drm.ko of DragonFly 6.5-DEVELOPMENT (built Jul 2 2026).

How it was proven

poc5227.c is a kernel module (KLD, -Werror clean) that calls the real dma_alloc_coherent() exported by drm.ko:

1. contigmalloc(2MB) — the exact allocator the shim uses underneath (kmem_alloc_contig → contigmalloc_map, sys/vm/vm_contig.c:608-613). Allocation landed at physical 0x3000000.
2. Fills the block: every page starts with the ASCII marker DF5227-STALE-KERNEL-MEMORY-MARKER!, body 0xA5.
3. contigfree() — pages return to the DMA-reserve alist, contents preserved (alist_free, no zeroing anywhere: sys/vm/vm_page.c:2868-2877).
4. dma_alloc_coherent(NULL, 2MB) — per the Linux DMA API contract this must return zeroed memory.
5. Result (run.log): same physical block (0x3000000), 512/512 pages stale, all 512 markers present verbatim, 0xA5 fill visible in the hexdump.

Why deterministic: both allocations resolve through the low-memory DMA reserve's first-fit alist_alloc (vm_page.c:2806-2814), so the second allocation reuses exactly the block freed in step 3.

Why the shim is wrong

• linux_dma.c:47 kmem_alloc_contig(size, 0, high, align) → vm_contig.c:612 contigmalloc_map(size, M_DEVBUF, M_NOWAIT, ...) — no M_ZERO; vm_contig.c:533-534 zeroes only if (flags & M_ZERO).
• The reserve path (vm_contig.c:288-290) never zeroes either.
• The Linux contract ("coherent memory is zeroed") is what the disabled FreeBSD reference implementation in the same function implements (linux_dma.c:64-67 passes BUS_DMA_ZERO) — and what all live callers are forced to hand-roll: memset() at amdgpu_ih.c:66, drm_pci.c:130, radeon_gart.c:85.

Threat model / ceiling

On real hardware the "device" is the GPU. Any LinuxKPI consumer that trusts the contract and lets the engine (or userspace, via GEM/GTT mappings) read its coherent allocation discloses stale kernel/user memory. Today's in-tree callers mask the bug with memsets, so there is no live unprivileged leak on a stock desktop — hence Medium, not High. The defect is in the shim: every future/upstream-synced caller that drops its memset becomes a live kernel-info-leak (the classic dma-coherent leak class).

No uid=0 chain applies (info-leak class).

Fix validation (same run, same guest)

fix.diff (shared with DF-5228): allocate with contigmalloc_map(..., M_NOWAIT | M_ZERO, ...).

• Guest reset (vm.sh reset with-src), fix applied to /usr/src, drm.ko rebuilt from source, loaded fresh.
• Re-run of the identical PoC (run.fixed.log): DF5227 RESULT: marker_hits=0 stale_nonzero_pages=0/512 — same physical block reuse, buffer now zeroed. Baseline behavior GONE.

Observations / notes

• kldunload drm (stock or patched, no device attached) wedged the guest's kernel-linker subsystem on one occasion; pre-existing drm teardown behavior (see DF-4532/DF-5064 family), not related to this finding — the fix run avoided unload entirely (fresh boot + load).
• Guest reset clean after the runs.

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.