lkml.org 
[lkml]   [2021]   [Dec]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [lockdep] UAF read in print_name().
From
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

\
 
 \ /
  Last update: 2021-12-29 04:26    [W:0.139 / U:1.656 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site