Re: [PATCH] net: block MSG_NO_SHARED_FRAGS in sendmsg()

[Jann Horn]

On Wed, May 13, 2026 at 10:50 AM David Laight
<david.laight.linux@xxxxxxxxx> wrote:
> On Tue, 12 May 2026 16:02:03 +0200
> Jann Horn <jannh@xxxxxxxxxx> wrote:
>
> > This change should cause no difference in behavior; it just cleans up some
> > hazardous code that could have become a problem in the future.
> >
> > MSG_NO_SHARED_FRAGS is a kernel-internal flag that cancels the effect of
> > MSG_SPLICE_PAGES, another kernel-internal flag that influences the
> > data-sharing semantics of SKBs.
> >
> > Prevent passing this flag in from userspace via sendmsg() by adding it to
> > MSG_INTERNAL_SENDMSG_FLAGS.
> >
> > This is not currently an observable problem because MSG_NO_SHARED_FRAGS
> > only has an effect if kernel code adds MSG_SPLICE_PAGES to it.
> > The only codepath that adds MSG_SPLICE_PAGES to user-supplied flags from
> > which MSG_NO_SHARED_FRAGS hasn't been cleared is the path
> > tcp_bpf_sendmsg -> tcp_bpf_send_verdict -> tcp_bpf_push, and that is not a
> > problem because tcp_bpf_sendmsg always intentionally sets
> > MSG_NO_SHARED_FRAGS anyway.
>
> Should that be inverted to an explicit list of valid flags?

That would be more robust in the long term, yes. I figured I'd just
add this one flag to MSG_INTERNAL_SENDMSG_FLAGS since that's more
obviously correct than making sure I have a full list of allowed
flags.

> Unfortunately it doesn't look like calls with unsupported flags can be
> errored - which actually means that no new ones can be allocated for
> new functionality.

That's not entirely true - to avoid issues like that, MSG_ZEROCOPY was
wired up such that it only takes effect if userspace first sets
SO_ZEROCOPY, which essentially means "I promise I'm not passing
MSG_ZEROCOPY to this socket accidentally".