DF-5187 — default drm_gem_dumb_map_offset returns offsets from the wrong address space (latent, dead in-tree)

What

The default drm_gem_dumb_map_offset (reached from drm_mode_mmap_dumb_ioctl's else branch, sys/dev/drm/drm_dumb_buffers.c:128) returns

*offset = drm_vma_node_offset_addr(&obj->vma_node);   /* drm_gem.c:401 */

the raw vma-offset-manager address (drm_mm region starting at DRM_FILE_PAGE_OFFSET_START = 0x100000 pages = 1<<40 bytes — drm_gem.c:119-160). But the DragonFly mmap resolver for the DRM cdev only understands the legacy hash-key form:

if ((offset & DRM_GEM_MAPPING_MASK) != DRM_GEM_MAPPING_KEY)   /* 2ULL<<62 */
        return (NULL);                                        /* drm_gem.c:1070 */
offset &= ~DRM_GEM_MAPPING_KEY;
drm_ht_find_item(&mm->offset_hash, DRM_GEM_MAPPING_IDX(offset), ...)

and the hash key lives in a different allocator (mm->idxunr, drm_gem.c:153) than the vma node's page index — two independent namespaces grafted together in this port. i915's own override returns the correct form (DRM_GEM_MAPPING_OFF(obj->base.map_list.key) | DRM_GEM_MAPPING_KEY, i915_gem.c:2647-2648), which is what everything actually uses.

Consequences for any driver relying on the default:

1. the MAP_DUMB offset lacks the KEY bits → mmap() on it returns ENODEV (dumb buffers unmap-able — functional bug);
2. nothing in the default path establishes the correspondence the resolver assumes (vma page index vs idxunr key), so the two namespaces can disagree about which object an offset denotes — the same mis-wiring that gives DF-5186's race its wrong-object resolution power.

Scope

Latent: all three in-tree KMS drivers override .dumb_map_offset (amdgpu_drv.c:1322, i915_drv.c:3301, radeon_drv.c:693), so no in-tree path uses the default. Info severity; filed so the port's dual-namespace mmap plumbing is on record and because any out-of-tree/currently-unwired GEM driver that trusts the default hands out unmappable (or mis-resolving) offsets.

Fix

Return the hash-key form exactly like i915 (fix.diff). Not verified at runtime (no in-tree consumer; no DRM device on the audit guest) — hence status untested.

DF-5187 — VERDICT

status: untested · Info/latent — no PoC attempted (no in-tree consumer of the default path; no DRM device on the audit guest).

Code facts (all verified by reading this tree):

• drm_mode_mmap_dumb_ioctl falls back to drm_gem_dumb_map_offset when the driver does not override (sys/dev/drm/drm_dumb_buffers.c:120-129).
• drm_gem_dumb_map_offset returns the vma-manager address (sys/dev/drm/drm_gem.c:401); that address space starts at DRM_FILE_PAGE_OFFSET_START = 0x100000 pages (drm_gem.c:119-123,158-160) and carries no DRM_GEM_MAPPING_KEY bits.
• The cdev mmap path drm_mmap_single → drm_gem_mmap_single → drm_gem_object_from_offset (drm_drv.c:1256-1270, drm_gem.c:1063-1080) rejects offsets without the KEY bits (ENODEV) and resolves the index through the separate mm->idxunr key space (drm_gem.c:153,576).
• i915's override returns the resolver-compatible form DRM_GEM_MAPPING_OFF(map_list.key) | DRM_GEM_MAPPING_KEY (i915_gem.c:2647-2648) — proof that the two namespaces are distinct and only the hash-key form works.
• In-tree users of the default: none (.dumb_map_offset set by amdgpu_drv.c:1322, i915_drv.c:3301, radeon_drv.c:693).

Conclusion: real mis-wiring, currently dead in-tree, actionable one-line fix (fix.diff). No runtime verification performed — nothing to run against.

kernel_refs

• sys/dev/drm/drm_dumb_buffers.c:120-129 (audited-file fallback)
• sys/dev/drm/drm_gem.c:381-406 (default handler)
• sys/dev/drm/drm_gem.c:1063-1080 (resolver requiring KEY|OFF(hash key))
• sys/dev/drm/drm_gem.c:119-160 (two disjoint offset allocators)
• sys/dev/drm/i915/i915_gem.c:2647-2648 (working override form)

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.