ipv6: ip6mr: Call ip6mr_fib_lookup() under RCU in pim6_rcv() and reg_vif6_xmit()

ipv6: ip6mr: Call ip6mr_fib_lookup() under RCU in pim6_rcv() and reg_vif6_xmit()

[y2k]

Commit 019c892e4654 ("ipmr: Call ipmr_fib_lookup() under RCU.") fixed
the same issue in IPv4's reg_vif_xmit(). The IPv6 counterpart has the
same problem in two places.

In pim6_rcv() (net/ipv6/ip6mr.c:578) and reg_vif6_xmit()
(net/ipv6/ip6mr.c:624), ip6mr_fib_lookup() is called without holding
rcu_read_lock().

When CONFIG_IP6_MROUTE_MULTIPLE_TABLES=n, ip6mr_fib_lookup() accesses
net->ipv6.mrt6 directly without rcu_dereference(), while the IPv4
equivalent correctly uses rcu_dereference(net->ipv4.mrt). This
inconsistency means IPv6 multicast routing lacks proper RCU protection.

In reg_vif6_xmit(), rcu_read_lock() is acquired at line 628 after the
ip6mr_fib_lookup() call at line 624 — too late. In pim6_rcv(), there
is no rcu_read_lock() before ip6mr_fib_lookup() at line 578 at all.

Suggested fix for reg_vif6_xmit():

  + rcu_read_lock();
    if (ip6mr_fib_lookup(net, &fl6, &mrt) < 0) {
  +   rcu_read_unlock();
      goto tx_err;
    }
    DEV_STATS_ADD(dev, tx_bytes, skb->len);
    DEV_STATS_INC(dev, tx_packets);
  - rcu_read_lock();
    ip6mr_cache_report(mrt, skb, READ_ONCE(mrt->mroute_reg_vif_num),
                       MRT6MSG_WHOLEPKT);
    rcu_read_unlock();

Suggested fix for pim6_rcv():

  + rcu_read_lock();
    if (ip6mr_fib_lookup(net, &fl6, &mrt) < 0) {
  +   rcu_read_unlock();
      goto drop;
    }

Additionally, net->ipv6.mrt6 should be accessed via rcu_dereference()
in ip6mr_fib_lookup() to match the IPv4 pattern in ipmr_fib_lookup().

Thanks,
y2k
y2k@desarrollaria.com

Re: ipv6: ip6mr: Call ip6mr_fib_lookup() under RCU in pim6_rcv() and reg_vif6_xmit()

[Kuniyuki Iwashima]

From: y2k <y2k@desarrollaria.com>
Date: Fri, 08 May 2026 13:21:21 +0200
> Commit 019c892e4654 ("ipmr: Call ipmr_fib_lookup() under RCU.") fixed
> the same issue in IPv4's reg_vif_xmit(). The IPv6 counterpart has the
> same problem in two places.

No.

The change is just for rcu_dereference() added in the commit below
for ->exit_rtnl() conversion, but IP6MR is not yet converted.

---8<---
commit b3b6babf47517fde6b6de2493dea28e8831b9347
Author: Kuniyuki Iwashima <kuniyu@google.com>
Date:   Thu Apr 23 05:34:54 2026

    ipmr: Free mr_table after RCU grace period.
...
    Note that IP6MR is not yet converted to ->exit_rtnl(), so this
    change is not needed for now but will be.
---8<---


> 
> In pim6_rcv() (net/ipv6/ip6mr.c:578) and reg_vif6_xmit()
> (net/ipv6/ip6mr.c:624), ip6mr_fib_lookup() is called without holding
> rcu_read_lock().
> 
> When CONFIG_IP6_MROUTE_MULTIPLE_TABLES=n, ip6mr_fib_lookup() accesses
> net->ipv6.mrt6 directly without rcu_dereference(), while the IPv4
> equivalent correctly uses rcu_dereference(net->ipv4.mrt). This
> inconsistency means IPv6 multicast routing lacks proper RCU protection.
> 
> In reg_vif6_xmit(), rcu_read_lock() is acquired at line 628 after the
> ip6mr_fib_lookup() call at line 624 — too late. In pim6_rcv(), there
> is no rcu_read_lock() before ip6mr_fib_lookup() at line 578 at all.
> 
> Suggested fix for reg_vif6_xmit():
> 
>   + rcu_read_lock();
>     if (ip6mr_fib_lookup(net, &fl6, &mrt) < 0) {
>   +   rcu_read_unlock();
>       goto tx_err;
>     }
>     DEV_STATS_ADD(dev, tx_bytes, skb->len);
>     DEV_STATS_INC(dev, tx_packets);
>   - rcu_read_lock();
>     ip6mr_cache_report(mrt, skb, READ_ONCE(mrt->mroute_reg_vif_num),
>                        MRT6MSG_WHOLEPKT);
>     rcu_read_unlock();
> 
> Suggested fix for pim6_rcv():
> 
>   + rcu_read_lock();
>     if (ip6mr_fib_lookup(net, &fl6, &mrt) < 0) {
>   +   rcu_read_unlock();
>       goto drop;
>     }
> 
> Additionally, net->ipv6.mrt6 should be accessed via rcu_dereference()
> in ip6mr_fib_lookup() to match the IPv4 pattern in ipmr_fib_lookup().

Re: ipv6: ip6mr: Call ip6mr_fib_lookup() under RCU in pim6_rcv() and reg_vif6_xmit()

[y2k]

Thank you for the clarification. I missed that IP6MR is not yet
converted to ->exit_rtnl() and therefore does not need this change.

I appreciate the quick response.

y2k