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)

Ouverte
#7,504 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
45/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Calme
Stack technique
c, linux

Piste de recherche

Start with the reported call path from drm_gem_prime_fd_to_handle through drm_gem_prime_import_dev and dma_buf_unmap_attachment_unlocked to dma_direct_unmap_sg, then compare the HDMI hotplug and DRM cleanup paths. Reproduce, if possible, by racing DRM_IOCTL_PRIME_FD_TO_HANDLE with an HDMI disconnect and capture the cleanup state. Done means the import fails cleanly without a NULL dereference or display-session loss.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
C
Étoiles
13.3k
Forks
5.5k
Merge moyen
3 j 20 h
PR mergées (30 j)
27

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de raspberrypi/linux

Toutes les issues de raspberrypi/linux

Issues similaires

Plus d'issues C

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.