Messages in this thread | | | Date | Tue, 28 Dec 2021 22:25:02 -0500 | Subject | Re: [lockdep] UAF read in print_name(). | From | Waiman Long <> |
| |
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
| |