Re: [lockdep] UAF read in print_name().

[Waiman Long <longman@redhat.com>]

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