If your kernel was built between 2017 and the patch — which covers essentially every mainstream Linux distribution — you're in scope.
Copy Fail requires only an unprivileged local user account — no network access, no kernel debugging features, no pre-installed primitives. The kernel crypto API (AF_ALG) ships enabled in essentially every mainstream distro's default config, so the entire 2017 → patch window is in play out of the box.
Not a call-out, but just to share information if anyone doesn't know: - hyphen: shortest, the one on most keyboards, used to hyphenate words or to replace en or em dashes – en dash: shorter (width...
Not a call-out, but just to share information if anyone doesn't know:
- hyphen: shortest, the one on most keyboards, used to hyphenate words or to replace en or em dashes – en dash: shorter (width of the 'N' character), used to show ranges between numbers or dates — em dash: longer (width of the 'M' character), used in lots of ways but mostly like a colon or as parentheses around a phrase
LLMs use both en and em dashes more than most people, especially on the internet where it's commonplace to just use a hyphen instead.
As a frequent user of em dashes (but not en dashes, eww those are weird), I resent that my grammatical sophistication is now being used to discredit me!
As a frequent user of em dashes (but not en dashes, eww those are weird), I resent that my grammatical sophistication is now being used to discredit me!
Dashes, hyphens, commas, and parenthesis use are all my favorite ways to trail off into other topics in the middle of a sentence. Happens when you have 7 trains of thought going around at the same...
Dashes, hyphens, commas, and parenthesis use are all my favorite ways to trail off into other topics in the middle of a sentence. Happens when you have 7 trains of thought going around at the same time, right?!
Out of curiosity, why and how? The hyphen is the only one on the keyboard, so why not just roll with that one? Do you have the ALT+code memorized, or is there some other shortcut?
Out of curiosity, why and how? The hyphen is the only one on the keyboard, so why not just roll with that one? Do you have the ALT+code memorized, or is there some other shortcut?
When you're writing markdown that gets converted to HTML, you can insert an en dash with -- and an em dash with ---. I also use them quite a bit in my writing—but now I second guess myself for...
When you're writing markdown that gets converted to HTML, you can insert an en dash with -- and an em dash with ---. I also use them quite a bit in my writing—but now I second guess myself for fear that I'll come off sounding like an AI.
I’m on a Mac; it’s shift-option-hyphen. That’s not so hard. I memorized it back when dinosaurs roamed the earth and now it’s muscle memory. When I’m not on my Mac, I’m on my iPhone where it’s even...
I’m on a Mac; it’s shift-option-hyphen. That’s not so hard. I memorized it back when dinosaurs roamed the earth and now it’s muscle memory. When I’m not on my Mac, I’m on my iPhone where it’s even easier — just long-press on the hyphen key and tap it in the little pop-up menu. Also (I never do it this way) you can type two hyphens and it will autocorrect them into an em dash.
We can debate whether it’s good that I care about the difference between a hyphen and an em dash… but I do care! Hyphens are nice and short little bridges between related terms, and em dashes are sufficiently loooong that they read as an actual pause. I appreciate when text includes little cues like that, and I try to use them myself.
If you want to level up, there are options; consider the underused and misunderstood semicolon! Unless you’re using em-dash pairs within a sentence — to wander over to another thought and then...
If you want to level up, there are options; consider the underused and misunderstood semicolon! Unless you’re using em-dash pairs within a sentence — to wander over to another thought and then come back — then most ways you use the em-dash can probably be substituted with a semicolon.
(Apologies to all the superior language wizards who reply to me if I’ve accidentally summoned Cunningham’s Law)
Come on, man— I do it all (except the en dash; it can die in a fire for all I care!) with aplomb: There are few… precious few… punctuation marks I overlook in my day-to-day shitposting.
Come on, man— I do it all (except the en dash; it can die in a fire for all I care!) with aplomb: There are few… precious few… punctuation marks I overlook in my day-to-day shitposting.
I have been summoned. this very much will not result in appropriate semicolon use whatsoever, as many situations when people use em-dashes are setting apart things that are not complete clauses on...
(Apologies to all the superior language wizards who reply to me if I’ve accidentally summoned Cunningham’s Law)
I have been summoned.
then most ways you use the em-dash can probably be substituted with a semicolon
this very much will not result in appropriate semicolon use whatsoever, as many situations when people use em-dashes are setting apart things that are not complete clauses on their own and thus should not be separated by a semicolon under any of the typical rulesets for punctuation use in English.
But also semicolons are best used incredibly sparingly anyway and imo some AI tools like ChatGPT do already overuse them as well, so I don't see them as a way to avoid the issues of em dashes on that front either.
Yeah, unfortunately I think the whole page is AI generated (or at least edited by AI), but this seems to be a legit issue with an actual CVE and the page provides information on what devices are...
Yeah, unfortunately I think the whole page is AI generated (or at least edited by AI), but this seems to be a legit issue with an actual CVE and the page provides information on what devices are most at risk.
Seems like the vulnerability was also found by AI, or at least partly helped by it (as Xint Code seems to be mostly a swarm of AI agents doing code scanning).
Seems like the vulnerability was also found by AI, or at least partly helped by it (as Xint Code seems to be mostly a swarm of AI agents doing code scanning).
AI-assisted. The starting insight — that splice() hands page-cache pages into the crypto subsystem and that scatterlist page provenance might be an under-explored bug class — came from human research by Taeyang Lee at Xint.
From there, Xint Code scaled the audit across the entire crypto/ subsystem in roughly an hour. Copy Fail was the highest-severity finding in the run.
Even that question was answered by AI. It's AI all the way down. If the machines ever cotton on that we recognise their em-dash style and stop using it, we're sunk.
Even that question was answered by AI. It's AI all the way down. If the machines ever cotton on that we recognise their em-dash style and stop using it, we're sunk.
It's just a temporal artifact. The tells were different before, and I assume in a year the em-dashes will be gone. Hopefully there will be another tell, but I'm expecting different models, and...
It's just a temporal artifact. The tells were different before, and I assume in a year the em-dashes will be gone. Hopefully there will be another tell, but I'm expecting different models, and deployments of models, to begin applying slightly more variable styles to be more stealth. Seeing as companies like Anthropic are apparently big on undetected use. :(
This is a nitpick but em-dashes are one of the OG fingerprints and I'd be surprised to see them go completely. More recent are grating linguistic patterns "not like this, but like that", and lists...
It's just a temporal artifact. The tells were different before
This is a nitpick but em-dashes are one of the OG fingerprints and I'd be surprised to see them go completely. More recent are grating linguistic patterns "not like this, but like that", and lists of three.
There is an easy mitigation that won't affect most people. https://cert.europa.eu/publications/security-advisories/2026-005/ echo "install algif_aead /bin/false" >...
There is an easy mitigation that won't affect most people.
This workaround does not affect dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS, or SSH. It may affect applications explicitly configured to use the afalg engine or that bind aead/skcipher/hash sockets directly. Exposure can be assessed with lsof | grep AF_ALG.
So, relax a little, odds are you don't use this module, and you can disable it.
Careful that RHEL and some derivative have this thing compiled into the kernel and not a module, so disabling modprobe will not help. A comment down here mentioned a kernel cmdline that will...
Careful that RHEL and some derivative have this thing compiled into the kernel and not a module, so disabling modprobe will not help. A comment down here mentioned a kernel cmdline that will disable it.
I know the routine, I’ve been through it before with Heartbleed, Spectre/Meltdown, etc. I think we’re likely to be entering a new wave of a lot more of these hair-on-fire scrambles coming more...
I know the routine, I’ve been through it before with Heartbleed, Spectre/Meltdown, etc. I think we’re likely to be entering a new wave of a lot more of these hair-on-fire scrambles coming more frequently. On the bright side, I’m optimistic that once we reach the other side of that wave, the world’s critical software will be in a much more stable and secure state than it is now, and things should quiet down a lot. These are growing pains for the industry.
I’m now picturing some executive at NSA with a big whiteboard in their office with vulnerabilities listed, and every few days another one gets crossed out, and they’re just stressing over how...
I’m now picturing some executive at NSA with a big whiteboard in their office with vulnerabilities listed, and every few days another one gets crossed out, and they’re just stressing over how they’re gonna infiltrate <insert random enemy or ally>
I want to do more sleuthing, because I recall Linus getting quite mad at security bros around that time trying to push what he deemed unnecessary complexity into the kernel for little benefit. An...
I want to do more sleuthing, because I recall Linus getting quite mad at security bros around that time trying to push what he deemed unnecessary complexity into the kernel for little benefit.
Using AF_ALG introduces a new set on unexpected syscalls (network related syscalls, for a utility that ostensiblty does not touch the network).
Normally this is not a problem, but under some systemd or containers setup this could lead to unexpected problems.
This seems extremely scary in some cases. In the past I used a webhost that allowed SSH access to a system that was shared by multiple users (so you only had access to your home directory). With...
This seems extremely scary in some cases. In the past I used a webhost that allowed SSH access to a system that was shared by multiple users (so you only had access to your home directory). With this exploit, one could access and modify sites of anyone who also happened to be assigned to the same machine/VM.
I'm having a bit of trouble understanding: which kernel has the fix for this issue? Is it only 7.0 or later? I have a Fedora machine, Mint machine, and Steam Deck. All 3 are personal use and not...
I'm having a bit of trouble understanding: which kernel has the fix for this issue? Is it only 7.0 or later? I have a Fedora machine, Mint machine, and Steam Deck. All 3 are personal use and not servers or anything. On Fedora 43, the latest it gave me was 6.19.14, do I need to update to Fedora 44, or do I need to wait for the new update to ship? And what about Mint and SteamOS?
As far as I'm aware the only major distribution with a fix out in the wild is Proxmox. It'll likely be a minor revision number that you have, rather than a major version update, in terms of a...
As far as I'm aware the only major distribution with a fix out in the wild is Proxmox. It'll likely be a minor revision number that you have, rather than a major version update, in terms of a kernel fix. You can check if your system is vulnerable like this:
lsmod | grep algif_aead # no output means your kernel is safe
grep API_AEAD=m /boot/config-$(uname -r)# output here means that you can apply the workaround belowecho -e 'blacklist algif_aead\ninstall algif_aead /bin/false' > /etc/modprobe.d/copy-fail.conf
update-initramfs -u
reboot
This has caught the world by surprise, so everyone's in a bit of a hurry to apply the relevant patch, but they'll be out soon enough. It sounds like you've just got a handful of single-user machines, so your risk is much lower than say a multi-user server. Remember that access to a given machine is required to make this exploit work.
The fix was quietly merged in at the start of the month so rolling release distros and those which frequently update their kernel have been patched. The distros doing "stable"/"LTS" branches on...
The fix was quietly merged in at the start of the month so rolling release distros and those which frequently update their kernel have been patched. The distros doing "stable"/"LTS" branches on the other hand are generally not patched and are working out how to backport it to their older kernel versions.
Arch has had the fix for a while since they keep their kernel up to date.
NixOS has had patched kernels available if you used linux-latest, linux-6_18 or linux-6_19 which admittedly is not the default but is pretty common.
Ahh, good point! At my workplace we don't really mess with rolling release distros. Debian, Ubuntu, Proxmox, RHEL, CentOS, Rocky, and Suse are the main ones for us. So I actually just completely...
Ahh, good point! At my workplace we don't really mess with rolling release distros. Debian, Ubuntu, Proxmox, RHEL, CentOS, Rocky, and Suse are the main ones for us. So I actually just completely forgot about Arch et al. :P
grep API_AEAD= /boot/config-$(uname -r) For enterprise kernels where CONFIG_CRYPTO_USER_API_AEAD=y add initcall_blacklist=algif_aead_init to the kernel command line and reboot...
grep API_AEAD= /boot/config-$(uname -r)
For enterprise kernels where CONFIG_CRYPTO_USER_API_AEAD=y
To be clear, for the lsmod line, no output means you're safe to apply the fix and not safe from the vulnerability, yeah? Lsmod just lists what is loaded, the vulnerable module could still be...
To be clear, for the lsmod line, no output means you're safe to apply the fix and not safe from the vulnerability, yeah? Lsmod just lists what is loaded, the vulnerable module could still be loaded up.
I imagine it was fixed in 7.0, but has been backported to 6.19 and 6.18 as of the subversions 6.19.12 and 6.18.22. I would think that 6.19.14 has the fix- the distros have had over a month to...
I imagine it was fixed in 7.0, but has been backported to 6.19 and 6.18 as of the subversions 6.19.12 and 6.18.22. I would think that 6.19.14 has the fix- the distros have had over a month to respond to the CVE.
Seems my MX Linux 25.1 machines are not affected. No aead module in lsmod. Still checking other machines. Most of my machines are single user and low risk at least. However I do have a router and...
Seems my MX Linux 25.1 machines are not affected. No aead module in lsmod. Still checking other machines. Most of my machines are single user and low risk at least. However I do have a router and server I need to check.
Interesting to see when widespread modules like this have a flaw discovered because of the sheer breadth of devices affected.
If I understand this correctly, what you are saying doesn’t mean you aren’t vulnerable. It means you aren’t reliant on the module that makes you vulnerable so you can safely apply the mitigation....
If I understand this correctly, what you are saying doesn’t mean you aren’t vulnerable. It means you aren’t reliant on the module that makes you vulnerable so you can safely apply the mitigation. An exploit will simply load the affected module on demand to escalate.
Ah yeah that makes sense. I was just reading other comments saying how to check if one's kernel is safe and was doing that as a quick check on everything, but misunderstood. Sounds like applying...
Ah yeah that makes sense. I was just reading other comments saying how to check if one's kernel is safe and was doing that as a quick check on everything, but misunderstood. Sounds like applying the mitigation if a system has not received a patch for this flaw yet is still advisable then. While I've worked with Linux a long time, including in a professional capacity, not really in this aspect as much, and I hadn't dug into this at all in any detail. The more I'm wrapping my head around it the more it makes sense. Because yeah, if the module is present at all, then it could be dynamically loaded.
What I seem to be lacking is, is there a sure-fire way to verify if a system is already patched / no longer vulnerable? There seems to be lack of information on the method of doing so. The more I look the more I realize that it may just not exist.
Seems like just due to the nature of the issue, there's probably just not really any simple path (obviously there are more intense ones like running the PoC) to checking if a particular system is vulnerable or not outside of verifying if a particular kernel version one is on is simply affected or not. Especially since some systems build this module in instead of having it separate.
To me that makes sense post-mitigation, but not post-patch. My assumption (which may be wrong) would be that algif_aead will still load in a patched kernel, because actual patches are modifying...
To me that makes sense post-mitigation, but not post-patch.
My assumption (which may be wrong) would be that algif_aead will still load in a patched kernel, because actual patches are modifying the code in the module, not disabling the module altogether, whereas the temporary mitigation is to disable it
So if I'm thinking about this right-- a "fixed" algif_aead should still be able to load on a patched, no longer vulnerable system, without the (then unnecessary) "migitation" applied
Gotta get you Dark Reader! (It's a browser extension.) I didn't even realize this site didn't have a dark mode because DR did a solid job with it. Full disclosure, the results are kinda ugly maybe...
Gotta get you Dark Reader! (It's a browser extension.) I didn't even realize this site didn't have a dark mode because DR did a solid job with it.
Full disclosure, the results are kinda ugly maybe 40% of the time, but it's still better than being blinded by your screen turning into the surface of the sun out of nowhere.
Word of warning, i have had issues with it in the past where suddenly my browser slows to a crawl or straight up fails. It's been inconsistent over the years, and they've gotten better, but if you...
Word of warning, i have had issues with it in the past where suddenly my browser slows to a crawl or straight up fails. It's been inconsistent over the years, and they've gotten better, but if you get odd behavior start there.
I agree. Had to switch to Page Shadow because of problems with Dark Reader performance and breaking various pages (even when supposedly toggled "off" for that page). Apparently whether or not it's...
I agree. Had to switch to Page Shadow because of problems with Dark Reader performance and breaking various pages (even when supposedly toggled "off" for that page). Apparently whether or not it's toggled on for a particular site, Dark Reader still injects code into the page and some sites (especially higher security industries like banking) seem to flip out because of this injection (understandably so, really)
The kernel mailing list entry can be found here.
The em dash per sentence ratio is off the charts
Not a call-out, but just to share information if anyone doesn't know:
-hyphen: shortest, the one on most keyboards, used to hyphenate words or to replace en or em dashes–en dash: shorter (width of the 'N' character), used to show ranges between numbers or dates—em dash: longer (width of the 'M' character), used in lots of ways but mostly like a colon or as parentheses around a phraseLLMs use both en and em dashes more than most people, especially on the internet where it's commonplace to just use a hyphen instead.
As a frequent user of em dashes (but not en dashes, eww those are weird), I resent that my grammatical sophistication is now being used to discredit me!
Dashes, hyphens, commas, and parenthesis use are all my favorite ways to trail off into other topics in the middle of a sentence. Happens when you have 7 trains of thought going around at the same time, right?!
Out of curiosity, why and how? The hyphen is the only one on the keyboard, so why not just roll with that one? Do you have the ALT+code memorized, or is there some other shortcut?
When you're writing markdown that gets converted to HTML, you can insert an en dash with
--and an em dash with---. I also use them quite a bit in my writing—but now I second guess myself for fear that I'll come off sounding like an AI.I’m on a Mac; it’s shift-option-hyphen. That’s not so hard. I memorized it back when dinosaurs roamed the earth and now it’s muscle memory. When I’m not on my Mac, I’m on my iPhone where it’s even easier — just long-press on the hyphen key and tap it in the little pop-up menu. Also (I never do it this way) you can type two hyphens and it will autocorrect them into an em dash.
We can debate whether it’s good that I care about the difference between a hyphen and an em dash… but I do care! Hyphens are nice and short little bridges between related terms, and em dashes are sufficiently loooong that they read as an actual pause. I appreciate when text includes little cues like that, and I try to use them myself.
I have my dash of choice memorised.
If you want to level up, there are options; consider the underused and misunderstood semicolon! Unless you’re using em-dash pairs within a sentence — to wander over to another thought and then come back — then most ways you use the em-dash can probably be substituted with a semicolon.
(Apologies to all the superior language wizards who reply to me if I’ve accidentally summoned Cunningham’s Law)
Come on, man— I do it all (except the en dash; it can die in a fire for all I care!) with aplomb: There are few… precious few… punctuation marks I overlook in my day-to-day shitposting.
I have been summoned.
this very much will not result in appropriate semicolon use whatsoever, as many situations when people use em-dashes are setting apart things that are not complete clauses on their own and thus should not be separated by a semicolon under any of the typical rulesets for punctuation use in English.
But also semicolons are best used incredibly sparingly anyway and imo some AI tools like ChatGPT do already overuse them as well, so I don't see them as a way to avoid the issues of em dashes on that front either.
Ah, it was actually just a typo, but now I know that's called an en dash!
Yeah, unfortunately I think the whole page is AI generated (or at least edited by AI), but this seems to be a legit issue with an actual CVE and the page provides information on what devices are most at risk.
Seems like the vulnerability was also found by AI, or at least partly helped by it (as Xint Code seems to be mostly a swarm of AI agents doing code scanning).
From the FAQ:
Even that question was answered by AI. It's AI all the way down. If the machines ever cotton on that we recognise their em-dash style and stop using it, we're sunk.
It's just a temporal artifact. The tells were different before, and I assume in a year the em-dashes will be gone. Hopefully there will be another tell, but I'm expecting different models, and deployments of models, to begin applying slightly more variable styles to be more stealth. Seeing as companies like Anthropic are apparently big on undetected use. :(
This is a nitpick but em-dashes are one of the OG fingerprints and I'd be surprised to see them go completely. More recent are grating linguistic patterns "not like this, but like that", and lists of three.
There is an easy mitigation that won't affect most people.
https://cert.europa.eu/publications/security-advisories/2026-005/
So, relax a little, odds are you don't use this module, and you can disable it.
Careful that RHEL and some derivative have this thing compiled into the kernel and not a module, so disabling modprobe will not help. A comment down here mentioned a kernel cmdline that will disable it.
We're scrabbling at work to try and get this mitigated, what a mess.
I know the routine, I’ve been through it before with Heartbleed, Spectre/Meltdown, etc. I think we’re likely to be entering a new wave of a lot more of these hair-on-fire scrambles coming more frequently. On the bright side, I’m optimistic that once we reach the other side of that wave, the world’s critical software will be in a much more stable and secure state than it is now, and things should quiet down a lot. These are growing pains for the industry.
I’m now picturing some executive at NSA with a big whiteboard in their office with vulnerabilities listed, and every few days another one gets crossed out, and they’re just stressing over how they’re gonna infiltrate <insert random enemy or ally>
I want to do more sleuthing, because I recall Linus getting quite mad at security bros around that time trying to push what he deemed unnecessary complexity into the kernel for little benefit.
An older email advocating for keeping it disabled. (not Linus, but interesting)
This seems extremely scary in some cases. In the past I used a webhost that allowed SSH access to a system that was shared by multiple users (so you only had access to your home directory). With this exploit, one could access and modify sites of anyone who also happened to be assigned to the same machine/VM.
I'm having a bit of trouble understanding: which kernel has the fix for this issue? Is it only 7.0 or later? I have a Fedora machine, Mint machine, and Steam Deck. All 3 are personal use and not servers or anything. On Fedora 43, the latest it gave me was 6.19.14, do I need to update to Fedora 44, or do I need to wait for the new update to ship? And what about Mint and SteamOS?
As far as I'm aware the only major distribution with a fix out in the wild is Proxmox. It'll likely be a minor revision number that you have, rather than a major version update, in terms of a kernel fix. You can check if your system is vulnerable like this:
This has caught the world by surprise, so everyone's in a bit of a hurry to apply the relevant patch, but they'll be out soon enough. It sounds like you've just got a handful of single-user machines, so your risk is much lower than say a multi-user server. Remember that access to a given machine is required to make this exploit work.
The fix was quietly merged in at the start of the month so rolling release distros and those which frequently update their kernel have been patched. The distros doing "stable"/"LTS" branches on the other hand are generally not patched and are working out how to backport it to their older kernel versions.
Arch has had the fix for a while since they keep their kernel up to date.
NixOS has had patched kernels available if you used linux-latest, linux-6_18 or linux-6_19 which admittedly is not the default but is pretty common.
Ahh, good point! At my workplace we don't really mess with rolling release distros. Debian, Ubuntu, Proxmox, RHEL, CentOS, Rocky, and Suse are the main ones for us. So I actually just completely forgot about Arch et al. :P
For enterprise kernels where CONFIG_CRYPTO_USER_API_AEAD=y
add
to the kernel command line and reboot
https://www.openwall.com/lists/oss-security/2026/04/30/2
Thanks so much for the check! Looks like Fedora is safe. Haven't checked Mint or SteamOS yet.
To be clear, for the lsmod line, no output means you're safe to apply the fix and not safe from the vulnerability, yeah? Lsmod just lists what is loaded, the vulnerable module could still be loaded up.
I imagine it was fixed in 7.0, but has been backported to 6.19 and 6.18 as of the subversions 6.19.12 and 6.18.22. I would think that 6.19.14 has the fix- the distros have had over a month to respond to the CVE.
Seems my MX Linux 25.1 machines are not affected. No aead module in lsmod. Still checking other machines. Most of my machines are single user and low risk at least. However I do have a router and server I need to check.
Interesting to see when widespread modules like this have a flaw discovered because of the sheer breadth of devices affected.
If I understand this correctly, what you are saying doesn’t mean you aren’t vulnerable. It means you aren’t reliant on the module that makes you vulnerable so you can safely apply the mitigation. An exploit will simply load the affected module on demand to escalate.
Ah yeah that makes sense. I was just reading other comments saying how to check if one's kernel is safe and was doing that as a quick check on everything, but misunderstood. Sounds like applying the mitigation if a system has not received a patch for this flaw yet is still advisable then. While I've worked with Linux a long time, including in a professional capacity, not really in this aspect as much, and I hadn't dug into this at all in any detail. The more I'm wrapping my head around it the more it makes sense. Because yeah, if the module is present at all, then it could be dynamically loaded.
What I seem to be lacking is, is there a sure-fire way to verify if a system is already patched / no longer vulnerable? There seems to be lack of information on the method of doing so. The more I look the more I realize that it may just not exist.
Seems like just due to the nature of the issue, there's probably just not really any simple path (obviously there are more intense ones like running the PoC) to checking if a particular system is vulnerable or not outside of verifying if a particular kernel version one is on is simply affected or not. Especially since some systems build this module in instead of having it separate.
I think modprobe algif_aead should reliably return 1 if the module can't be loaded?
To me that makes sense post-mitigation, but not post-patch.
My assumption (which may be wrong) would be that algif_aead will still load in a patched kernel, because actual patches are modifying the code in the module, not disabling the module altogether, whereas the temporary mitigation is to disable it
So if I'm thinking about this right-- a "fixed" algif_aead should still be able to load on a patched, no longer vulnerable system, without the (then unnecessary) "migitation" applied
Feels good to be able to write a nix expression to assert that the kernel isn't vulnerable and move on with your day.
Off-topic, but I'm always annoyed at these completely white websites with text that can't implement a dark mode.
Gotta get you Dark Reader! (It's a browser extension.) I didn't even realize this site didn't have a dark mode because DR did a solid job with it.
Full disclosure, the results are kinda ugly maybe 40% of the time, but it's still better than being blinded by your screen turning into the surface of the sun out of nowhere.
Word of warning, i have had issues with it in the past where suddenly my browser slows to a crawl or straight up fails. It's been inconsistent over the years, and they've gotten better, but if you get odd behavior start there.
I agree. Had to switch to Page Shadow because of problems with Dark Reader performance and breaking various pages (even when supposedly toggled "off" for that page). Apparently whether or not it's toggled on for a particular site, Dark Reader still injects code into the page and some sites (especially higher security industries like banking) seem to flip out because of this injection (understandably so, really)
Usually I'll use Zen's boosts to get that fixed, but I've used Dark Reader. That should be on the website though.