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