linux-kernel - Re: [lockdep] UAF read in print

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 28 Dec 2021 22:25:02 -0500
From:   Waiman Long <longman@...hat.com>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
        Boqun Feng <boqun.feng@...il.com>
Cc:     LKML <linux-kernel@...r.kernel.org>
Subject: Re: [lockdep] UAF read in print_name().

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