Re: [PATCH net-next v5 13/14] ip6_gre: add drop reasons to the transmit path

From: Anton Danilov

Date: Mon Oct 05 2026 - 13:54:43 EST


On Sun, Oct 04, 2026 at 09:00:50PM +0000, netdev-bot+sashiko@xxxxxxxxxx wrote:
> [Severity: Medium]
> This early check only covers packets without valid IPv6 metadata. What
> happens to an inner IPv6 packet from :: that does carry valid IPv6 TX
> metadata on a collect_md ip6gre or ip6gretap device?

...

> Would it make sense to guard the test in ip6gre_xmit_ipv6() (and in
> ip6_tnl_start_xmit()) with !t->parms.collect_md, as
> ip6erspan_tunnel_xmit() does?

The drop predates this series, as the review says. For collect_md
ip6gretap it is a bug: on an L2 tunnel, frames from :: 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).
I will send a fix for collect_md ip6gretap to net separately.

For the L3 devices, ip6gre and ip6tnl, I would keep the drop, as
sending a packet with an unspecified source there means forwarding it
(RFC 4291, section 2.5.2). What does not fit there is the reason, as
there is no loop. I will revisit it when I send the rest of this
series. As Ido suggested, patches 1-3 and 14 go out first as a separate
vxlan series, and the other patches follow once it is in.

pw-bot: cr

---

Anton Danilov