Messages in this thread | | | Subject | Re: [PATCH v6 00/16] locking/lockdep: Add support for dynamic keys | From | Bart Van Assche <> | Date | Mon, 14 Jan 2019 08:52:33 -0800 |
| |
On Mon, 2019-01-14 at 13:52 +0100, Peter Zijlstra wrote: > On Fri, Jan 11, 2019 at 09:01:41AM -0800, Bart Van Assche wrote: > > The list_del_rcu() call must only happen once. > > Yes; obviously. But if we need to check all @pf's, that means the entry > is still reachable after a single reset_lock()/free_key_range(), which > is a bug. > > > I ran into complaints reporting that > > the list_del_rcu() call triggered list corruption. This change made these complaints > > disappear. > > I'm saying this solution buggy, because that means the entry is still > reachable after we do call_rcu() (which is a straight up UAF). > > Also put it differently, what guarantees checking those two @pf's is > sufficient. Suppose your earlier @pf already did the RCU callback and > freed stuff while the second is in progress. Then you're poking into > dead space.
zap_class() only examines elements of the list_entries[] array for which the corresponding bit in list_entries_in_use has been set. The RCU callback clears the bits in the list_entries_in_use that correspond to elements that have been freed. The graph lock serializes zap_class() calls and the code inside the RCU callback. So it's not clear to me why you are claiming that zap_class() would trigger a use-after-free?
Bart.
| |