On Mon, May 18, 2026 at 2:30 PM Christian Brauner <[email protected]> wrote: > On Sat, May 16, 2026 at 07:21:26PM +0100, Pedro Falcato wrote: > > Since the advent of vulns like Dirty Pipe, Dirty Frag, Copy Fail > > and Fragnasia, splicing a read-only file is fundamentally unsafe. > > > > As such, as a mitigation, add a way for users to block splice() for > > files they cannot write to. This eliminates this whole class of exploits > > that use splice()+confusion in pipe/net/etc code to gain write-access to > > files they can only read. > > > > Users can simply toggle fs.splice_needs_write=1 and suddenly splice() will > > refuse perfectly legal splices() from files it can only read, but not write. [...] > At that point you can also just ENOSYS splice() and vmsplice() via > seccomp and force a fallback on non-splice codepaths that userspace has > to have anyway as splice() isn't supported unconditionally. > > It feels like a knee-jerk reaction to an exploit class originating in > buggy modules that we have little control over and we would extend an > API to users that is really difficult to use. > > What might make more sense is to add a splice specific security_*() hook > into the code so that an LSM can deny usage of splice in whatever way it > wants to - bpf lsm or in-tree lsm.
I feel like a sysctl for "disable all the splice-like interfaces and zerocopy TX" would be reasonable to have? Either by blocking such operations, or better, silently downgrading all such operations to normal copies. FWIW, vmsplice() and splice() are also weird in how much memory they can implicitly pin - if you call vmsplice() on a single byte in a 2M THP page, I believe you'll implicitly pin 2M of memory... By the way, another bug a few years ago of a similar shape was this one - also a bug in networking code that can lead to accidental writes into spliced pages: https://project-zero.issues.chromium.org/issues/42451650 ("ktls writes into spliced readonly pages") with fix: https://git.kernel.org/linus/c5a595000e26
