From: Sabrina Dubroca <sd@queasysnail.net>
To: Pavel Begunkov <asml.silence@gmail.com>
Cc: netdev@vger.kernel.org, Huzaifa Sidhpurwala <huzaifas@redhat.com>,
"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>,
Willem de Bruijn <willemb@google.com>
Subject: Re: [PATCH net] net: gro: don't copy frags between mixed zcopy skbs
Date: Tue, 19 May 2026 16:59:52 +0200 [thread overview]
Message-ID: <agx66OTyTlQbot0M@krikkit> (raw)
In-Reply-To: <743e314d-abfd-4a03-a74e-33a57c0bf6b8@gmail.com>
2026-05-19, 15:39:19 +0100, Pavel Begunkov wrote:
> On 5/19/26 13:40, Sabrina Dubroca 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.
>
> Was it reproduced? Sounds like we're missing skb_orphan_frags_rx()
> as skbs looping into rx should be orphaned.
>
> +cc Willem
Yes, as I wrote in the patch:
Huzaifa has found this to be exploitable to overwrite the page cache
Neither of us is that familiar with MANAGED_FRAG_REFS/iouring, so
maybe there's a better way to fix this at another location in the
stack.
--
Sabrina
next prev parent reply other threads:[~2026-05-19 14:59 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
2026-05-19 14:39 ` Pavel Begunkov
2026-05-19 14:59 ` Sabrina Dubroca [this message]
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=agx66OTyTlQbot0M@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.