On Mon, Nov 25, 2024 at 11:06:38AM +0100, Thomas Hellström wrote:
On Sun, 2024-11-24 at 07:46 -0500, Sasha Levin wrote:
From: Thomas Hellström <thomas.hellstrom@xxxxxxxxxxxxxxx>
[ Upstream commit 823a566221a5639f6c69424897218e5d6431a970 ]
When using mutex_acquire_nest() with a nest_lock, lockdep refcounts
the
number of acquired lockdep_maps of mutexes of the same class, and
also
keeps a pointer to the first acquired lockdep_map of a class. That
pointer
is then used for various comparison-, printing- and checking
purposes,
but there is no mechanism to actively ensure that lockdep_map stays
in
memory. Instead, a warning is printed if the lockdep_map is freed and
there are still held locks of the same lock class, even if the
lockdep_map
itself has been released.
In the context of WW/WD transactions that means that if a user
unlocks
and frees a ww_mutex from within an ongoing ww transaction, and that
mutex happens to be the first ww_mutex grabbed in the transaction,
such a warning is printed and there might be a risk of a UAF.
Note that this is only problem when lockdep is enabled and affects
only
dereferences of struct lockdep_map.
Adjust to this by adding a fake lockdep_map to the acquired context
and
make sure it is the first acquired lockdep map of the associated
ww_mutex class. Then hold it for the duration of the WW/WD
transaction.
This has the side effect that trying to lock a ww mutex *without* a
ww_acquire_context but where a such context has been acquire, we'd
see
a lockdep splat. The test-ww_mutex.c selftest attempts to do that, so
modify that particular test to not acquire a ww_acquire_context if it
is not going to be used.
Signed-off-by: Thomas Hellström <thomas.hellstrom@xxxxxxxxxxxxxxx>
Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
Link:
https://lkml.kernel.org/r/20241009092031.6356-1-thomas.hellstrom@xxxxxxxxxxxxxxx
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
It looks like the last version was not picked for this patch.
https://lore.kernel.org/all/172918113162.1279674.6570518059490493206@2413ebb6fbb6/T/
The version in this autosel patch regresses the locking api selftests
and should not be backported. Same for the corresponding backports for
6.11 and 6.6. Let me know if I should reply separately to those.
This is what ended up landing upstream...
I can drop it from the autosel queue, but if this has issues then you
should also fix it up upstream.
--
Thanks,
Sasha
