610.57.04: NULL deref in nvDPLibSetAdaptiveSync (nvDisableVrr) on modeset after DP hot-replug through Thunderbolt dock

Start with src/nvidia-modeset/src/dp/nvdp-device.cpp and trace how DisplayPort::Group::enumDevices() and destruction of DisplayPort::Device interact during DisplayPort hot-unplug and Thunderbolt host resets. Review the promised bug report attachment and compare behavior around nvDPLibSetAdaptiveSync() with the surrounding DisplayPort device lifecycle code. Done means the stale or destroyed device cannot remain enumerable for a later modeset, supported by a repeatable hot-replug regression test or a narrowly justified lifecycle fix.

NVIDIA Open GPU Kernel Modules Version

610.57.04 (Arch nvidia-open-dkms 610.57.04-1)

Please confirm this issue does not happen with the proprietary driver (of the same version)

I can't test this. The GPU is a GB205 (RTX 5070 Ti Laptop), which only the open kernel modules support.

Operating System and Version

Arch Linux (Omarchy 4.0.4)

Kernel Release

Linux 7.2.5-3-omarchy #1 SMP PREEMPT_DYNAMIC Mon, 14 Sep 2026 19:55:01 +0000 x86_64 GNU/Linux. Distribution kernel, stable release.

Hardware: GPU

GPU 0: NVIDIA GeForce RTX 5070 Ti Laptop GPU (10de:2f58), hybrid with Intel Arrow Lake-S iGPU (8086:7d67). ASUS ROG Strix G16 G615LR, BIOS G615LR.331.

Describe the bug

An atomic modeset oopses in nvDPLibSetAdaptiveSync() with a NULL dereference. It happens on a DisplayPort head whose sink has been hot-unplugged and replugged several times through a Thunderbolt dock.

Oops: general protection fault, kernel NULL pointer dereference 0x140: 0000 [#1] SMP NOPTI
CPU: 15 UID: 1000 PID: 3210 Comm: Hyprland Tainted: G           OE       7.2.5-3-omarchy #1 PREEMPT(full)
Hardware name: ASUSTeK COMPUTER INC. ROG Strix G16 G615LR_G615LR/G615LR, BIOS G615LR.331 11/19/2025
RIP: 0010:nvDPLibSetAdaptiveSync+0x69/0xb0 [nvidia_modeset]
Code: 2e 2e 2e ff d0 48 85 c0 74 4b 45 84 e4 48 89 1c 24 48 89 c3 41 0f 95 c4 45 0f b6 e4 0f 1f 44 00 00 48 8b 03 48 89 df 44 89 e6 <48> 8b 80 40 01 00 00 2e 2e 2e ff d0 48 8b 45 00 48 89 de 48 89 ef
RAX: 0000000000000000 RBX: ffff89c0ca1ba008 RCX: 0000000000000001
RDX: ffff89c0de1f53c8 RSI: 0000000000000000 RDI: ffff89c0ca1ba008
Call Trace:
 nvDisableVrr+0x329/0x360 [nvidia_modeset]
 nvSetDispModeEvo+0x2e7c/0x4260 [nvidia_modeset]
 nvKmsIoctl+0x123/0x300 [nvidia_modeset]
 nvkms_ioctl_from_kapi_try_pmlock+0x68/0xb0 [nvidia_modeset]
 ApplyModeSetConfig+0x169/0xda0 [nvidia_modeset]
 nv_drm_atomic_apply_modeset_config+0x57d/0x8d0 [nvidia_drm]
 nv_drm_atomic_commit+0x266/0x5c0 [nvidia_drm]
 drm_atomic_commit+0xb1/0xf0
 drm_mode_atomic_ioctl+0xbfb/0xe50
 drm_ioctl_kernel+0xb6/0x110
 drm_ioctl+0x2e9/0x550
 __x64_sys_ioctl+0xc1/0x110
 do_syscall_64+0xaa/0x690
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

At the faulting instruction, RBX is the DisplayPort::Device * returned by pGroup->enumDevices(). Its first quadword (the vtable pointer) is 0 (mov rax,[rbx] gives RAX=0), so the virtual call dev->setIgnoreMSAEnable(enable) reads [0x0 + 0x140]. In 610.57.04 src/nvidia-modeset/src/dp/nvdp-device.cpp:

void nvDPLibSetAdaptiveSync(const NVDispEvoRec *pDispEvo, NvU32 head, NvBool enable)
{
    ...
    DisplayPort::Group *pGroup = pDpLibConnector->pGroup[head];
    for (dev = pGroup->enumDevices(0); dev != NULL; dev = pGroup->enumDevices(dev)) {
        dev->setIgnoreMSAEnable(enable);
    }
}

So the head's DP group still enumerates a Device that looks already destroyed (zeroed vtable), most likely the sink lost in the earlier hot-unplug. The process doing the modeset (the Wayland compositor) dies with it.

To Reproduce

Topology: two 3840x2160@120 DP monitors (Dell S2725QS) behind a Thunderbolt 5 dock (Ugreen U712, host controller Intel JHL9580). Each monitor has its own DP tunnel and lands on the NVIDIA GPU as DP-1/DP-2. A KVM sits between the dock and the monitors. The compositor is Hyprland 0.56.2 with aquamarine 0.15.0 and renders on the Intel iGPU.

What led up to the oops, in order:

1. The Thunderbolt link to the dock dropped and came back several times during normal use. One time the host could not rebuild the tunnels (DP tunnel activation failed, aborting), and afterwards card0-DP-2/status stayed connected with nothing attached.
2. The host router was reset (PCI remove/rescan of the NHI) with the dock unplugged, and the dock reconnected. Both monitors came back.
3. One monitor was power-cycled with its button, which triggered a DP hot-unplug and hot-plug through the dock.
4. A runtime mode change on that monitor (3840x2160@120 → @60) produced the oops above.

This happened once. The compositor-side bug that kept the output in this state (hyprwm/aquamarine#391) is now fixed locally, so I can't easily put the driver back into that state. I'm filing so the NULL vtable in the group's device list can be looked at from the trace.

Bug Incidence

Once

nvidia-bug-report.log.gz

Will be attached in a follow-up comment. It's from a later boot; the oops boot's kernel log is quoted above.

More Info

Expected: a modeset on a head whose DP sink was replugged either succeeds or fails cleanly, and never dereferences a destroyed DisplayPort::Device.

nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device DP-0 is logged at every boot on this machine. Thunderbolt was booted with thunderbolt.clx=0 only after this event, so it was not in effect at the time.