Re: [BUG] thunderbolt: NULL pointer dereference in tb_dp_dprx_work after device disconnect (7.2.6)

[Mika Westerberg <mika.westerberg@linux.intel.com>]

Hi,

Thanks for the report and good that the problem got fixed. These should
land on the v7.3-rcX still.

On Thu, Sep 24, 2026 at 06:28:34PM +0200, Paweł Frelek wrote:
> FWIW, this is addressed by Sven Peter's series "thunderbolt: Fix DP
> tunnel teardown while an async DPRX read is running", patches 1-6 of
> which are already in thunderbolt.git/fixes. I tested v3 on top of
> 7.2.6 on this machine (dock unplug/replug, reboots with the dock
> connected): no crashes or warnings.
> 
> Thanks,
> Paweł
> 
> wt., 22 wrz 2026 o 16:48 Paweł Frelek <pawel.frelek@gmail.com> napisał(a):
> >
> > Hi,
> >
> > I hit a NULL pointer dereference in tb_dp_dprx_work during reboot,
> > right after the dock was disconnected from the Thunderbolt bus.
> >
> > Hardware:
> > - Lenovo ThinkPad X13 Gen 3 AMD (21CNS15T00), BIOS R22ET81W (1.51)
> > - Lenovo ThinkPad Thunderbolt 4 Dock (40B0), external monitor over DP
> >
> > Kernel: 7.2.6-hardened1 (Arch linux-hardened), not tainted
> > Cmdline includes: thunderbolt.dprx_timeout=-1
> >
> > What happened:
> > The external DP monitor behind the dock did not come up at boot. I
> > unplugged and replugged the monitor's DP cable at the dock, without
> > success, then rebooted (the dock itself stayed connected). During
> > shutdown the dock was reported as disconnected and ~50 ms later the
> > pending DPRX work crashed:
> >
> > [  140.825070] thunderbolt 0-2: device disconnected
> > [  140.875648] BUG: kernel NULL pointer dereference, address: 000000000000032b
> > [  140.877281] CPU: 8 UID: 0 PID: 125 Comm: kworker/u48:4 Not tainted
> > 7.2.6-hardened1-1-hardened #1 PREEMPT(full)
> > [  140.877513] Hardware name: LENOVO 21CNS15T00/21CNS15T00, BIOS
> > R22ET81W (1.51 ) 04/10/2026
> > [  140.877748] Workqueue: thunderbolt0 tb_dp_dprx_work [thunderbolt]
> > [  140.878003] RIP: 0010:tb_dp_dprx_work+0x82/0x160 [thunderbolt]
> > [  140.880927] Call Trace:
> > [  140.881164]  <TASK>
> > [  140.881652]  process_one_work+0x198/0x370
> > [  140.881896]  worker_thread+0x1a6/0x310
> > [  140.882380]  kthread+0xf3/0x130
> > [  140.882863]  ret_from_fork+0x2dc/0x3a0
> > [  140.883818]  ret_from_fork_asm+0x1a/0x30
> > [  140.884065]  </TASK>
> > [  141.399331] Code: 24 20 48 8b 87 58 ff ff ff 48 8d b8 18 03 00 00
> > 49 89 c4 4c 8d b8 18 03 00 00 e8 39 ff db d3 48 8b 8b 60 ff ff ff 48
> > 8b 41 20 <0f> b6 90 2b 03 00 00 c0 ea 05 75 5d 66 81 b8 18 03 00 00 86
> > 80 74
> > [  141.399974] RAX: 0000000000000000 RBX: ffff88ae1389c4b0 RCX: ffff88b040d53578
> > [  141.400298] RDX: ffff88b0916f0000 RSI: ffff88ae1389c4b8 RDI: ffff88ae011a6318
> > [  141.402844] Kernel panic - not syncing: Fatal exception
> >
> > It looks like the DPRX work is not cancelled when the device behind the
> > tunnel goes away. With dprx_timeout=-1 the work never expires, which
> > makes the window large, but I assume the race exists with the default
> > timeout too.
> >
> > I set dprx_timeout=-1 because the external monitors sometimes did not
> > come up at boot (DP tunnel torn down as "not active").
> >
> > Full pstore dmesg available on request.
> >
> > Thanks,
> > Paweł
> >
> > --
> > Paweł Frelek   ( ͡° ͜ʖ ͡°)
> > pawel.frelek@gmail.com
> 
> 
> 
> -- 
> Paweł Frelek   ( ͡° ͜ʖ ͡°)
> pawel.frelek@gmail.com