All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sabrina Dubroca <sd@queasysnail.net>
To: Eric Dumazet <edumazet@google.com>
Cc: Willem de Bruijn <willemb@google.com>,
	netdev@vger.kernel.org, Huzaifa Sidhpurwala <huzaifas@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Simon Horman <horms@kernel.org>,
	Pavel Begunkov <asml.silence@gmail.com>
Subject: Re: [PATCH net] net: gro: don't copy frags between mixed zcopy skbs
Date: Tue, 19 May 2026 15:12:06 +0200	[thread overview]
Message-ID: <agxhpnI84II_Utjk@krikkit> (raw)
In-Reply-To: <CANn89i+w93DBm_yo5DZ6K_dgV4Gst=vb5OnTcXi2rKqeNHZSbQ@mail.gmail.com>

2026-05-19, 05:57:22 -0700, Eric Dumazet wrote:
> On Tue, May 19, 2026 at 5:40 AM Sabrina Dubroca <sd@queasysnail.net> wrote:
> >
> > skb_gro_receive() can currently copy frags between the source and GRO
> > skb, without checking the zerocopy status, and in particular the
> > SKBFL_MANAGED_FRAG_REFS flag.
> >
> > When SKBFL_MANAGED_FRAG_REFS is set, the skb doesn't hold a reference
> > on the pages in shinfo->frags. Appending those frags to another skb's
> > frags without fixing up the page refcount can lead to UAF.
> >
> > When either the last skb in the GRO chain (the one we would append
> > frags to) or the source skb is zerocopy, skip the frags copy, and just
> > append the new skb to the frag_list.
> >
> > This is probably a bit less efficient than calling
> > skb_zcopy_downgrade_managed(), but then we'd also have to handle the
> > rest of the zerocopy flags/machinery. This can be improved in
> > net-next.
> >
> > Fixes: 753f1ca4e1e5 ("net: introduce managed frags infrastructure")
> > Reported-by: Huzaifa Sidhpurwala <huzaifas@redhat.com>
> > Assisted-by: Claude:claude-mythos-preview
> > Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
> > ---
> >  net/core/gro.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > Huzaifa has found this to be exploitable to overwrite the page cache
> >
> > diff --git a/net/core/gro.c b/net/core/gro.c
> > index 31d21de5b15a..cae0a0dbfa69 100644
> > --- a/net/core/gro.c
> > +++ b/net/core/gro.c
> > @@ -123,6 +123,9 @@ int skb_gro_receive(struct sk_buff *p, struct sk_buff *skb)
> >         lp = NAPI_GRO_CB(p)->last;
> >         pinfo = skb_shinfo(lp);
> >
> > +       if (skb_zcopy(skb) || skb_zcopy(lp))
> > +               goto merge;
> > +
> >         if (headlen <= offset) {
> >                 skb_frag_t *frag;
> >                 skb_frag_t *frag2;
> 
> Do we really want to merge these skbs in the first place?
> 
> What about play safe?

Seems reasonable to me. I'll wait another 23.5 hours to submit v2.
(and I'll let you pick some commit tags if you want)

-- 
Sabrina

  reply	other threads:[~2026-05-19 13:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-19 12:40 [PATCH net] net: gro: don't copy frags between mixed zcopy skbs Sabrina Dubroca
2026-05-19 12:57 ` Eric Dumazet
2026-05-19 13:12   ` Sabrina Dubroca [this message]
2026-05-19 14:39 ` Pavel Begunkov
2026-05-19 14:59   ` Sabrina Dubroca
2026-05-25  7:28     ` Pavel Begunkov

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=agxhpnI84II_Utjk@krikkit \
    --to=sd@queasysnail.net \
    --cc=asml.silence@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=huzaifas@redhat.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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.