DF-4516 — cross-device PRIME import panics the kernel via dma_buf_detach stub

What

drm_gem_prime_import_dev() (sys/dev/drm/drm_prime.c:709-762) attaches with dma_buf_attach() (drm_prime.c:733). On this port dma_buf_attach() is a stub that returns NULL, not ERR_PTR (sys/dev/drm/include/linux/dma-buf.h:96-101), so the IS_ERR(attach) guard at drm_prime.c:734 does not fire. The code proceeds, the subsequent dma_buf_map_attachment(NULL, …) returns -EINVAL (linux_dma-buf.c:196-197), and the error unwind fail_detach: calls dma_buf_detach() (drm_prime.c:758) — which is hardcoded to panic("dma_buf_attach is not implemented") (dma-buf.h:125-130).

Any foreign dma-buf (i.e. exported by another DRM device) imported through a driver that uses the generic import helper — radeon (radeon_drv.c:699) and amdgpu (amdgpu_prime.c:445-458 falls through to drm_gem_prime_import) — instantly panics the kernel. i915 has its own copy (i915_gem_dmabuf.c:305-321) that swallows the NULL attach and instead creates a zombie object with import_attach == NULL.

Files (shared trigger with DF-4515)

• df4515mod.c — sysctl hw.df4515mod.fire=6 runs exactly drm_prime.c:733→739→758
• run.log, panic.txt — baseline: panic: dma_buf_attach is not implemented
• fix_run.log — after fix.diff: dma_buf_attach -> ERR_PTR(-ENOSYS), IS_ERR=1, no panic
• fix.diff — stub returns ERR_PTR(-ENOSYS); detach stops panicking

Reproduce (as root in the guest)

cd /usr/src/sys/dev/drm/drm && make obj && make
cd /root/df4515 && make
kldload /usr/obj/usr/src/sys/dev/drm/drm/drm.ko
kldload df4515mod.ko
sysctl hw.df4515mod.fire=6      # EXPECT: panic: dma_buf_attach is not implemented

Note: the real entry (DRM_IOCTL_PRIME_FD_TO_HANDLE with a foreign prime fd) requires two DRM devices; the QEMU guest has none, so the PoC drives the identical call sequence through the shipped drm.ko symbols.

DF-4516 VERDICT — REPRODUCED (guaranteed kernel panic on cross-device PRIME import)

Bottom line

Importing a dma-buf exported by another DRM device through the generic PRIME import helper executes panic() unconditionally on this port. The chain, every step traced in source and executed on the guest against the shipped drm.ko:

1. DRM_IOCTL_PRIME_FD_TO_HANDLE (unprivileged with /dev/dri/cardN open — video group) → drm_gem_prime_fd_to_handle (drm_prime.c:792)
2. → driver gem_prime_import → generic drm_gem_prime_import_dev (drm_prime.c:709)
3. → attach = dma_buf_attach(dma_buf, attach_dev) (drm_prime.c:733) — the port's stub returns NULL (dma-buf.h:96-101); IS_ERR(NULL) is false, so the guard at :734 passes
4. → dma_buf_map_attachment(NULL, DMA_BIDIRECTIONAL) (drm_prime.c:739) returns ERR_PTR(-EINVAL) (linux_dma-buf.c:196-197)
5. → goto fail_detach → dma_buf_detach(dma_buf, attach) (drm_prime.c:758) → panic("dma_buf_attach is not implemented") (dma-buf.h:129)

Guest proof (no GPU on the guest — entry-level precondition documented)

drm.ko built from the guest's /usr/src and loaded; KLD executes steps 3-5 with the real module symbols. Observed (run.log, panic.txt):

dma_buf_attach: stub
df4515mod: [6] dma_buf_attach -> 0 IS_ERR=0            <- NULL, IS_ERR blind (drm_prime.c:734)
dma_buf_map_attachment: stub
df4515mod: [6] dma_buf_map_attachment -> -22           <- -EINVAL (linux_dma-buf.c:196)
df4515mod: [6] goto fail_detach -> dma_buf_detach (drm_prime.c:758): expect panic
panic: dma_buf_attach is not implemented
sysctl_fire() <- sysctl_root() <- userland_sysctl() <- sys___sysctl() <- syscall2()

Deterministic; reproduced first try.

Reachability

• radeon: .gem_prime_import = drm_gem_prime_import (radeon_drv.c:699) — direct.
• amdgpu: amdgpu_gem_prime_import falls through to drm_gem_prime_import for any non-self dmabuf (amdgpu_prime.c:445-458).
• Trigger requires two DRM devices (export on A, import into B) — e.g. any hybrid i915+radeon/amdgpu laptop or dual-GPU box, or a foreign exporter appearing later. Single-GPU self-import takes the early-return path (drm_prime.c:718-728) and does not reach the stub.
• i915's own import (i915_gem_dmabuf.c:284-334) dodges the panic (#if 0 around its fail_detach) but instead succeeds with import_attach == NULL and no dma_buf reference — a zombie object whose first page-fetch fails; separate defect, same root.

Fix validation

fix.diff (dma-buf.h): dma_buf_attach returns ERR_PTR(-ENOSYS) (caught by the existing IS_ERR at drm_prime.c:734 → clean -ENOSYS ioctl failure) and dma_buf_detach no longer panics. Applied to guest /usr/src, rebuilt, re-run (fix_run.log):

dma_buf_attach: not implemented
df4515mod: [6] dma_buf_attach -> 0xffffffffffffffb2 IS_ERR=1      <- caught, no panic

Guest kept running. fix_status = fixed.

References

sys/dev/drm/drm_prime.c:709-762 (:733, :734, :739, :742-743, :758) sys/dev/drm/include/linux/dma-buf.h:96-101 (NULL stub), :125-130 (panic stub) sys/dev/drm/linux_dma-buf.c:189-207 (map_attachment EINVAL on NULL attach) sys/dev/drm/radeon/radeon_drv.c:699, sys/dev/drm/amd/amdgpu/amdgpu_prime.c:445-458, sys/dev/drm/amd/amdgpu/amdgpu_drv.c:1328 (generic import wiring)

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.