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. > > 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.
Shouldn't be difficult with a bpf lsm tbh. Just so we don't get any ideas about adding yet more lsms to the kernel...
