[PATCH net] ip6_gre: let collect_md ip6gretap send from the unspecified address

[PATCH net] ip6_gre: let collect_md ip6gretap send from the unspecified address

[Anton Danilov]

ip6gre_xmit_ipv6() drops an IPv6 packet whose source address equals the
tunnel remote, to avoid a trivial tunneling loop. On a collect_md
ip6gretap device t->parms.raddr is not the exit point: the outer
destination comes from the per-packet tunnel metadata. Such devices are
normally created without a remote, so raddr is ::, and the check never
matches a real tunnel endpoint. It matches every frame sent from the
unspecified address instead.

On an L2 tunnel those frames are regular link traffic. Duplicate Address
Detection sends its Neighbor Solicitations from :: (RFC 4862, section
5.4.2), and MLD reports are sent from :: while an interface has no
link-local address yet (RFC 3590, section 4). Frames bridged into a
collect_md ip6gretap device, e.g. with tc tunnel_key and mirred, are
dropped even though they carry valid metadata, so DAD cannot detect a
duplicate address on the other side of the tunnel.

Skip the check for collect_md devices of type ARPHRD_ETHER. It stays for
L3 ip6gre, where sending a packet with an unspecified source means
forwarding it (RFC 4291, section 2.5.2), and for ip6gretap without
collect_md. ip6erspan does not run this check in collect_md mode either.

Fixes: 6712abc168eb ("ip6_gre: add ip6 gre and gretap collect_md mode")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Anton Danilov <littlesmilingcloud@gmail.com>

---
 net/ipv6/ip6_gre.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index e61cb10b50dc..ba1ed459ee79 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -831,7 +831,12 @@ static inline int ip6gre_xmit_ipv6(struct sk_buff *skb, struct net_device *dev)
 	__u32 mtu;
 	int err;
 
-	if (ipv6_addr_equal(&t->parms.raddr, &ipv6h->saddr))
+	/* The outer destination of a collect_md tunnel comes from the
+	 * metadata, so raddr is not its exit point, and hosts on the link
+	 * bridged into an L2 one do send from :: (DAD, early MLD).
+	 */
+	if (!(t->parms.collect_md && dev->type == ARPHRD_ETHER) &&
+	    ipv6_addr_equal(&t->parms.raddr, &ipv6h->saddr))
 		return -1;
 
 	if (!t->parms.collect_md &&
-- 
2.47.3

Re: [PATCH net] ip6_gre: let collect_md ip6gretap send from the unspecified address

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net] ip6_gre: let collect_md ip6gretap send from the unspecified address

[Anton Danilov]

On Mon, Oct 05, 2026 at 07:20:34PM +0000, netdev-bot+sinfo@kernel.org wrote:
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
>
>  - How the issue was discovered, e.g. hit in production, hit during
>    development, syzbot report, manual code inspection, LLM or static
>    analysis tool scan.

Hit during development of the net-next series that annotates these
drivers with drop reasons. An LLM-assisted review of that series
flagged the misleading "dead loop" reason this check gives to frames
sent from :: when raddr is ::. Following that up with code inspection
and testing showed that for L2 collect_md devices the drop itself is
wrong, not just the label. The review of that series on the list asked
about the same case, and this fix was promised in the reply:

  https://lore.kernel.org/netdev/20261005174649.853236-1-littlesmilingcloud@gmail.com/

>  - Whether the issue was actually triggered, or is only theoretical
>    (e.g. found by code inspection). If it was triggered please include
>    the symptoms, like the stack trace or error messages.

Triggered deliberately in a test VM; this is not a production report.
There is no stack trace or log message: the frames are dropped
silently, and the loss only shows up in counters. With frames bridged
from a veth into a collect_md ip6gretap device by tc (flower +
tunnel_key set + mirred) over a dummy underlay, five DAD-style
Neighbor Solicitations sent from :: give tx_errors +5 and tx_dropped
+5 on the tunnel device, zero packets on the underlay, and five
kfree_skb events in ip6gre_tunnel_xmit() (reason NOT_SPECIFIED). The
same frames sent from a link-local address are transmitted. With the
patch applied the frames from :: are transmitted as well, while the
check still fires for native ip6gretap with a configured remote and
for L3 collect_md ip6gre; each half of the new condition was verified
by removing it in turn and watching the case it protects start passing
frames it must not.

---

Anton Danilov