From: Justin Iurman <justin.iurman@gmail.com>
To: Yuya Kusakabe <yuya.kusakabe@gmail.com>,
Andrea Mayer <andrea.mayer@uniroma2.it>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v3] net: ipv6: keep room for the mac header in dst_dev_overhead()
Date: Mon, 21 Sep 2026 23:59:46 +0200 [thread overview]
Message-ID: <206467ff-9afc-42e0-a0ff-e861f67ced89@gmail.com> (raw)
In-Reply-To: <20260922-seg6-maclen-headroom-v3-1-7b2f982ef79d@gmail.com>
On 9/21/26 22:49, Yuya Kusakabe wrote:
> The seg6, ioam6 and rpl lwtunnels size their skb_cow_head() request
> as the length they are about to push plus dst_dev_overhead(), then
> push the new headers and rebuild the mac header below them with
> skb_mac_header_rebuild(). That rebuild needs skb->mac_len of
> headroom, but dst_dev_overhead() leaves LL_RESERVED_SPACE() of the
> egress device, 16 bytes for plain Ethernet.
>
> Where the mac header is longer than that, as it is on ingress
> through a VLAN device with reorder_hdr off, the rebuild runs out of
> room: skb_set_mac_header(skb, -skb->mac_len) computes a negative
> offset, stores it unchecked in the u16 skb->mac_header, and the
> memmove that follows writes skb->mac_len bytes about 64 KB past skb-
> >head. Forwarding plain ping6 traffic through such a device
> reproduces it on all five seg6 encapsulation modes and on the rpl
> and ioam6 inline paths; skb->mac_header comes back as 65534 on a 704-
> byte head.
>
> Return the larger of the two. The helper already returns skb-
> >mac_len when it has no dst, so this only makes the other branch
> agree, and it covers every caller rather than each call site in
> turn.
>
> Fixes: 40475b63761a ("net: ipv6: seg6_iptunnel: mitigate 2-realloc
> issue") Fixes: dce525185bc9 ("net: ipv6: ioam6_iptunnel: mitigate 2-
> realloc issue") Fixes: 985ec6f5e623 ("net: ipv6: rpl_iptunnel:
> mitigate 2-realloc issue") Suggested-by: Andrea Mayer
> <andrea.mayer@uniroma2.it> Assisted-by: LLM Signed-off-by: Yuya
> Kusakabe <yuya.kusakabe@gmail.com> --- Changes in v3: - Fix
> dst_dev_overhead() itself rather than each of its callers [Andrea] -
> Drop Justin's Reviewed-by from v2, which was given for the per-
> caller version; the patch no longer touches the files he reviewed -
> Link to v2: https://lore.kernel.org/r/20260918-seg6-maclen-headroom-
> v2-1-4d370af55b2e@gmail.com
>
> Changes in v2: - Use max_t(unsigned int, ...) rather than max()
> [Justin] - Make the same change in ioam6_iptunnel and rpl_iptunnel
> [Justin] - Reproduce and verify the fix on those two as well:
> unpatched, rpl underflows in 12 of 16 probed configurations and
> ioam6 in 3 of 13, both reaching about 64 KB past a 320-byte head;
> patched, neither underflows in 18 - Rewrap the requests so they no
> longer exceed 80 columns - Retitle for net: ipv6, now that the
> change spans three files - Link to v1: https://lore.kernel.org/
> r/20260917-seg6-maclen-headroom-v1-1-02ccec50f096@gmail.com ---
> include/net/dst.h | 3 ++- 1 file changed, 2 insertions(+), 1
> deletion(-)
>
> diff --git a/include/net/dst.h b/include/net/dst.h index
> 307073eae7f8..dbedfe72e1fd 100644 --- a/include/net/dst.h +++ b/
> include/net/dst.h @@ -455,7 +455,8 @@ static inline unsigned int
> dst_dev_overhead(struct dst_entry *dst, struct sk_buff *skb) { if
> (likely(dst)) - return LL_RESERVED_SPACE(dst->dev); + return
> max_t(unsigned int, skb->mac_len, + LL_RESERVED_SPACE(dst-
> >dev));
>
> return skb->mac_len; }
>
Reviewed-by: Justin Iurman <justin.iurman@gmail.com>
next prev parent reply other threads:[~2026-09-21 21:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 20:49 [PATCH net v3] net: ipv6: keep room for the mac header in dst_dev_overhead() Yuya Kusakabe
2026-09-21 21:59 ` Justin Iurman [this message]
2026-09-22 11:24 ` Gabriel Goller
2026-09-22 14:49 ` Eric Dumazet
2026-09-22 15:13 ` Andrea Mayer
2026-09-24 2:20 ` patchwork-bot+netdevbpf
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=206467ff-9afc-42e0-a0ff-e861f67ced89@gmail.com \
--to=justin.iurman@gmail.com \
--cc=andrea.mayer@uniroma2.it \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=yuya.kusakabe@gmail.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.