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. 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 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. 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 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.
