This is a note to let you know that I've just added the patch titled
net: rfkill: reduce data->mtx scope in rfkill_fop_open
to the 6.5-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
net-rfkill-reduce-data-mtx-scope-in-rfkill_fop_open.patch
and it can be found in the queue-6.5 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From f2ac54ebf85615a6d78f5eb213a8bbeeb17ebe5d Mon Sep 17 00:00:00 2001
From: Johannes Berg <johannes.berg@xxxxxxxxx>
Date: Wed, 11 Oct 2023 16:55:10 +0200
Subject: net: rfkill: reduce data->mtx scope in rfkill_fop_open
From: Johannes Berg <johannes.berg@xxxxxxxxx>
commit f2ac54ebf85615a6d78f5eb213a8bbeeb17ebe5d upstream.
In syzbot runs, lockdep reports that there's a (potential)
deadlock here of data->mtx being locked recursively. This
isn't really a deadlock since they are different instances,
but lockdep cannot know, and teaching it would be far more
difficult than other fixes.
At the same time we don't even really _need_ the mutex to
be locked in rfkill_fop_open(), since we're modifying only
a completely fresh instance of 'data' (struct rfkill_data)
that's not yet added to the global list.
However, to avoid any reordering etc. within the globally
locked section, and to make the code look more symmetric,
we should still lock the data->events list manipulation,
but also need to lock _only_ that. So do that.
Reported-by: syzbot+509238e523e032442b80@xxxxxxxxxxxxxxxxxxxxxxxxx
Fixes: 2c3dfba4cf84 ("rfkill: sync before userspace visibility/changes")
Signed-off-by: Johannes Berg <johannes.berg@xxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
net/rfkill/core.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -1180,7 +1180,6 @@ static int rfkill_fop_open(struct inode
init_waitqueue_head(&data->read_wait);
mutex_lock(&rfkill_global_mutex);
- mutex_lock(&data->mtx);
/*
* start getting events from elsewhere but hold mtx to get
* startup events added first
@@ -1192,10 +1191,11 @@ static int rfkill_fop_open(struct inode
goto free;
rfkill_sync(rfkill);
rfkill_fill_event(&ev->ev, rfkill, RFKILL_OP_ADD);
+ mutex_lock(&data->mtx);
list_add_tail(&ev->list, &data->events);
+ mutex_unlock(&data->mtx);
}
list_add(&data->list, &rfkill_fds);
- mutex_unlock(&data->mtx);
mutex_unlock(&rfkill_global_mutex);
file->private_data = data;
@@ -1203,7 +1203,6 @@ static int rfkill_fop_open(struct inode
return stream_open(inode, file);
free:
- mutex_unlock(&data->mtx);
mutex_unlock(&rfkill_global_mutex);
mutex_destroy(&data->mtx);
list_for_each_entry_safe(ev, tmp, &data->events, list)
Patches currently in stable-queue which might be from johannes.berg@xxxxxxxxx are
queue-6.5/wifi-cfg80211-validate-ap-phy-operation-before-start.patch
queue-6.5/wifi-mac80211-allow-transmitting-eapol-frames-with-t.patch
queue-6.5/wifi-cfg80211-use-system_unbound_wq-for-wiphy-work.patch
queue-6.5/net-rfkill-gpio-prevent-value-glitch-during-probe.patch
queue-6.5/rfkill-sync-before-userspace-visibility-changes.patch
queue-6.5/wifi-cfg80211-avoid-leaking-stack-data-into-trace.patch
queue-6.5/wifi-cfg80211-fix-6ghz-scan-configuration.patch
queue-6.5/net-rfkill-reduce-data-mtx-scope-in-rfkill_fop_open.patch
queue-6.5/wifi-iwlwifi-ensure-ack-flag-is-properly-cleared.patch
queue-6.5/wifi-mac80211-work-around-cisco-ap-9115-vht-mpdu-len.patch
