From: Julius Bairaktaris <julius@bairaktaris.de>
To: netdev@vger.kernel.org
Cc: dsahern@kernel.org, idosch@nvidia.com, davem@davemloft.net,
edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com,
horms@kernel.org, steffen.klassert@secunet.com,
willemb@google.com, jiayuan.chen@linux.dev,
mfleming@cloudflare.com, almasrymina@google.com,
bigeasy@linutronix.de, richardbgobert@gmail.com,
ecree.xilinx@gmail.com, linux-kernel@vger.kernel.org
Subject: [PATCH net v3 0/4] ipmr: forward GSO multicast packets
Date: Sun, 18 Oct 2026 14:58:50 +0200 [thread overview]
Message-ID: <cover.1792293419.git.julius@bairaktaris.de> (raw)
With fraglist GRO or UDP GRO forwarding on, a routed IPv4 multicast
stream arrives as GSO packets. ipmr_prepare_xmit() drops every DF
aggregate larger than the MTU, and ip_encap() sets no tunnel GSO state,
so a GSO packet sent to a VIFF_TUNNEL vif is dropped during
segmentation. With that state set, a fraglist aggregate reaches
skb_segment_list() with tunnel headers, which can write before the head
of a frag_list member, and a TCP GRO packet keeps its fixed-ID flag on
what is now the outer header. Both also happen today when such a packet
is routed into a tunnel device.
Patch 1 makes room for the tunnel headers in skb_segment_list().
Patch 2 moves the TCP fixed-ID flag to the inner header on encapsulation.
Patch 3 sets up IPXIP4 GSO state and outer IP IDs in ip_encap().
Patch 4 lets DF GSO packets pass when their segments fit the MTU.
Tested in QEMU on veth, n=3 per arm: an MFC entry to a plain vif and a
tunnel vif, 4000 1316-byte datagrams per run, fraglist GRO, UDP GRO
forwarding and UDP_SEGMENT, DF set and clear, software segmentation on
egress; a fraglist stream routed into VXLAN over IPv4 and IPv6; and a
TCP stream with fixed IP IDs, merged by GRO and routed into an ipip
device with DF clear.
- net (7ec48f396a1d): DF aggregates dropped on both vifs (FragFails),
non-DF aggregates dropped on the tunnel vif (tx_dropped); VXLAN:
KASAN slab-out-of-bounds write in skb_segment_list() in 6 of 6
runs, then a panic.
- v2: outer IP IDs repeat on the tunnel vif in 18 of 18 runs.
- without patch 2: TCP over ipip repeats outer IP IDs (831 unique of
14666) and increments the fixed inner IDs, 3 of 3 runs.
- this series: every segment sent on both vifs, FragFails 0, no tx
drops, outer IP IDs unique in 18 of 18 runs; VXLAN: no KASAN report
in 6 of 6 runs; TCP over ipip: outer IDs unique, inner IDs kept, 3 of
3 runs.
Changes in v3:
- Patch 1: name the VXLAN out-of-bounds write (Sashiko).
- Add patch 2 (Sashiko).
- Patch 3: reserve one outer IP ID per segment (Sashiko).
- v2: https://lore.kernel.org/netdev/20261011162957.1328474-1-julius@bairaktaris.de/
Changes in v2:
- Add patches 1 and 3; v1 let DF GSO packets reach ip_encap() on tunnel
vifs, where they were dropped during segmentation (Sashiko).
- Keep the additive MTU comparison and check mtu > encap before
subtracting, so a route MTU below 20 cannot wrap (Sashiko).
- v1: https://lore.kernel.org/netdev/20261010131842.2157365-1-julius@bairaktaris.de/
Julius Bairaktaris (4):
net: make room for the tunnel header in skb_segment_list()
ip_tunnel: move the TCP fixed-ID flag to the inner header
ipmr: set up GSO state for tunnel vifs
ipmr: do not drop GSO packets that fit the MTU after segmentation
net/core/skbuff.c | 4 ++++
net/ipv4/ip_tunnel_core.c | 13 ++++++++++++-
net/ipv4/ipmr.c | 23 +++++++++++++++++------
3 files changed, 33 insertions(+), 7 deletions(-)
base-commit: 7ec48f396a1d89532c0537bc38b408b8c31ee37f
--
2.53.0
next reply other threads:[~2026-10-18 12:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-18 12:58 Julius Bairaktaris [this message]
2026-10-18 12:58 ` [PATCH net v3 1/4] net: make room for the tunnel header in skb_segment_list() Julius Bairaktaris
2026-10-18 12:58 ` [PATCH net v3 2/4] ip_tunnel: move the TCP fixed-ID flag to the inner header Julius Bairaktaris
2026-10-18 12:58 ` [PATCH net v3 3/4] ipmr: set up GSO state for tunnel vifs Julius Bairaktaris
2026-10-18 12:58 ` [PATCH net v3 4/4] ipmr: do not drop GSO packets that fit the MTU after segmentation Julius Bairaktaris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1792293419.git.julius@bairaktaris.de \
--to=julius@bairaktaris.de \
--cc=almasrymina@google.com \
--cc=bigeasy@linutronix.de \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=ecree.xilinx@gmail.com \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=jiayuan.chen@linux.dev \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mfleming@cloudflare.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=richardbgobert@gmail.com \
--cc=steffen.klassert@secunet.com \
--cc=willemb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.