Pi 5: NULL deref oops in dma_direct_unmap_sg via drm_gem_prime_fd_to_handle error path during HDMI hotplug (6.18.34+rpt)

[serialseb]

Describe the bug

NULL pointer dereference (kernel Oops, [#1]) in dma_direct_unmap_sg, reached through the DRM PRIME import error/cleanup path (drm_gem_prime_import_dev → dma_buf_unmap_attachment_unlocked → drm_gem_unmap_dma_buf), when a userspace process calls DRM_IOCTL_PRIME_FD_TO_HANDLE concurrently with an HDMI hotplug disconnect. The faulting process (a Chromium-family "Renderer") is killed mid-ioctl inside the DRM core; the X session never recovers (display and input dead, kernel otherwise healthy).

To reproduce

Not reliably reproducible on demand; observed when the attached TV dropped/re-asserted the HDMI link (TV auto-standby after DPMS off) at the same moment a browser renderer imported a dma-buf. The identical hotplug flap occurs several times a day here without harm — the oops needs the import call to race the disconnect.

Sequence observed in the log:

1. HDMI connector disconnect + immediate re-detect (EDID re-read succeeds, DDC then unresponsive — TV entering standby)
2. ~4 s later, a Renderer process issues DRM_IOCTL_PRIME_FD_TO_HANDLE
3. Oops below; the ioctl's error path unmaps an attachment whose sgt appears to be NULL

Expected behaviour

The PRIME import error path tolerates the connector going away; the ioctl fails cleanly instead of oopsing.

System

• Raspberry Pi 5 Model B Rev 1.1
• Debian trixie (arm64), X11/KDE session
• Kernel: 6.18.34+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.18.34-1+rpt1, 16k pages
• Display: LG 4K TV on HDMI-A-1 (vc4)

Oops

Unable to handle kernel NULL pointer dereference at virtual address 000000000000001c
Mem abort info:
  ESR = 0x0000000096000005
  EC = 0x25: DABT (current EL), IL = 32 bits
  SET = 0, FnV = 0
  EA = 0, S1PTW = 0
  FSC = 0x05: level 1 translation fault
Data abort info:
  ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
  CM = 0, WnR = 0, TnD = 0, TagAccess = 0
  GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
user pgtable: 16k pages, 47-bit VAs, pgdp=00000003aa0cc000
[000000000000001c] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
Internal error: Oops: 0000000096000005 [#1]  SMP
CPU: 0 UID: 1000 PID: 1274022 Comm: Renderer Tainted: G        W           6.18.34+rpt-rpi-2712 #1 PREEMPT  Debian 1:6.18.34-1+rpt1
Tainted: [W]=WARN
Hardware name: Raspberry Pi 5 Model B Rev 1.1 (DT)
pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : dma_direct_unmap_sg+0x84/0x260
lr : dma_unmap_sg_attrs+0x60/0x148
sp : ffffc0008fa63ac0
x29: ffffc0008fa63ac0 x28: ffffc0008fa63d08 x27: 0000000000000020
x26: 0000000000000000 x25: 0000000000000020 x24: ffff800002149010
x23: 0000000000000498 x22: 0000000000000000 x21: 0000000000000000
x20: ffff800002149010 x19: 0000000000000000 x18: 0000000000000000
x17: 0000000000000000 x16: ffffe2eeba37e008 x15: 00007fff0140bc68
x14: ffffffbfc0000000 x13: 0000000000000000 x12: 0000000000000000
x11: ffff80007ff7a980 x10: 0000000000000000 x9 : ffffe2eeba37e068
x8 : ffff8003956ea8c8 x7 : 0000000000000000 x6 : 000000000000003f
x5 : ffff800014172d80 x4 : 0000000000000020 x3 : 0000000000000000
x2 : 0000000000000498 x1 : 0000000000000000 x0 : ffff800002149010
Call trace:
 dma_direct_unmap_sg+0x84/0x260 (P)
 dma_unmap_sg_attrs+0x60/0x148
 drm_gem_unmap_dma_buf+0x38/0x68 [drm]
 dma_buf_unmap_attachment+0x3c/0xa0
 dma_buf_unmap_attachment_unlocked+0x58/0x98
 drm_gem_prime_import_dev+0x1a0/0x1e0 [drm]
 drm_gem_prime_fd_to_handle+0x1a8/0x280 [drm]
 drm_prime_fd_to_handle_ioctl+0x40/0x58 [drm]
 drm_ioctl_kernel+0xc8/0x140 [drm]
 drm_ioctl+0x368/0x4e8 [drm]
 __arm64_sys_ioctl+0xb4/0x120
 invoke_syscall+0x4c/0x100
 el0_svc_common.constprop.0+0xc8/0xf0
 do_el0_svc+0x24/0x38
 el0_svc+0x38/0x120
 el0t_64_sync_handler+0xa0/0xe8
 el0t_64_sync+0x198/0x1a0
Code: f240003f 9a931013 6b1602ff 540005a0 (b9401e61)
---[ end trace 0000000000000000 ]---

Additional context

Earlier in the same boot (~11 h before), a WARNING fired in vc4_hdmi_write_infoframe+0x3e0/0x470 [vc4] via drm_atomic_helper_connector_hdmi_update_audio_infoframe / vc4_hdmi_audio_prepare — also during an HDMI link event (that is the Tainted: W). Possibly the same underlying "HDMI went away mid-operation" class.

Happy to provide full logs or test patches.