From: "Ahelenia Ziemiańska" <nabijaczleweli@nabijaczleweli.xyz>
Cc: Jens Axboe <axboe@kernel.dk>,
Christian Brauner <brauner@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jirislaby@kernel.org>,
Miklos Szeredi <miklos@szeredi.hu>,
Vivek Goyal <vgoyal@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Eric Dumazet <edumazet@google.com>,
"David S. Miller" <davem@davemloft.net>,
David Ahern <dsahern@kernel.org>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>,
Wenjia Zhang <wenjia@linux.ibm.com>,
Jan Karcher <jaka@linux.ibm.com>,
"D. Wythe" <alibuda@linux.alibaba.com>,
Tony Lu <tonylu@linux.alibaba.com>,
Wen Gu <guwen@linux.alibaba.com>,
Boris Pismenny <borisp@nvidia.com>,
John Fastabend <john.fastabend@gmail.com>,
David Howells <dhowells@redhat.com>,
Shigeru Yoshida <syoshida@redhat.com>,
Peilin Ye <peilin.ye@bytedance.com>,
Kuniyuki Iwashima <kuniyu@amazon.com>,
Alexander Mikhalitsyn <alexander@mihalicyn.com>,
Daan De Meyer <daan.j.demeyer@gmail.com>,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
virtualization@lists.linux.dev, netdev@vger.kernel.org,
linux-s390@vger.kernel.org, Alejandro Colomar <alx@kernel.org>,
linux-man@vger.kernel.org
Subject: [PATCH v2 00/11] Avoid unprivileged splice(file->)/(->socket) pipe exclusion
Date: Thu, 21 Dec 2023 04:08:41 +0100 [thread overview]
Message-ID: <cover.1703126594.git.nabijaczleweli@nabijaczleweli.xyz> (raw)
[-- Attachment #1: Type: text/plain, Size: 4391 bytes --]
Hi!
As it stands, splice(file -> pipe):
1. locks the pipe,
2. does a read from the file,
3. unlocks the pipe.
When the file resides on a normal filesystem, this isn't an issue
because the filesystem has been defined as trusted by root having
mounted it.
But when the file is actually IPC (FUSE) or is just IPC (sockets)
or is a tty, this means that the pipe lock will be held for an
attacker-controlled length of time, and during that time every
process trying to read from, write to, open, or close the pipe
enters an uninterruptible sleep, and will only exit it if the
splicing process is killed.
This trivially denies service to:
* any hypothetical pipe-based log collexion system
* all nullmailer installations
* me, personally, when I'm pasting stuff into qemu -serial chardev:pipe
A symmetric situation happens for splicing(pipe -> socket):
the pipe is locked for as long as the socket is full.
This follows:
1. https://lore.kernel.org/linux-fsdevel/qk6hjuam54khlaikf2ssom6custxf5is2ekkaequf4hvode3ls@zgf7j5j4ubvw/t/#u
2. a security@ thread rooted in
<irrrblivicfc7o3lfq7yjm2lrxq35iyya4gyozlohw24gdzyg7@azmluufpdfvu>
3. https://nabijaczleweli.xyz/content/blogn_t/011-linux-splice-exclusion.html
4. https://lore.kernel.org/lkml/cover.1697486714.git.nabijaczleweli@nabijaczleweli.xyz/t/#u (v1)
https://lore.kernel.org/lkml/1cover.1697486714.git.nabijaczleweli@nabijaczleweli.xyz/t/#u (resend)
https://lore.kernel.org/lkml/2cover.1697486714.git.nabijaczleweli@nabijaczleweli.xyz/t/#u (reresend)
5. https://lore.kernel.org/lkml/dtexwpw6zcdx7dkx3xj5gyjp5syxmyretdcbcdtvrnukd4vvuh@tarta.nabijaczleweli.xyz/t/#u
(relay_file_splice_read removal)
1-7/11 request MSG_DONTWAIT (sockets)/IOCB_NOWAIT (generic) on the read
8/11 removes splice_read from tty completely
9/11 removes splice_read from FUSE filesystems
(except virtiofs which has normal mounting security semantics,
but is handled via FUSE code)
10/11 allows splice_read from FUSE filesystems mounted by real root
(this matches the blessing received by non-FUSE network filesystems)
11/11 requests MSG_DONTWAIT for splice(pipe -> socket).
12/11 has the man-pages patch with draft wording.
All but 5/11 (AF_SMC) have been tested and embed shell programs to
repro them. AIUI I'd need an s390 machine for it? It's trivial.
6/11 (AF_KCM) also fixes kcm_splice_read() passing SPLICE_F_*-style
flags to skb_recv_datagram(), which takes MSG_*-style flags. I don't
think they did anything anyway? But.
There are two implementations that definitely sleep all the time
and I didn't touch them:
tracing_splice_read_pipe
tracing_buffers_splice_read (dropped in v2, v1 4/11)
the semantics are lost on me, but they're in debugfs/tracefs, so
it doesn't matter if they block so long as they work, and presumably
they do right now.
There is also relay_file_splice_read (dropped in v2, v1 5/11),
which isn't an implementation at all because it's dead code, broken,
and removed in -mm.
The diffs in 1-7,11/11 are unchanged, save for a rebase in 7/11.
8/11 replaces the file type test in v1 10/11.
9/11 and 10/11 are new in v2.
Ahelenia Ziemiańska (11):
splice: copy_splice_read: do the I/O with IOCB_NOWAIT
af_unix: unix_stream_splice_read: always request MSG_DONTWAIT
fuse: fuse_dev_splice_read: use nonblocking I/O
net/smc: smc_splice_read: always request MSG_DONTWAIT
kcm: kcm_splice_read: always request MSG_DONTWAIT
tls/sw: tls_sw_splice_read: always request non-blocking I/O
net/tcp: tcp_splice_read: always do non-blocking reads
tty: splice_read: disable
fuse: file: limit splice_read to virtiofs
fuse: allow splicing from filesystems mounted by real root
splice: splice_to_socket: always request MSG_DONTWAIT
drivers/tty/tty_io.c | 2 --
fs/fuse/dev.c | 10 ++++++----
fs/fuse/file.c | 17 ++++++++++++++++-
fs/fuse/fuse_i.h | 4 ++++
fs/fuse/inode.c | 2 ++
fs/fuse/virtio_fs.c | 1 +
fs/splice.c | 5 ++---
net/ipv4/tcp.c | 32 +++-----------------------------
net/kcm/kcmsock.c | 2 +-
net/smc/af_smc.c | 6 +-----
net/tls/tls_sw.c | 5 ++---
net/unix/af_unix.c | 5 +----
12 files changed, 39 insertions(+), 52 deletions(-)
base-commit: 2cf4f94d8e8646803f8fb0facf134b0cd7fb691a
--
2.39.2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next reply other threads:[~2023-12-21 3:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-21 3:08 Ahelenia Ziemiańska [this message]
2023-12-21 3:09 ` [PATCH v2 12/11 man-pages] splice.2: document 6.8 blocking behaviour Ahelenia Ziemiańska
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=cover.1703126594.git.nabijaczleweli@nabijaczleweli.xyz \
--to=nabijaczleweli@nabijaczleweli.xyz \
--cc=alexander@mihalicyn.com \
--cc=alibuda@linux.alibaba.com \
--cc=alx@kernel.org \
--cc=axboe@kernel.dk \
--cc=borisp@nvidia.com \
--cc=brauner@kernel.org \
--cc=daan.j.demeyer@gmail.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=guwen@linux.alibaba.com \
--cc=jaka@linux.ibm.com \
--cc=jirislaby@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=kuniyu@amazon.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=peilin.ye@bytedance.com \
--cc=stefanha@redhat.com \
--cc=syoshida@redhat.com \
--cc=tonylu@linux.alibaba.com \
--cc=vgoyal@redhat.com \
--cc=viro@zeniv.linux.org.uk \
--cc=virtualization@lists.linux.dev \
--cc=wenjia@linux.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).