[PATCH net] amt: do not offer software GSO on the amt device

[PATCH net] amt: do not offer software GSO on the amt device

[Omar Ramadan]

amt_link_setup() puts NETIF_F_GSO_SOFTWARE in the device features, so
the core hands amt_dev_xmit() a GSO skb unsegmented: a UDP_SEGMENT
sender, or a UDP packet GRO merged on a link with UDP GRO forwarding
or fraglist GRO, that is routed to the amt device. The relay copies
the skb for each tunnel in amt_send_multicast_data() and pushes the AMT
and outer headers, but it never marks the copy for UDP tunnel
segmentation, so skb->encapsulation stays clear and gso_type is still
the inner SKB_GSO_UDP_L4. When the outer IP layer segments it,
__udp_gso_segment() cuts the outer UDP payload at the inner gso_size:
the first segment carries the AMT header, the inner headers and part
of the data, and every later one carries raw inner payload behind a
new outer UDP header, which a gateway takes for a malformed AMT
message.

The amt device cannot offload segmentation to anything, so stop
offering it and let validate_xmit_skb() segment a GSO skb before
amt_dev_xmit() replicates it. Each gateway then gets one AMT message
per inner packet. Neither mode needs GSO: a gateway only sends IGMP
and MLD reports.

Fixes: cbc21dc1cfe9 ("amt: add data plane of amt interface")
Signed-off-by: Omar Ramadan <omar@blockcast.net>
---
 drivers/net/amt.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/amt.c b/drivers/net/amt.c
index bddc24e18..6eb148c9f 100644
--- a/drivers/net/amt.c
+++ b/drivers/net/amt.c
@@ -3155,10 +3155,8 @@ static void amt_link_setup(struct net_device *dev)
 	dev->priv_flags		|= IFF_NO_QUEUE;
 	dev->lltx		= true;
 	dev->netns_immutable	= true;
-	dev->features		|= NETIF_F_GSO_SOFTWARE;
 	dev->hw_features	|= NETIF_F_SG | NETIF_F_HW_CSUM;
 	dev->hw_features	|= NETIF_F_FRAGLIST | NETIF_F_RXCSUM;
-	dev->hw_features	|= NETIF_F_GSO_SOFTWARE;
 	dev->pcpu_stat_type	= NETDEV_PCPU_STAT_TSTATS;
 	eth_hw_addr_random(dev);
 	eth_zero_addr(dev->broadcast);

base-commit: a7bfaba4823e3c165bb2004c74eff7c096672bc7
-- 
2.47.3

Re: [PATCH net] amt: do not offer software GSO on the amt device

[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] amt: do not offer software GSO on the amt device

[Omar Ramadan]

Found by code inspection: an LLM-assisted review of drivers/net/amt.c
while I was working on an IPv6 outer transport for amt.

It has not been triggered. I have no reproducer, and I have not seen
it in production or in testing; it comes from reading the code. The
path is a GSO skb, for example from a UDP_SEGMENT sender or a GRO
merged UDP flow, that is routed to a relay's amt device: it reaches
amt_dev_xmit() unsegmented because the device offers
NETIF_F_GSO_SOFTWARE, and the outer UDP layer later segments each
per-tunnel copy at the inner gso_size.

Testing: W=1 build with CONFIG_IPV6=y and =n, and
tools/testing/selftests/net/amt.sh passes with the patch applied, but
amt.sh never sends a GSO skb, so nothing exercises the changed path.

Re: [PATCH net] amt: do not offer software GSO on the amt device

[Eric Dumazet]

On Thu, Oct 1, 2026 at 12:27 AM Omar Ramadan <omar@blockcast.net> wrote:
>
> Found by code inspection: an LLM-assisted review of drivers/net/amt.c
> while I was working on an IPv6 outer transport for amt.
>
> It has not been triggered. I have no reproducer, and I have not seen
> it in production or in testing; it comes from reading the code. The
> path is a GSO skb, for example from a UDP_SEGMENT sender or a GRO
> merged UDP flow, that is routed to a relay's amt device: it reaches
> amt_dev_xmit() unsegmented because the device offers
> NETIF_F_GSO_SOFTWARE, and the outer UDP layer later segments each
> per-tunnel copy at the inner gso_size.
>
> Testing: W=1 build with CONFIG_IPV6=y and =n, and
> tools/testing/selftests/net/amt.sh passes with the patch applied, but
> amt.sh never sends a GSO skb, so nothing exercises the changed path.

1)  Note that tx checksum offload is off by default on amt, so the bug
would not trigger by default.

2) Please take a look at Documentation/process/coding-assistants.rst

3) A better fix would be (for net-next) to call udp_tunnel_handle_offloads()
in amt_send_multicast_data() like other UDP tunnels do

Re: [PATCH net] amt: do not offer software GSO on the amt device

[Omar Ramadan]

(Resending with the list and Cc's restored; my first copy went to
Eric only by mistake.)

On Thu, Oct 1, 2026, Eric Dumazet wrote:
> 1)  Note that tx checksum offload is off by default on amt, so the bug
> would not trigger by default.

You're right, and I should have checked that before sending. With
tx-checksum-ip-generic off, netdev_fix_features() drops GSO_UDP_L4
from amt's features, so validate_xmit_skb() segments any UDP GSO skb
before amt_dev_xmit() sees it. It takes "ethtool -K <amt> tx on" first.

The commit message, and my reply to the bot, also overstate the
symptom. Even with tx on, the per-tunnel copy keeps csum_start on the
inner UDP header, so where it is segmented in software,
__udp_gso_segment() rejects it and the copy is dropped, rather than
being cut into malformed AMT messages. That is from reading the code,
not from a reproducer.

> 2) Please take a look at Documentation/process/coding-assistants.rst

Thanks, I have. Anything further I send that an LLM helped with will
carry an Assisted-by: tag and say what was and was not reproduced.

> 3) A better fix would be (for net-next) to call udp_tunnel_handle_offloads()
> in amt_send_multicast_data() like other UDP tunnels do

Agreed, please drop this patch. I'll do it that way for net-next,
with an amt.sh case that sends a UDP_SEGMENT burst through the relay
with tx on.

pw-bot: cr