Yet another Dirty Frag type vulnerability: Fragnesia [LWN.net]

Sam James has sent an announcement to the OSS Security mailing list about another local-privilege-escalation (LPE) exploit in the same class as Dirty Frag, called "Fragnesia". From the disclosure:

This is a separate bug in the ESP/XFRM from dirtyfrag which has received its own patch. However, it is in the same surface and the mitigation is the same as for dirtyfrag.

It abuses a logic bug in the Linux XFRM ESP-in-TCP subsystem to achieve arbitrary byte writes into the kernel page cache of read-only files, without requiring any race condition.

James noted that there is a patch in the works, but it has not yet been pulled into Linus Torvalds's tree nor into any of the stable kernels. A proof of concept exploit is also available.

to post comments

People should be paying attention to the role of splice in these bugs.

Posted May 13, 2026 16:25 UTC (Wed) by koverstreet (subscriber, #4296) [Link] (18 responses)

splice() is what takes a logic bug that would otherwise be overwriting a few bytes in attacker owned memory and allows pointing it at anything.

It does have legitimate uses in high performance network servers, but it has a history of really subtle bugs because it violates the usual expectations when you're reading code - if you think you've considered everything in your subsystem, you probably haven't considered splice.

Restricting splice to just the applications that need it, or disabling it entirely would be some wise hardening.

People should be paying attention to the role of splice in these bugs.

Posted May 13, 2026 16:44 UTC (Wed) by geofft (subscriber, #59789) [Link] (1 responses)

This would be easy to restrict from untrusted userspace with a seccomp filter. Should this be considered something that you should generally close off if you're running a multi-user system with untrusted users, just like you should disable module autoloading, etc.? Do userspace applications that use it generally have fallbacks?

People should be paying attention to the role of splice in these bugs.

Posted May 13, 2026 16:57 UTC (Wed) by koverstreet (subscriber, #4296) [Link]

I wouldn't restrict it to multi user systems. If you're running a server, there's always an attack surface and the potential for remote code execution, but hopefully with sandboxing so a hole doesn't lead to the entire machine being taken over. All these local root exploits turn remote code execution into "I own your machine and you have to reinstall from scratch if you want to be safe".

People should be paying attention to the role of splice in these bugs.

Posted May 13, 2026 18:16 UTC (Wed) by azz (subscriber, #371) [Link] (11 responses)

It does look like it wouldn't be very difficult to add a CONFIG_SPLICE option to disable splice/vmsplice/tee, like the similar ones for IO_URING and ADVISE_SYSCALLS, and a fair chunk of supporting code could be disabled too, which might be of interest to the very-tiny-kernel people.

I wonder if any applications would be upset by getting ENOSYS rather than EINVAL when trying a splice...

People should be paying attention to the role of splice in these bugs.

Posted May 14, 2026 5:38 UTC (Thu) by wtarreau (subscriber, #51152) [Link] (10 responses)

> I wonder if any applications would be upset by getting ENOSYS rather than EINVAL when trying a splice...

They wouldn't necessarily be upset and would fall back to the slow path. However doing this as a config option won't work: distros will need to keep it enabled due to the numerous users. What would be needed would be a sysctl-based kill switch so that admins can decide on a per-system basis which ones must absolutely disable unprivileged splice even if it costs performance. It remains unlikely that it is disabled at most places anyway, because who wants to use more CPU cycles 100% of the time for routine workloads in hope to avoid a hypothetical LPE once every 5 years ? There are plenty of other occasions that will not use this vector anyway (and usually on systems that don't need a working splice, there's a password-less sudo user running everything from a browser...).

People should be paying attention to the role of splice in these bugs.

Posted May 14, 2026 7:04 UTC (Thu) by neggles (subscriber, #153254) [Link] (8 responses)

"Once every five years" somewhat loses its impact when there's been three in three weeks. Admittedly we don't know how long the tail of critical bugs like this actually is, but I'd be surprised if we made it more than a couple of months without another...

People should be paying attention to the role of splice in these bugs.

Posted May 14, 2026 15:03 UTC (Thu) by koverstreet (subscriber, #4296) [Link] (6 responses)

I'm also not seeing any security auditing being driven by the bugs being found, everything seems to be very reactive. Looking at the lists and LSF coverage, I see a lot of activity in the "performance" area, not a peep on how people are reacting to the security holes being found - and some of this really should be driving some deeper looks at core data structures and interfaces.

Syzbot is never going to catch these kinds of issues, the combinatorial explosion is too big when you've got arbitrary drivers and modules and filesystems communicating via struct page handoff with unclear and undocumented invariants.

The project to start properly typing the subtypes of struct page in the struct folio conversion got as far as folio_slab and then stalled - what was sold as "we're going to clean this stuff up" changed focus to "yeah we just care about performance" once the initial excitement died down.

Fun times.

People should be paying attention to the role of splice in these bugs.

Posted May 15, 2026 5:29 UTC (Fri) by willy (subscriber, #9762) [Link] (5 responses)

> The project to start properly typing the subtypes of struct page in the struct folio conversion got as far as folio_slab and then stalled - what was sold as "we're going to clean this stuff up" changed focus to "yeah we just care about performance" once the initial excitement died down.

Just so everybody else knows, this is a lie.

People should be paying attention to the role of splice in these bugs.

Posted May 15, 2026 13:04 UTC (Fri) by koverstreet (subscriber, #4296) [Link] (4 responses)

Matthew, you don't take criticism well.

Back when you were getting folios merged, there were concerns raised by the mm community, primarily Johannes, and I argued vociferously for getting folios in because we needed it. But seeing how it's played out, he had a point.

I keep getting reports of nuttier and nuttier mm behavior - it's getting worse, not better, and there's not much I can do about it but attempt ugly workarounds, and I can't even work around the one you guys introduced in large folios where you forgot to include a range in .set_folio_dirty. Know what that does to mmap write workloads?

Tell me, has anyone looked at the interactions with large folios and splice?

People should be paying attention to the role of splice in these bugs.

Posted May 15, 2026 14:10 UTC (Fri) by koverstreet (subscriber, #4296) [Link]

> Tell me, has anyone looked at the interactions with large folios and splice?

To answer my own question, "yeouch". A lot of the obvious ones are awkwardly patched over in callers, but I expect this to be fruitful mining for security researchers.

Disabling CONFIG_TRANSPARENT_HUGEPAGE for the next six months might be smart.

People should be paying attention to the role of splice in these bugs.

Posted May 15, 2026 17:26 UTC (Fri) by willy (subscriber, #9762) [Link] (2 responses)

I don't owe you anything.

I'm not engaging with you. I'm just letting everybody else know that you're lying.

People should be paying attention to the role of splice in these bugs.

Posted May 15, 2026 18:18 UTC (Fri) by koverstreet (subscriber, #4296) [Link] (1 responses)

Matthew, everything I said was factually correct. It's right there in the code.

We've got zero-days coming out once per week, people are rushing to keep everything patched and evaluating how to mitigate, and you're lashing out and deflecting. I've seen you do it to other people too.

This does not bode well.

Everyone's code, my own included, has issues. I quite regularly have to communicate to people the state things are in and what they can expect. You don't have to take it as an attack.

Stop here

Posted May 15, 2026 18:31 UTC (Fri) by jzb (editor, #7867) [Link]

This is a fine space to discuss the technical details of these bugs; but let's not make it personal. It is not necessary and not what our comment section is for.

People should be paying attention to the role of splice in these bugs.

Posted May 14, 2026 18:05 UTC (Thu) by wtarreau (subscriber, #51152) [Link]

There will inevitably be a few more, for the time it takes to find them all in the same class and after that it will be calm again. Instead I'd rather bet we'll get a few more in the next two months then no more for some time. I personally don't count the last recent 3 or so LPE as 3 but as one because it's one class of bugs that causes users to rush updates.

People should be paying attention to the role of splice in these bugs.

Posted May 15, 2026 22:07 UTC (Fri) by azz (subscriber, #371) [Link]

> However doing this as a config option won't work: distros will need to keep it enabled due to the numerous users.

That depends on the distro. For hardening an embedded device, where you really don't want to be doing frequent kernel updates if you can avoid it, turning off kernel features that your application doesn't need is good hardening practice - and I'd imagine there are a decent number of embedded applications that could live without splice and friends (and ptrace and friends, for that matter).

People should be paying attention to the role of splice in these bugs.

Posted May 13, 2026 19:04 UTC (Wed) by mussell (subscriber, #170320) [Link]

There's no LSM hook for splice, so SELinux/AppArmor/etc. can't restrict access to it and it proves your point about subsystems not considering it. seccomp would work, but only if you also disable io_uring as well since you can call splice through that.

Thankfully using both an LSM and seccomp to limit creating user namespaces is enough to mitigate this exploit and all the others.

People should be paying attention to the role of splice in these bugs.

Posted May 13, 2026 19:24 UTC (Wed) by DemiMarie (subscriber, #164188) [Link] (2 responses)

Where does splice help here compared to sendfile?

People should be paying attention to the role of splice in these bugs.

Posted May 13, 2026 19:47 UTC (Wed) by hailfinger (subscriber, #76962) [Link] (1 responses)

sendfile() used to be restricted to sending from a file to a pipe, whereas splice() used to be more generic. Nowadays sendfile() uses splice under the hood for some use cases.

From the sendfile() man page:
> The in_fd argument must correspond to a file which supports mmap(2)-like operations (i.e., it cannot be a socket). Except since Linux 5.12 and if out_fd is a pipe, in which case sendfile() desugars to a splice(2) and its restrictions apply.

And yes, this has implications for suggested mitigations of most/all recent splice-class bugs.

People should be paying attention to the role of splice in these bugs.

Posted May 13, 2026 23:19 UTC (Wed) by azz (subscriber, #371) [Link]

Looking at the code, both cases in sendfile are implemented using splice (for which pipes are representations of in-kernel buffers) - if the output is a pipe, it uses splice_file_to_pipe to copy directly to it, otherwise it uses do_splice_direct which constructs a pipe and copies through it. Other bits of code use do_splice_direct too, e.g. the copy_file_range syscall and overlayfs.

Fedora updates

Posted May 13, 2026 19:32 UTC (Wed) by AdamW (subscriber, #48457) [Link]

Fedora updates are currently in testing.

Fedora 43: https://bodhi.fedoraproject.org/updates/FEDORA-2026-cccb6...
Fedora 44: https://bodhi.fedoraproject.org/updates/FEDORA-2026-4462e...

Ditch authencesn?

Posted May 13, 2026 19:55 UTC (Wed) by DemiMarie (subscriber, #164188) [Link]

authencesn seems to be used in a lot of these attacks. Time to mark it as BROKEN?

I'm tired of this

Posted May 13, 2026 22:11 UTC (Wed) by jpeisach (subscriber, #181966) [Link] (7 responses)

If AI is so good at detecting security bugs, why not we just have it patch them all in one go?

I'm tired of this

Posted May 13, 2026 22:16 UTC (Wed) by mb (subscriber, #50428) [Link] (6 responses)

That's what is actually happening right now.
You just have to realize that it takes some time to run AI agentic workflows on a code base. The time required is not instant.
It takes time and money to run AI agentic workflows.

I'm tired of this

Posted May 13, 2026 22:18 UTC (Wed) by jpeisach (subscriber, #181966) [Link] (4 responses)

> That's what is actually happening right now.

It looks a lot more like only reporting the bug and not providing a patch - or if they do, it's not all together. I'm proposing the patches be *unified* so it can just be "security fix patch for $module". That may be an issue for the sake of being able to bisect, but at least maybe get all the patches in together at the same time, so it isn't one bug after another?

I'm tired of this

Posted May 13, 2026 22:23 UTC (Wed) by mb (subscriber, #50428) [Link]

>I'm proposing the patches be *unified*

There's significant time between issues found, even if they are related.
Therefore, unification would be extremely dangerous. And it has always been.
Embargoes don't work.

If it's known to be a problem, fix it. Waiting is a problem and has always been.

I'm tired of this

Posted May 14, 2026 5:44 UTC (Thu) by wtarreau (subscriber, #51152) [Link] (2 responses)

> It looks a lot more like only reporting the bug and not providing a patch - or if they do, it's not all together.

That's what the security team is systematically asking for, and it's working increasingly well. What remains annoying is that probably half of the reports provide a "suggested fix" that only lacks the diff format and a commit message, so we're all the time asking them to turn that into a real patch. But yes, it is becoming quite frequent.

I think that right now there is a race between reporters, and when they find an issue, they don't want to waste time on a patch yet, they want to be the first ones to report it because they know it's a matter of hours before someone else reports it. *This* is what makes the situation really painful these days.

I'm tired of this

Posted May 14, 2026 10:52 UTC (Thu) by MarcB (subscriber, #101804) [Link] (1 responses)

> I think that right now there is a race between reporters, and when they find an issue, they don't want to waste time on a patch yet, they want to be the first ones to report it because they know it's a matter of hours before someone else reports it. *This* is what makes the situation really painful these days.

You also only see the reporters that want to genuinely help, or at least those that are just going for fame. But if those can find the bugs via LLMs, then so can criminals and spies. Given that LLMs had their current capabilities for quite some time before the recent uptake in reports, I suspect that he situation actually has not changed that much, its just that the change has now become more visible.
Also keep in mind, that all the bugs found via LLMs could equally be found by people, given enough time, skill and money. It is entirely possible, professional attackers were ahead all along (more than the few well-known exploit traders), and we are just now learning how bad the situation actually is.

I'm tired of this

Posted May 15, 2026 5:02 UTC (Fri) by wtarreau (subscriber, #51152) [Link]

This is *exactly* why we're trying to move most of them to public lists and have recently updated the reporting process to encourage them to do so. There's no point in keeping reports private and trying to elaborate a fix in a reduced team with limited testing abilities if criminals or determined researchers can also find them.

I'm tired of this

Posted May 14, 2026 15:52 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link]

It also takes time and effort to turn knowledge of a bug into a fix, run it through quality control, and get it to users. There is a finite pool of resources devoted to sending out fixes, and it looks very much like the LLMs are finding bugs faster than the patch pipeline can fix them.