From: "Michael S. Tsirkin" <mst@redhat.com>
To: Eric Dumazet <edumazet@kernel.org>
Cc: linux-kernel@vger.kernel.org, Eric Dumazet <edumazet@google.com>,
Claude Code <noreply@anthropic.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
netdev@vger.kernel.org
Subject: Re: [PATCH net] skbuff: keep accesses through unset transport header in bounds
Date: Sun, 25 Oct 2026 04:50:00 -0400 [thread overview]
Message-ID: <20261025044225-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAL4WiipHjseFcNaqaufAf5C7d3J5e6aLZBTsehJuJyR2m7G1Hg@mail.gmail.com>
On Sun, Oct 25, 2026 at 09:18:14AM +0100, Eric Dumazet wrote:
> Le sam. 24 oct. 2026 à 14:56, Michael S. Tsirkin <mst@redhat.com> a écrit :
> >
> > Commit 2170a1f09148 ("net: no longer reset transport_header in
> > __netif_receive_skb_core()") stopped the receive path from pretending
> > that an unset transport header starts at the network header - but only
> > on CONFIG_DEBUG_NET=y builds, the idea being that fuzzers and CI could
> > catch stacks reading a transport header where none was ever established.
> > And the plan is to drop this for release as well.
> >
> > Indeed, under KASAN, an access through the unset offset produces a
> > slab-out-of-bounds splat, which is how these bugs are usually found.
> > But a regular debug build has no such safety net: the accesses land at
> > skb->head + 0xffff, some 64K past the packet data.
> >
> > I don't think release builds are exposed to oob in this way, but I want
> > to make the stack a bit more robust if yes.
>
>
> This is not a net candidate: there is no bug in release builds, since
> __netif_receive_skb_core() still resets the transport header when
> CONFIG_DEBUG_NET is not set. The Fixes: tag points to a commit doing
> exactly what it was meant to do.
Good point.
>
> > While I appreciate a nice
> > KASAN splat as much as the next developer, making even a debug kernel do
> > oob accesses was never the point of the exercise.
> >
> > Make skb_transport_header(), and its inner variant, verify and WARN,
> > then fall back to the network header position when the transport header
> > was not set. This way, accesses stay within the packet.
>
> This adds a test and a conditional branch in a very hot helper
> (tcp_hdr(), udp_hdr(), skb_transport_offset()...), inlined in hundreds
> of places, for all builds, to protect CONFIG_DEBUG_NET=y builds only.
Good point. I'll put this in ifdef CONFIG_DEBUG_NET then?
> Falling back to the network header is also what 2170a1f09148 wanted
> to stop doing: pretending transport and network headers are the same
> is wrong, and silently hides the bug after the first WARN_ON_ONCE().
> KASAN would no longer report anything.
But the bug already manifested with a warning, why do we want
also the kasan splat much later? And why do we want memory
silently corrupted on non KASAN builds with CONFIG_DEBUG_NET?
> >
> > An extra benefit is that release and debug kernels now behave
> > identically if an unset transport header is ever reached,
> > avoids heisenbugs.
> >
>
> Not really, the fallback path is only reachable on CONFIG_DEBUG_NET=y
> builds.
Yes, this is what I referred to as the heisenbug: release behaves one
way, debug another, so e.g. if there's a bug only with header set,
it will not reproduce. I guess it's not a concern then.
>
> If you have an actual report (syzbot, KASAN, or a stack trace from a
> debug build), please share it, and we will fix the caller that uses
> an unset transport header. That is the whole point of the debug check.
>
> pw-bot: rejected
>
> > Fixes: 2170a1f09148 ("net: no longer reset transport_header in __netif_receive_skb_core()")
> > Cc: Eric Dumazet <edumazet@google.com>
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > Co-Authored-By: Claude Code <noreply@anthropic.com>
> > ---
> > include/linux/skbuff.h | 12 +++++++++++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > index a3ff380d43f0..cbfeb17d86f7 100644
> > --- a/include/linux/skbuff.h
> > +++ b/include/linux/skbuff.h
> > @@ -2993,6 +2993,12 @@ static inline void skb_reset_mac_len(struct sk_buff *skb)
> > static inline unsigned char *skb_inner_transport_header(const struct sk_buff
> > *skb)
> > {
> > + if (unlikely(skb->inner_transport_header ==
> > + (typeof(skb->inner_transport_header))~0U)) {
>
>
> Inner offsets do not use ~0 as an 'unset' marker, they are zeroed.
>
> > + DEBUG_NET_WARN_ON_ONCE(1);
> > + return skb->head + skb->inner_network_header;
> > + }
> > +
> > return skb->head + skb->inner_transport_header;
> > }
> >
> > @@ -3072,7 +3078,11 @@ static inline void skb_unset_transport_header(struct sk_buff *skb)
> >
> > static inline unsigned char *skb_transport_header(const struct sk_buff *skb)
> > {
> > - DEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb));
> > + if (unlikely(!skb_transport_header_was_set(skb))) {
> > + DEBUG_NET_WARN_ON_ONCE(1);
> > + return skb->head + skb->network_header;
> > + }
> > +
> > return skb->head + skb->transport_header;
> > }
> >
> > --
> > MST
> >
next prev parent reply other threads:[~2026-10-25 8:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-24 12:56 [PATCH net] skbuff: keep accesses through unset transport header in bounds Michael S. Tsirkin
2026-10-24 12:59 ` netdev-bot+sinfo
2026-10-25 8:18 ` Eric Dumazet
2026-10-25 8:50 ` Michael S. Tsirkin [this message]
2026-10-25 13:45 ` netdev-bot+sashiko
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=20261025044225-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=noreply@anthropic.com \
--cc=pabeni@redhat.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.