On Sun, May 17, 2026 at 01:51:16AM +0200, Mateusz Guzik wrote: > On Sat, May 16, 2026 at 8:21 PM Pedro Falcato <[email protected]> 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. > > > > The patch touches stuff I'm not familiar with, so no comments on that front. > > The core idea is a half-measure which will at best buy few weeks until > splice bugs dry out and there will be a new attack vector du jour > which people point their LLMs at. Perhaps it is worth it as a bandaid > until a more complete solution shows up.
I won't say you don't have a point. However, the whole idea is to attempt to restrict the attack vector. This is a proven source of problems. It's known since 2022 - now we have 3 or 4 new vulnerabilities taking advantage of this. Clearly, the kernel isn't doing great passing these pages around the kernel. The API isn't the easiest to use (much less safely). Can those be tackled? Yes. Today? Definitely not. In a few years? Also doubtful. Merging something like this (or equivalent, that allows for a restriction) I think is simply common sense. Basic hardening of interfaces so if anything gets discovered it's much less severe. Even if nothing else related to splice() gets discovered, I think it's still useful to have secure by default, minimally intrusive hardening in the kernel. One example: do you really need to be able to send SUID binaries in a zero-copy super efficient way around the kernel? Not really. But if something fscks it up, you get the world's easiest LPE. (not that today they couldn't find some random UAF and attempt to exploit this, since all of the page cache is mapped, but there are concurrent efforts e.g ASI that attempt to tackle this) > > A full-measure solution would git rm these modules to > fuck^W^W^W^W^W^Wprevent suspicious modules from being usable by > unprivileged users to begin with, at least by default. Of the cases I Sadly, for the networking case it's pretty important to have autoloading for protocol modules. Also, for the module in question (for Fragnesia it was ESP), that's really not that arcane. It's just a piece of code that gets confused as to whether or not it owns (versus "shares", like it should) the pages it's looking at. With fragnesia it's been found out that there are _several_ important spots in the networking stack that aren't getting this shared flag propagation correctly. > had seen so far, your typical machine either does not have the thing > loaded or in the worst case does not have a legitimate reason to > expose them. Someone(tm) would have to figure out a sensible setup > where stuff stops autoloading and there is a whitelist of modules > allowed on the box, and even then the functionality provided is only > usable by select people. > > Back in the day I wrote a LSM which learned what kind of socket > options etc. are being used in a given workload and afterwards only > allowed that. The code never escaped $workplace, but the idea might be > a starting point. It's beyond my skillset to comment whether or not that works well in practice :) > > All that aside, is someone with access to many tokens(tm) racing the > bad guys vs splice bugs? Realistically one has to assume there are I would assume it's hard to race the bad guys (the typical security problem). You get a great zero-day as a blackhat and (AIUI) you might be looking at tens-to-even-hundreds of thousands in rewards. But, again, not really my field of expertise :v > some more waiting (as suggested by the patch) and chances are decent > nobody has to be caught with their pants down even without the > aforementioned mitigation. -- Pedro
