Re: [PATCH v6 00/16] locking/lockdep: Add support for dynamic keys

[Bart Van Assche]

On Mon, 2019-01-14 at 13:52 +-0100, Peter Zijlstra wrote:
+AD4 On Fri, Jan 11, 2019 at 09:01:41AM -0800, Bart Van Assche wrote:
+AD4 +AD4 The list+AF8-del+AF8-rcu() call must only happen once. 
+AD4 
+AD4 Yes+ADs obviously. But if we need to check all +AEA-pf's, that means the entry
+AD4 is still reachable after a single reset+AF8-lock()/free+AF8-key+AF8-range(), which
+AD4 is a bug.
+AD4 
+AD4 +AD4 I ran into complaints reporting that
+AD4 +AD4 the list+AF8-del+AF8-rcu() call triggered list corruption. This change made these complaints
+AD4 +AD4 disappear.
+AD4 
+AD4 I'm saying this solution buggy, because that means the entry is still
+AD4 reachable after we do call+AF8-rcu() (which is a straight up UAF).
+AD4 
+AD4 Also put it differently, what guarantees checking those two +AEA-pf's is
+AD4 sufficient. Suppose your earlier +AEA-pf already did the RCU callback and
+AD4 freed stuff while the second is in progress. Then you're poking into
+AD4 dead space.

zap+AF8-class() only examines elements of the list+AF8-entries+AFsAXQ array for which the
corresponding bit in list+AF8-entries+AF8-in+AF8-use has been set. The RCU callback clears 
the bits in the list+AF8-entries+AF8-in+AF8-use that correspond to elements that have been
freed. The graph lock serializes zap+AF8-class() calls and the code inside the
RCU callback. So it's not clear to me why you are claiming that zap+AF8-class()
would trigger a use-after-free?

Bart.