]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
net: rfkill: reduce data->mtx scope in rfkill_fop_open
authorJohannes Berg <johannes.berg@intel.com>
Sun, 12 Apr 2026 12:55:16 +0000 (08:55 -0400)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 18 Apr 2026 08:35:57 +0000 (10:35 +0200)
commitba8a5db665303e52920b4f672f79e017d60bce3d
tree5f2271bb4280f51347ac86dac5983323d538db7d
parentf147fc8326d73055989898b19a87477f0dcccf09
net: rfkill: reduce data->mtx scope in rfkill_fop_open

[ Upstream commit f2ac54ebf85615a6d78f5eb213a8bbeeb17ebe5d ]

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@syzkaller.appspotmail.com
Fixes: 2c3dfba4cf84 ("rfkill: sync before userspace visibility/changes")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Stable-dep-of: ea245d78dec5 ("net: rfkill: prevent unlimited numbers of rfkill events from being created")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net/rfkill/core.c