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 15E171D0405; Wed, 20 Nov 2024 14:08:12 +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=1732111693; cv=none; b=Njz18i5mO6JAEeWctwnVyi7+Po/YW2U/zFXkuXbbwW/qdbqec7lmZtqZ7vknx6SwQDqbZhiyT6tqMxH6A7ds3iPUIdVsPKLhzuvsirvkUySz4zVCuc1cY1zh1Z0SMd8C+TFKxRBLqShuiLaI1p3xzOpLMnQXgh820sW4tvkgA6A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732111693; c=relaxed/simple; bh=JT2FR6+7NlnG37gSDA+ptlnCmOYOpjFXTLpyD+BD84Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PTof5gchUPvswXNp5SgPj7Zmv0HiFpUO4FDleDZFSO8cU3NsTRkxeM+xkgVqEL1+0G0mGbvhxJ3VoUxo9FzEdZrMCpSWosNQXNPbHy+rtxkMucH5t42ZoC7Im0IU1lRKq3Skb+L4A6nB7zMM1smaF2a54H6VMlAW2heo46r/Fyo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MWrnd5xQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MWrnd5xQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 859C4C4CECE; Wed, 20 Nov 2024 14:08:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1732111692; bh=JT2FR6+7NlnG37gSDA+ptlnCmOYOpjFXTLpyD+BD84Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MWrnd5xQQmm3zC3Gq0bXGdjR/KNoOyClXWZrIxB4YvyGXTIvtFyax52lXwCePPnDW TVqkesh4s3xRd2pJ/ZvHXOsC7z/iXSDeuKrLh8BDEe5gWaRM/ajcm4vrT1HkhC+le7 rfLe3A0x4Xla4nn9tEyMFBo0yNqxs/ccutiF9ry1DSEJkhYbTryIEVRiLfJUdt5Z/W d4WGIl0foXBROT6z1G/NqYiB2ieLZSY2tbljVguDI9swjM4DLSnCuSxlLY4gMXSNJi kXxym3+fGe7tlWXASvOPbHyo8xFfb0wQI6kyOJhGOjn8N8MCsJClbyqRDkxOz6ckBf fMb0sSGbhdB9Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Breno Leitao , David Ahern , Jakub Kicinski , Sasha Levin , davem@davemloft.net, edumazet@google.com, pabeni@redhat.com, netdev@vger.kernel.org Subject: [PATCH AUTOSEL 5.15 4/4] ipmr: Fix access to mfc_cache_list without lock held Date: Wed, 20 Nov 2024 09:07:47 -0500 Message-ID: <20241120140758.1769473-4-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241120140758.1769473-1-sashal@kernel.org> References: <20241120140758.1769473-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 5.15.173 Content-Transfer-Encoding: 8bit From: Breno Leitao [ Upstream commit e28acc9c1ccfcb24c08e020828f69d0a915b06ae ] Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb #33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao Reviewed-by: David Ahern Link: https://patch.msgid.link/20241108-ipmr_rcu-v2-1-c718998e209b@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- net/ipv4/ipmr_base.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/ipv4/ipmr_base.c b/net/ipv4/ipmr_base.c index aa8738a91210a..c45cb7cb57590 100644 --- a/net/ipv4/ipmr_base.c +++ b/net/ipv4/ipmr_base.c @@ -301,7 +301,8 @@ int mr_table_dump(struct mr_table *mrt, struct sk_buff *skb, if (filter->filter_set) flags |= NLM_F_DUMP_FILTERED; - list_for_each_entry_rcu(mfc, &mrt->mfc_cache_list, list) { + list_for_each_entry_rcu(mfc, &mrt->mfc_cache_list, list, + lockdep_rtnl_is_held()) { if (e < s_e) goto next_entry; if (filter->dev && -- 2.43.0