From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3FC562EB5BA; Mon, 13 Apr 2026 16:16:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776097016; cv=none; b=DkkIhvKTtCK12lVnsewAzqR+w7IDgFQdknehLMGNrZ4VXKPoWLXCYp8ImX78a+2Sk1mRt18pGPUVaRi6c93Gj8DrrYPNnTzV7rUUBuYIEo/hHtc4LDOBH/7QC7nG5szkXF4228iQiAyJr5hGbAZ4uR4PndTgm4Ha+9H+wF3TgQo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776097016; c=relaxed/simple; bh=izlEYu/XSHicefaCzr8JkBcitGo5DNNzj2y6/LMOYNU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IIgb0m5zjhsmyfbrJf2ZHl++0ligbR32PR2XncsC82J+SE7NzzuFrzOuE829lYVluLPX8nEIXs4v07syy7vXy/YqS9Wo66gpH68Nyvk1tuD7/hTVcEVngcSusGsgHdt+ck4KWNIYhYcphZOWelYxzjpU7vFgQPVJTzwRgYpwg4o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=VKRQRYpx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="VKRQRYpx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9B69C2BCAF; Mon, 13 Apr 2026 16:16:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1776097016; bh=izlEYu/XSHicefaCzr8JkBcitGo5DNNzj2y6/LMOYNU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VKRQRYpx9dDbqVp13qRvvwBdF0s5KReAg67ZMmXkrjHSnihvhrALMlkfhZrFOlmh1 yJ6PaLM2tORqKI4JEerp5nIDtcEBCzTYDjCs67oSdCY7wcaokEbX4XzTMLg9Tdd2I9 joYptTy9qeNRxoXUQkVxLltuSoN5yodRN+0L+PCs= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, syzbot+509238e523e032442b80@syzkaller.appspotmail.com, Johannes Berg , Sasha Levin Subject: [PATCH 6.1 30/55] net: rfkill: reduce data->mtx scope in rfkill_fop_open Date: Mon, 13 Apr 2026 18:01:04 +0200 Message-ID: <20260413155725.959863286@linuxfoundation.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260413155724.820472494@linuxfoundation.org> References: <20260413155724.820472494@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.1-stable review patch. If anyone has any objections, please let me know. ------------------ From: Johannes Berg [ 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 Stable-dep-of: ea245d78dec5 ("net: rfkill: prevent unlimited numbers of rfkill events from being created") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- 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)