i have a different point of view in this case. ‘copy-fail’ was this ai-discovered exploit and the ‘discoverer’ of ‘copy-fail’ broke the embargo but that caused a human-kind to check in and have a deeper view and discovered that there are quite much more leaks and vulnerabilities what we call now ‘dirty-frag’. i expect that there is much more upcoming in these days and without breaking the embargo ? i suspect the ‘copy-fail’-bug had been fixed without deeper examing the problem. every coin has two sides.
Well, if we look at Ubuntu and how they handled it so far:
- Fixes available for CVE-2026-31431 (Copy Fail) Linux Kernel Local Privilege Escalation Vulnerability | Ubuntu
- Dirty Frag Linux kernel local privilege escalation vulnerability mitigations | Ubuntu
The issue I see there is that they just post about the known mitigations but didn’t patch their kernels yet. Most Ubuntu versions are old and don’t get proper updates, unless you pay for it. There sysadmins have to locally patch or execute cmds to mitigate the issue until upstream provides needed patches.
Due to ABI rules on Ubuntu, those patches then have to be vetted by Ubuntu kernel engineers into their kernel source trees and retested. That is why you won’t see point-release versions of an Ubuntu Kernel: 7.MINOR.0-ABI.UPLOAD-FLAVOUR as in: 7.0.0-13.13-generic. There as admin you have to look at the changelog and cat /proc/version_signature to get the correct point-release version. Super frustrating! Even Canonical claim to support 7.0 series until 2031 on their end, they always have to backport upstream patches to their kernel tree.
just to remind all of us, a lot of iot-devices and especially ROUTERS using linux. don’t miss to update them asap.
I realize it’s a big security risk but Im not going to mess around with mixing stuff from unstable and potentially breaking my system. Will wait for the stable update.
In the meantime I’ll try to be more careful with the internet.
As long as you don’t require the modules the temporary mitigation from the first post is a good solution without using unstable. It is easy to apply and as easily removed (just delete the file that gets created).
you might have trouble when blacklisting the modules with vpn-servers. this code must be executed locally on a pc so you should be o.k. (not safe) if you’re running trusted code. the problem is this ‘trusted’ in itself. we’ve seen a lot of malicious code injections on github in the past months, a lot of daisy-chain-attacks and so forth. it’s not a good idea to downplay this security-flaw, especially cause no-one can predict if there are more vulnerabilities with this modules on the rise. if you’re running server-based systems the danger is much more worse. my impression is that it’s just the tip of the ice-berg.
anyhow, stay alerted if you’re running ‘cheap’ iot-devices like surveilance-cams etc. that are well known for easy access and router using web-based applications to configure/access the router. unfortunately a lot of this devices are already scrap cause the vendors often act with this ‘sale and forget’ mentality without any updates.
For anyone who thinks this issue isn’t one to be too concerned about, I found this article in my RSS reader yesterday, and it makes it very easy to understand what Dirty Frag does:
So, unless you have a very good reason not to, implement the recommended temporary mitigation until you can install a patched kernel:
Stable branch is undeniably very stable and immune to breakages, but unstable isn’t at all ‘Unstable’ as the name would suggest..
I have been using unstable for a while, I never came across any breakages… Only thing to avoid is non-stable kernels that are being developed and are experimental.
Currently there doesn’t seem to be any major bugs that could cause ‘system breakages’ at least on Plasma variant as long as not using niche AUR packages… And there’s also Timeshift just in case.
I have been using unstable branch since 2017 - I have never had issues I didn’t cause myself.
One should always be careful with that one - there is useful content but it is largely untrustworthy and a source that must be verified.
Switched to unstable , updated and got a black screen on both 7.0 and 6.18 , probably due to Nvidia drivers . Rolled back with Timeshift , installed 7.1 so I could remove the other two kernels , 7.1 did not show up in GRUB , still showing 7.05 and 6.18 updating GRUB did not work . Rolled back again , switched to stable branch , installed 7.1 again and re-installed GRUB .Rebooted , installed 7.0 removed 7.1 rebooted with 7.0 . Ran the workaround .Running normally now . Had my fun for this morning , before I finished my first cup of coffee . ![]()
Wouldn’t work on my system, because I’ve modified PAM to require a minimum password length of 8 characters. Or at least, I think so, because I might have made that 14 characters — I’ll have to check.
Ergo, blank passwords are not allowed on my machine, and I’ve also further tightened up security in different ways, even though those in and of themselves would not preclude the abuse of /usr/bin/su.
Nevertheless, I’ve applied the workaround posted higher up. ![]()
more patches incoming;
rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present
https://cdn.kernel.org/pub/linux/kernel/v7.x/ChangeLog-7.0.6
addendum; its apparently fully mitigated
After Linus accepted the rxrpc fix by Hyunwoo Kim, there is still work ongoing. David Howells is working on some improvement on the current fix. Same is Hyunwoo Kim doing after some feedback on his original fix, which seems incorrect …
Well, even after Greg told everyone it is resolved, fixes are still incoming …
![]()
everyone should take greg’s announcement with a grain of salt. fixed ? i doubt cause we don’t know what bugs related to the modules are still coming. @philm: it would be nice if kernel 7.0.6 would be deployed since it seems that this kernel has the actual bugfixes while 7.0.5 is only partial cleaned.
There is no need for 7.0.6 as our versions had that fix longer than upstream. I dont build kernels just for a version bump when new kernels are scheduled for tomorrow already!
So which versions of the Manjaro kernels have the dirty.frag patches? Does 6.18.28-2 that’s currently in testing have the patches?
Kernel 6.18.28-2 has 2 patches:
PKGBUILD - [pkg-upd] 6.18.28-2 (5ac9b11f) · Commits · Packages / core / linux618
# https://lore.kernel.org/all/af2kdW2F1gJ9U-Gg@v4bel/ 0001-dirty-frag-rxrpc-fix-from-netdev-list.patch # https://lore.kernel.org/all/agDTmXM2wXnJflYc@v4bel/ 0002-dirty-frag-rxrpc-fix-from-netdev-list.patch
Does that mean that 6.18.28-2 is fully patched against dirty frag? @koshikas mentions above that 7.06 is full patched against dirty frag, but then @philm mentions a few posts up that people are still working on improvements. And I sitll don’t understand if 6.18.28-2 has all the same patches in it as 7.06 and 6.18.29-1, which are currently in the Arch repos (and I guess the latest upstream kernels?).
it’s a fight against windmills. there’s already the next exploit based on the ‘dirty frag’ bug.
imo not an bug but a systemic-design-flaw of the mechanism itself and i’m convinced that it needs more than a patch. this modules and the mechanism needs a better and safer redesign.
you’re not the only one and it gets worse if you check the announcements of other distributions. there is total confusion about what kernel is patched or not… 5 distros → 10 opinions… total turmoil
no, the only way/workaround by now is to blacklist these 3 modules as described and wait till there’s a real solution. that should work for the main-number of users. it gets problematic if you wanna use vpn-providers and server-based systems where you might need this modules.
For now it is best to blacklist these modules as non of existing kernels are probably patched. The old exploit might not work no more, however newer variants still work on so claimed fixed kernels.
As a distribution we can only patch it downstream to only find out that the new patch gets a new revision or only partly fixed the issue.
You can read the engineers comments on each attempt: