Patch "ipmr: Fix access to mfc_cache_list without lock held" has been added to the 6.11-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    ipmr: Fix access to mfc_cache_list without lock held

to the 6.11-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:
     ipmr-fix-access-to-mfc_cache_list-without-lock-held.patch
and it can be found in the queue-6.11 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 9ce9ccc5d7cda0a9dd4d08f716c78b8683457e1f
Author: Breno Leitao <leitao@xxxxxxxxxx>
Date:   Fri Nov 8 06:08:36 2024 -0800

    ipmr: Fix access to mfc_cache_list without lock held
    
    [ 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 <leitao@xxxxxxxxxx>
    Reviewed-by: David Ahern <dsahern@xxxxxxxxxx>
    Link: https://patch.msgid.link/20241108-ipmr_rcu-v2-1-c718998e209b@xxxxxxxxxx
    Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/net/ipv4/ipmr_base.c b/net/ipv4/ipmr_base.c
index 271dc03fc6dbd..f0af12a2f70bc 100644
--- a/net/ipv4/ipmr_base.c
+++ b/net/ipv4/ipmr_base.c
@@ -310,7 +310,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 &&




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux