Re: [lockdep] UAF read in print_name().
From: Waiman Long
Date: Tue Dec 28 2021 - 22:25:09 EST
On 12/28/21 05:49, Tetsuo Handa wrote:
Hello.
I found using linux-next-20211210 that reading /proc/lockdep after lockdep splat
triggers UAF read access. I think this is a side effect of zapping dependency
information when loop driver's WQ is destroyed. You might want to xchg() the pointer
with a dummy struct containing a static string.
difference before lockdep splat and after lockdep splat
----------------------------------------
8635c8636
< ffff88811561cd28 OPS: 26 FD: 122 BD: 1 +.+.: (wq_completion)loop0
---
ffff88811561cd28 OPS: 31 FD: 439 BD: 1 +.+.: M>^MM-^AM-^HM-^?M-^?
Thanks for reporting.
Yes, listing locking classes by /proc/lockdep is racy as
all_lock_classes is accessed without lock protection. OTOH, we probably
can't fix this race as lock hold time will be too long for this case.
Atomically xchg the class name is a possible workaround, but we also
need to add additional checks as the iteration may also be redirected to
free_lock_classes leading to an endless iteration loop.
Cheers,
Longman