Public bug reported:
## [ 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.
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.
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`).
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.
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).
**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
- 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.
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.
- 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.
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
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.
- 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.
** Affects: xorg-server (Ubuntu)
Importance: Undecided
Status: New
--
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
