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

From: Waiman Long <longman@redhat.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
	Boqun Feng <boqun.feng@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [lockdep] UAF read in print_name().
Date: Tue, 28 Dec 2021 22:25:02 -0500	[thread overview]
Message-ID: <015af849-3571-e9ac-692f-d803aa19f566@redhat.com> (raw)
In-Reply-To: <77f05c15-81b6-bddd-9650-80d5f23fe330@i-love.sakura.ne.jp>

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