** Description changed:

  ## [ Impact ]
  
  On Noble (xorg-server 21.1.12) the X server crashes with SIGSEGV when a
  modesetting *platform* GPU screen is added at runtime and later removed. This
  is reliably triggered by a DisplayLink adapter (the proprietary
  `DisplayLinkManager` adds/reconfigures an `evdi` platform DRM device at
  runtime, and udev tears it down again), but it is **not** 
DisplayLink-specific:
  any runtime-hotplugged modesetting platform-GPU screen that is later removed
  hits it.
  
  Two distinct NULL-pointer dereferences are involved, both on the same
  evdi add/remove flow:
  
  1. **`DGACloseScreen` -> NULL `SetDGAMode`.** `xf86platformAddDevice()` (the
-    runtime hotplug path) does not set the `EnableDisableFBAccess` / 
`SetDGAMode`
-    function-pointer defaults that the boot path (`xf86Init.c`) sets on every 
GPU
-    screen. DGA is still wrapped onto the screen via `xf86CrtcScreenInit()`, so
-    on teardown `DGACloseScreen()` calls through a NULL `SetDGAMode` and the
-    server aborts.
+    runtime hotplug path) does not set the `EnableDisableFBAccess` / 
`SetDGAMode`
+    function-pointer defaults that the boot path (`xf86Init.c`) sets on every 
GPU
+    screen. DGA is still wrapped onto the screen via `xf86CrtcScreenInit()`, so
+    on teardown `DGACloseScreen()` calls through a NULL `SetDGAMode` and the
+    server aborts.
  
  2. **`config_udev_get_fallback_bus_id` -> NULL subsystem into `strcmp`.**
-    For a DRM device with no udev `ID_PATH` (evdi cards qualify),
-    `udev_device_get_subsystem()` can return NULL, which is passed straight 
into
-    `strcmp(..., "pci")`, faulting.
+    For a DRM device with no udev `ID_PATH` (evdi cards qualify),
+    `udev_device_get_subsystem()` can return NULL, which is passed straight 
into
+    `strcmp(..., "pci")`, faulting.
  
  On the login screen this crashes the greeter Xorg on essentially every boot
  that has a DisplayLink dongle attached; lightdm respawns it, so it is
  "self-recovering but noisy" there, but it is a hard server SIGSEGV in the
  general case (a running session with a DisplayLink head is taken down).
  
  ## [ Test Plan ]
  
  The two fixes differ sharply in reproducibility, so they are verified
  differently. Test on a machine with a DisplayLink adapter (evdi) + a
  modesetting GPU.
  
  **Patch 1 (DGA, MR !2244) -- deterministic, directly demonstrable:**
  
  1. Install **stock** `xorg-server` from `-updates`. Attach a DisplayLink 
dongle
-    plus a monitor, then cold-boot (or `systemctl restart lightdm`). The 
greeter Xorg
-    SIGSEGVs on essentially every such boot:
-    `sudo coredumpctl list --since "$(who -b | awk '{print $3, $4}')" | grep 
-i Xorg`
-    shows a fresh Xorg core; symbolizing it (against the matching `1ubuntu1.x`
-    dbgsym) shows `DGACloseScreen` calling a NULL `SetDGAMode` on a `modeset` 
GPU
-    screen (`isGPU=1`).
+    plus a monitor, then cold-boot (or `systemctl restart lightdm`). The 
greeter Xorg
+    SIGSEGVs on essentially every such boot:
+    `sudo coredumpctl list --since "$(who -b | awk '{print $3, $4}')" | grep 
-i Xorg`
+    shows a fresh Xorg core; symbolizing it (against the matching `1ubuntu1.x`
+    dbgsym) shows `DGACloseScreen` calling a NULL `SetDGAMode` on a `modeset` 
GPU
+    screen (`isGPU=1`).
  2. Install the fixed `xorg-server` (`2:21.1.12-1ubuntu1.9`) from
-    `noble-proposed`; reboot with the dongle attached and repeat across several
-    boots plus a suspend/resume cycle.
+    `noble-proposed`; reboot with the dongle attached and repeat across several
+    boots plus a suspend/resume cycle.
  3. **Pass:** `Xorg.0.log` shows the same teardown (`config/udev: removing GPU
-    device .../evdi.0` -> `xf86: remove device N` -> `UnloadModule: 
modesetting`)
-    and there are **zero** new Xorg coredumps (baseline was ~one per boot).
+    device .../evdi.0` -> `xf86: remove device N` -> `UnloadModule: 
modesetting`)
+    and there are **zero** new Xorg coredumps (baseline was ~one per boot).
  
  **Patch 2 (udev, MR !2245) -- a teardown race, NOT reproducible on
  demand:**
  
  This crash cannot be triggered deterministically -- it requires the parent
  platform device's `subsystem` link to already be gone mid-`remove`, which does
  not happen under orderly sysfs add/remove and resisted repeated live
  dongle-unplug attempts. Its existence is established by a **dispositive
  symbolized coredump** (`rdi=0`, `rsi -> "pci"` in
  `config_udev_get_fallback_bus_id`). Verification therefore rests on inspection
  plus soak, not a before/after repro:
  
  - the fix is a minimal NULL-guard that can only *prevent* a NULL deref (it
-   changes nothing when the subsystem is non-NULL), matching the 2019 precedent
-   commit `429ee86a` that guarded the four sibling callers in the same file; 
and
+   changes nothing when the subsystem is non-NULL), matching the 2019 precedent
+   commit `429ee86a` that guarded the four sibling callers in the same file; 
and
  - the fixed build has been the reporter's daily driver for ~2 weeks of
-   DisplayLink add/remove (many boots + suspend/resume cycles), which exercises
-   this exact udev path, with **zero** `config_udev` coredumps.
+   DisplayLink add/remove (many boots + suspend/resume cycles), which exercises
+   this exact udev path, with **zero** `config_udev` coredumps.
  
  On-demand reproduction of a NULL-deref-on-a-race is impractical; this is 
called
  out explicitly so the SRU reviewer can weigh the inspection-plus-soak evidence
  rather than expect a stock repro. If a reviewer is uncomfortable verifying 
!2245
  this way, it can be split into its own bug/upload without holding up the
  fully-demonstrable DGA fix.
  
  ## [ Where problems could occur ]
  
  Both changes are tiny, upstream-reviewed, and merged to `xorg/xserver`
  master.
  
  - The DGA change adds two function-pointer assignments to the runtime
-   GPU-screen *add* path, mirroring exactly what the boot path already does for
-   every GPU screen. It only affects screens created by runtime platform-GPU
-   hotplug; single-GPU desktops and the boot path are unchanged.
+   GPU-screen *add* path, mirroring exactly what the boot path already does for
+   every GPU screen. It only affects screens created by runtime platform-GPU
+   hotplug; single-GPU desktops and the boot path are unchanged.
  - The udev change adds a NULL check before an existing `strcmp`. It can only
-   prevent a crash; it cannot change behaviour for a non-NULL subsystem.
+   prevent a crash; it cannot change behaviour for a non-NULL subsystem.
  
  Any regression would therefore be confined to the multi-GPU / DisplayLink /
  PRIME-offload platform-bus path. That path is exactly what is broken today, 
and
- the fixed build has been the reporter's daily driver for ~2 weeks (many
+ the fixed build has been my daily driver for ~3 weeks (many
  boot and suspend/resume cycles with a DisplayLink head attached) with zero
  recurrences and no new coredumps.
  
  ## [ Other Info ]
  
  - Upstream: MR !2244 (DGA, commit `dbcd36b`, merged 2026-07-13) and MR !2245
-   (udev, commit `9babe7e7`, merged 2026-07-01), freedesktop issues #1904 / 
#1905.
+   (udev, commit `9babe7e7`, merged 2026-07-01), freedesktop issues #1904 / 
#1905.
  - The two fixes cherry-pick cleanly onto 21.1.12; see the attached debdiff.
  - Resolute (26.04 / Mint 23) shipped 21.1.22 without these and needs the same
-   backport; nominate the Resolute series on this same bug (base `-1ubuntu1.2` 
->
-   `-1ubuntu1.3`). Ubuntu 26.04 removed the GNOME Xorg session entirely and
-   Xwayland is unaffected, so stock GNOME sees no impact -- but `xorg-server`
-   still serves the X11-session flavours (Kubuntu X11, Xubuntu, Ubuntu 
Cinnamon,
-   MATE) and the default Mint 23 (Cinnamon/X11) configuration, where 
NVIDIA-on-X11
-   users concentrate. The crash requires runtime GPU-screen hotplug (a 
DisplayLink
-   dock or eGPU) to fire.
+   backport; nominate the Resolute series on this same bug (base `-1ubuntu1.2` 
->
+   `-1ubuntu1.3`). Ubuntu 26.04 removed the GNOME Xorg session entirely and
+   Xwayland is unaffected, so stock GNOME sees no impact -- but `xorg-server`
+   still serves the X11-session flavours (Kubuntu X11, Xubuntu, Ubuntu 
Cinnamon,
+   MATE) and the default Mint 23 (Cinnamon/X11) configuration, where 
NVIDIA-on-X11
+   users concentrate. The crash requires runtime GPU-screen hotplug (a 
DisplayLink
+   dock or eGPU) to fire.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2160643

Title:
  xorg-server SIGSEGV on runtime GPU-screen (DisplayLink/evdi) hotplug
  -- NULL SetDGAMode and NULL udev subsystem

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/2160643/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to