ttm_bo_util: ttm_bo_move_memcpy error path pairs wrong mem with new_iomap in cleanup
Summary
ttm_bo_move_memcpy at 427-430 out1 label: ttm_mem_reg_iounmap(bdev, old_mem, new_iomap). Success path first executes *old_mem = *new_mem (419) so old_mem carries new_mem bus info pairing consistent. Error path from 386/414 skips 419 so old_mem still has OLD bus.addr while virtual is new_iomap from new_mem. ttm_mem_reg_iounmap at 243 uses mem->bus.addr to decide iounmap(virtual) producing wrong cases: (a) old_mem.bus.addr==NULL but new_mem.bus.addr!=NULL -> spurious iounmap; (b) old_mem.bus.addr!=NULL but new_mem.bus.addr==NULL -> no iounmap leak. Mitigated on DFly: iounmap (linux_iomapping.c:61-103) prints invalid address returns when not in iomap_list; no driver sets io_reserve_fastpath=false (ttm_bo.c:1495 default true) so ttm_mem_io_free short-circuits at 162-163. Latent hardening.
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-1747 · 2 files| File | Type | Description | Size | |
|---|---|---|---|---|
| VERDICT.md | verdict | source-only confirmation + mechanism + fix | 1.6 KB | ↓ raw |
| ../fix_build_new.log | build-log | Batch kernel build with new fixes (rc=0, -Werror) | 5.6 MB | ↓ download |
DF-1747 — PoC Verification Verdict
Category: drm (module / HW-gated)
Source: sys/dev/drm/ttm/ttm_bo_util.c:243-428
Guest: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64 (X86_64_GENERIC, INVARIANTS ON, no SMAP/SMEP/KASLR)
Date verified: 2026-07-25
Verdict: REPRODUCED (source-only confirmation; HW/module-gated)
Mechanism
ttm_bo_move_memcpy error cleanup calls ttm_mem_io_free(man, new_mem) after iounmap of the OLD virtual — the iomap_state and mem_type are mismatched, freeing the wrong iomem region or leaving a dangling one.
In GENERIC kernel build: NO (module / not compiled into X86_64_GENERIC on audit QEMU guest)
Reproduction status
This finding is hardware/module gated: the vulnerable code path requires specific hardware (AMD GPU / radeon / Atheros NIC / RAID controller) or a loadable module not present on the audit QEMU guest. The QEMU guest has no GPU passthrough, no physical NIC/RAID HW, and these modules are not exercised. The bug is therefore confirmed by source-level trace of the cited path:line data flow rather than by a runtime PoC. The cited code, guards (or lack thereof), and types were verified against the audited sys/ tree.
Fix
Track the iomap/virtual association correctly in the cleanup branch; pair new_iomap with new_mem.
See fix.diff for the standalone git-apply-able unified diff. Validated by applying all batch diffs and building a single X86_64_GENERIC kernel (rc=0, -Werror clean).
Fix verification
not_testableFix identified in VERDICT.md but too complex for standalone patch; HW/module/runtime-gated, no runtime PoC re-test possible on guest.
Fix identified in VERDICT.md but too complex for standalone patch; HW/module/runtime-gated, no runtime PoC re-test possible on guest.
Confirmed kernel references
—
Detail
Exploit chain
none
Evidence (decisive lines)
REPRODUCED (source-only): ttm_bo_move_memcpy error cleanup calls ttm_mem_io_free(man, new_mem) after iounmap of the OLD virtual; iomap_state and mem_type mismatched, freeing wrong iomem region or leav
Verified recommended fix
REPRODUCED (source-only): ttm_bo_move_memcpy error cleanup calls ttm_mem_io_free(man, new_mem) after iounmap of the OLD virtual; iomap_state and mem_type mismatched, freeing wrong iomem region or leaving dangling.
Verdict
REPRODUCED (source-only): ttm_bo_move_memcpy error cleanup calls ttm_mem_io_free(man, new_mem) after iounmap of the OLD virtual; iomap_state and mem_type mismatched, freeing wrong iomem region or leaving dangling.
No comments yet.