linux-kernel - Re: UBSAN: shift-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1f8a360d-89ea-4621-9e48-a20e2c42193b@redhat.com>
Date: Sat, 13 Dec 2025 21:18:10 +0100
From: Zdenek Kabelac <zkabelac@...hat.com>
To: imre.deak@...el.com
Cc: LKML <linux-kernel@...r.kernel.org>
Subject: Re: UBSAN: shift-out-of-bounds in
 drivers/gpu/drm/display/drm_dp_mst_topology.c:4575:36

Dne 12. 12. 25 v 20:14 Imre Deak napsal(a):
> Hi,
> 
> On Fri, Dec 12, 2025 at 07:55:12PM +0100, Zdenek Kabelac wrote:
>> Hi
>>
>> I've noticed this in my message log while suspending my P1 machine
>> (and unplugging it from my docking station).
>>
>> ----
>> kernel: UBSAN: shift-out-of-bounds in
>> drivers/gpu/drm/display/drm_dp_mst_topology.c:4575:36
>> kernel: shift exponent -1 is negative
>>
>> My laptop: ThinkPad P16v Gen 1, 64G RAM, 16 AMD Cores
> 
> The WARN itself should be removed by
> https://lore.kernel.org/all/20251119094650.799135-1-suraj.kandpal@intel.com
> 
> however, the above fix doesn't have other effects besides removing the
> WARN message/stack trace, so the slow-down you describe must have a
> differrent root cause than using a -1 as a shift value above. A wild
> guess is that it's some timeout trying to access the sink (which is
> inaccissible because the sink was unplugged) and the corresponding MST
> timeout being rather long (up to 4 sec per MST programming step).
> 
> I'd suggest opening an AMD DRM driver ticket to get a better idea,
> attaching there a dmesg log taken after booting with debug enabled (at
> least adding the drm.debug=0x15e kernel param) and reproducing the
> problem.


Ok - I think I've found matching symptoms in this thread:

https://discussion.fedoraproject.org/t/f41-is-sluggish-after-resuming-from-suspend-fixed-by-a-restart/147352/2

I guess I need to start to 'think' when I plug & unplug cables from the laptop 
before suspend...

Regards

Zdenek