[PATCH] net: block MSG_NO_SHARED_FRAGS in sendmsg()

[PATCH] net: block MSG_NO_SHARED_FRAGS in sendmsg()

[Jann Horn]

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.

Signed-off-by: Jann Horn <jannh@google.com>
---
 include/linux/socket.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/socket.h b/include/linux/socket.h
index ec4a0a025793..1a4d0d128a13 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -357,7 +357,7 @@ struct ucred {
 
 /* Flags to be cleared on entry by sendmsg and sendmmsg syscalls */
 #define MSG_INTERNAL_SENDMSG_FLAGS \
-	(MSG_SPLICE_PAGES | MSG_SENDPAGE_NOPOLICY | MSG_SENDPAGE_DECRYPTED)
+	(MSG_SPLICE_PAGES | MSG_SENDPAGE_NOPOLICY | MSG_SENDPAGE_DECRYPTED | MSG_NO_SHARED_FRAGS)
 
 /* Setsockoptions(2) level. Thanks to BSD these must match IPPROTO_xxx */
 #define SOL_IP		0

---
base-commit: 5d6919055dec134de3c40167a490f33c74c12581
change-id: 20260511-msg_no_shared_frags-d557c14e487b

--  
Jann Horn <jannh@google.com>

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

[David Laight]

On Tue, 12 May 2026 16:02:03 +0200
Jann Horn <jannh@google.com> 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?

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.

-- David

> 
> Signed-off-by: Jann Horn <jannh@google.com>
> ---
>  include/linux/socket.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/socket.h b/include/linux/socket.h
> index ec4a0a025793..1a4d0d128a13 100644
> --- a/include/linux/socket.h
> +++ b/include/linux/socket.h
> @@ -357,7 +357,7 @@ struct ucred {
>  
>  /* Flags to be cleared on entry by sendmsg and sendmmsg syscalls */
>  #define MSG_INTERNAL_SENDMSG_FLAGS \
> -	(MSG_SPLICE_PAGES | MSG_SENDPAGE_NOPOLICY | MSG_SENDPAGE_DECRYPTED)
> +	(MSG_SPLICE_PAGES | MSG_SENDPAGE_NOPOLICY | MSG_SENDPAGE_DECRYPTED | MSG_NO_SHARED_FRAGS)
>  
>  /* Setsockoptions(2) level. Thanks to BSD these must match IPPROTO_xxx */
>  #define SOL_IP		0
> 
> ---
> base-commit: 5d6919055dec134de3c40167a490f33c74c12581
> change-id: 20260511-msg_no_shared_frags-d557c14e487b
> 
> --  
> Jann Horn <jannh@google.com>
> 
> 

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@gmail.com> wrote:
> On Tue, 12 May 2026 16:02:03 +0200
> Jann Horn <jannh@google.com> 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".