quoted
When IPV6_MROUTE_MULTIPLE_TABLES is enabled, multicast routing tables
must be read under RCU or RTNL lock.
Fixes: d1db275dd3f6 ("ipv6: ip6mr: support multiple tables")
Signed-off-by: Stefan Wiehler <redacted>
---
net/ipv6/ip6mr.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index b169b27de7e1..39aac81a30f1 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -2633,27 +2633,31 @@ static int ip6mr_rtm_getroute(struct sk_buff *in_skb, struct nlmsghdr *nlh,
grp = nla_get_in6_addr(tb[RTA_DST]);
tableid = tb[RTA_TABLE] ? nla_get_u32(tb[RTA_TABLE]) : 0;
+ rcu_read_lock();
AFAICS ip6mr_rtm_getroute() runs with RTNL held, so I don't see
why this patch is needed.
That's true, but it's called neither with RCU nor RTNL lock when
RTNL_FLAG_DOIT_UNLOCKED is set in rtnetlink_rcv_msg():
if (flags & RTNL_FLAG_DOIT_UNLOCKED) {
doit = link->doit;
rcu_read_unlock();
if (doit)
err = doit(skb, nlh, extack);
module_put(owner);
return err;
}
rcu_read_unlock();
I realized now that I completely misunderstood how ip6mr_rtm_dumproute() gets
called - it should be still safe though because mpls_netconf_dump_devconf() and
getaddr_dumpit() hold the RCU lock while mpls_dump_routes() asserts that the
RTNL lock is held. Is that observation correct?