PT-2026-61417 · Linux · Linux

CVE-2026-64100

·

Published

2026-07-19

·

Updated

2026-07-19

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
drm/msm: Fix shrinker deadlock
With PROVE LOCKING on an Snapdragon X1 and VM reclaim pressure, we see:

====================================================== WARNING: possible circular locking dependency detected 7.0.0-debug+ #43 Tainted: G W

kswapd0/82 is trying to acquire lock: ffff800080ec3870 (reservation ww class acquire){+.+.}-{0:0}, at: msm gem shrinker scan+0x17c/0x400 [msm]
but task is already holding lock: ffffc31709b263b8 (fs reclaim){+.+.}-{0:0}, at: balance pgdat+0x88/0x988
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (fs reclaim){+.+.}-{0:0}: lock acquire+0x4d0/0xad0 lock acquire.part.0+0xc4/0x248 lock acquire+0x8c/0x248 fs reclaim acquire+0xd0/0xf0 dma resv lockdep+0x224/0x348 do one initcall+0x84/0x5d0 do initcalls+0x194/0x1d8 kernel init freeable+0x128/0x180 kernel init+0x2c/0x160 ret from fork+0x10/0x20
-> #1 (reservation ww class mutex){+.+.}-{4:4}: lock acquire+0x4d0/0xad0 lock acquire.part.0+0xc4/0x248 lock acquire+0x8c/0x248 dma resv lockdep+0x1a8/0x348 do one initcall+0x84/0x5d0 do initcalls+0x194/0x1d8 kernel init freeable+0x128/0x180 kernel init+0x2c/0x160 ret from fork+0x10/0x20
-> #0 (reservation ww class acquire){+.+.}-{0:0}: check prev add+0x114/0x790 validate chain+0x594/0x6f0 lock acquire+0x4d0/0xad0 lock acquire.part.0+0xc4/0x248 lock acquire+0x8c/0x248 drm gem lru scan+0x1ac/0x440 msm gem shrinker scan+0x17c/0x400 [msm] do shrink slab+0x150/0x4a0 shrink slab+0x144/0x460 shrink one+0x9c/0x1b0 shrink many+0x27c/0x5c0 shrink node+0x344/0x550 balance pgdat+0x2c0/0x988 kswapd+0x11c/0x318 kthread+0x10c/0x128 ret from fork+0x10/0x20
other info that might help us debug this: Chain exists of: reservation ww class acquire --> reservation ww class mutex --> fs reclaim Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs reclaim); lock(reservation ww class mutex); lock(fs reclaim); lock(reservation ww class acquire);
*** DEADLOCK *** 1 lock held by kswapd0/82: #0: ffffc31709b263b8 (fs reclaim){+.+.}-{0:0}, at: balance pgdat+0x88/0x988
stack backtrace: CPU: 4 UID: 0 PID: 82 Comm: kswapd0 Tainted: G W 7.0.0-debug+ #43 PREEMPT(full) Tainted: [W]=WARN Hardware name: LENOVO 21BX0016US/21BX0016US, BIOS N3HET94W (1.66 ) 09/15/2025 Call trace: show stack+0x20/0x40 (C) dump stack lvl+0x9c/0xd0 dump stack+0x18/0x30 print circular bug+0x114/0x120 check noncircular+0x178/0x198 check prev add+0x114/0x790 validate chain+0x594/0x6f0 lock acquire+0x4d0/0xad0 lock acquire.part.0+0xc4/0x248 lock acquire+0x8c/0x248 drm gem lru scan+0x1ac/0x440 msm gem shrinker scan+0x17c/0x400 [msm] do shrink slab+0x150/0x4a0 shrink slab+0x144/0x460 shrink one+0x9c/0x1b0 shrink many+0x27c/0x5c0 shrink node+0x344/0x550 balance pgdat+0x2c0/0x988 kswapd+0x11c/0x318 kthread+0x10c/0x128 ret from fork+0x10/0x20
kswapd0 holding fs reclaim calls the MSM shrinker, which calls dma resv lock. This in turn acquires fs reclaim.
Fix this deadlock by using dma resv trylock() instead, dropping the subsequently unused passed wait-wound lock 'ticket'.
Patchwork: https://patchwork.freedesktop.org/patch/723564/ [rob: fixup compile errors, replace lockdep splat with somethin ---truncated---
Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Related Identifiers

CVE-2026-64100

Affected Products

Linux