CopyFail Was Not Disclosed to Distros
117 points by ori_b 3 hours ago | 61 comments

xeeeeeeeeeeenu 2 hours ago
For context, the author of the linked post, Sam James, is a Gentoo developer.

Anyway, this is a disaster. It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. Who knows how many shared hosting providers were hacked with this.

It's also worrying that it seems there's no communication between the kernel security team and distribution maintainers. One would hope that the former would notify the latter, but apparently it's the responsibility of whoever finds the vulnerability.

reply
lifis 5 minutes ago
The Linux kernel is not usable as a security boundary, so anyone who wants to do "shared hosting" and not be hacked needs to use something else, like gVisor or firecracker VMs
reply
zamalek 24 minutes ago
The disclosure was more about marketing than security. From the disclosure page:

> Is your software AI-era safe?

> Copy Fail was surfaced by Xint Code about an hour of scan time against the Linux crypto/ subsystem. [...]

> [Try Xint Code]

More chaos makes their product seem even more attractive.

reply
esseph 23 minutes ago
Your advertising for them on HN would help them too, I bet.
reply
jasonmp85 9 minutes ago
Does it? Now that I see their name again in this context they're blacklisted for life.
reply
CSSer 8 seconds ago
Yes, exactly. Name and shame.
reply
shimman 57 minutes ago
Expecting people to do the right thing is a fundamental issue here. Why would you ever expect for all of vulnerabilities to be disclosed privately? There's very little actual incentive to do this.

I'm honestly unaware of what systems could be put in place to prevent this but expecting people to always do the right thing is fantasy level thinking. I mean I bet the disclosers that they would during the right thing, hence why it's a bad thing to rely on.

reply
dwedge 40 minutes ago
When the exploit is an advertisement for an exploit detection company, not doing the right thing is a bad look
reply
dgellow 32 minutes ago
The worst thing would be to exploit or sell it for profit. Instead of that, publicizing the exploit is closer to neutral–good in my books, that did trigger a really quick reaction from the different actors to patch their kernels and systems
reply
ori_b 21 minutes ago
Imagine how much quicker the distros would have reacted if they were given a heads up a month ago. But, sure, I guess kudos to this company for not being actively criminal, and merely bumblingly incompetent and overly eager to get their marketing pitch out the door.
reply
egonschiele 26 minutes ago
Why don't all these distro maintainers add their own back doors, and mine crypto off our machines without our knowledge? Surely, there is some legal fine print they can add that would let them do that. There is very little incentive for them to maintain these systems, given how thankless and underpaid the work is.
reply
holowoodman 50 minutes ago
I can accept (and welcome) disclosure before there are patches.

But publishing a working exploit together with the disclosure before patches are available is really really irresponsible, maybe even criminal.

And no, the proposed mitigations don't help with half of the distributions out there...

reply
akerl_ 16 minutes ago
> maybe even criminal

What’s your theory here? What crime?

reply
michaelmrose 7 minutes ago
If it's not a crime I see no reason not to work with partner nations to build responsible disclosure into a legal framework everywhere because it pretty obviously should be.
reply
akerl_ 3 minutes ago
If you wanted to somehow make coordinated disclosure into a legal framework, that would be an interesting and complex project.

But it’s not the law anywhere I’m aware of today, and I’d not support it becoming a law.

reply
SoftTalker 22 minutes ago
AIUI the exploit was fairly low-effort once you knew the vulnerability. So publishing one probably didn't change the landscape much.
reply
wang_li 35 minutes ago
There is an alternative mitigation you can use which blacklists the function calls when the affected code is not built as a kernel module.
reply
semiquaver 46 minutes ago
Patches were available for nearly a month.
reply
ori_b 43 minutes ago
Basic care would involve making sure the patches had made it into the wild before ending the embargo, and nagging the relevant parties if not.

Edit: As of this writing, most distros including Redhat, Fedora, Debian Stable, do not have patches available in the package repos, though they're being actively worked on.

reply
sgjohnson 36 minutes ago
Not true, if there’s any evidence of the exploit being used in the wild, it’s much more responsible to release immediately.

Considering that the patches have been available for a while, someone surely reversed what they were for and was actually exploiting this in the wild.

In the age of AI, I’d argue that “responsible disclosure” is dead. Arguably even in closed source projects. Just ask Claude to do a diff between the previous version and to see whether anything fixed in there could have had security implications.

We’re not there yet, but very soon the only way to responsibly disclose a vulnerability will be immediately.

reply
ori_b 10 minutes ago
But they didn't release immediately -- they waited a month, but forgot to tell the distros, and forgot to check if waiting a month had actually lead to distros picking up the patches and shipping them.
reply
semiquaver 38 minutes ago
“Made it into the wild?” Patches landed a month ago. Should they also wait until my linksys router from 2018 has a patch ready?
reply
ori_b 35 minutes ago
Patches are still in the process of landing in most major distros as of the time of this writing. Most users are not able to get an update through their distro's packaging mechanisms.
reply
SoftTalker 18 minutes ago
It's a local vulnerability at least. How many people do you let log in to your router?

With the way linux is used these days, I'd guess the number of systems with untrusted local users is pretty limited. Even with shared hosting, you generally have root in your VM or container anyway. Unless this enables an escape from that?

Still the risk that people who run "curl | bash" without care could get bitten, but usually its "curl | sudo bash" anyway...

reply
sgbeal 6 minutes ago
> Even with shared hosting, you generally have root in your VM or container

Lots of shared hosters don't use VMs or containers. It's some arbitrary number of people logging in to a shared system, each one with a home directory under /home/THE_USER_NAME. i've had several such hosters over the years (thankfully not right now, though).

reply
michaelmrose 7 seconds ago
Local root is part of the path to escaping
reply
GrayShade 8 minutes ago
Fedora is patched.
reply
em-bee 10 minutes ago
only for versions 6.19.12 & 6.18.22. older versions (which are used in distributions) are not ready yet.
reply
baggy_trough 55 minutes ago
Why wouldn't the linux security team notify the main linux distributions?
reply
bonzini 18 minutes ago
Partly they already have enough on their plate. It's up to the reporter to pick how to handle the disclosure, and unless a specific maintainer chooses to handle it, the Linux security team clearly says they won't.

Partly they have a strong belief that all kernel bugs are vulnerabilities and all vulnerabilities are just bugs; sometimes taken to the extreme in both ways (on one hand this case where the vulnerability is almost ignored; on the other hand, I saw cases where a VM panic that could be triggered only by a misbehaving host—which could just choose to stop executing the VM—was given a CVE).

reply
skywhopper 50 minutes ago
I think it’s reasonable to expect folks in the security community who go to the trouble of creating a website detailing security vulnerabilities in specific listed software to pre-notify the security teams of that software. The CopyFail website calls out Ubuntu and Red Hat specifically, but apparently the author of the site did not inform them of the issue?

But even if you think making unethical decisions in personal self interest is something no one should be criticized for, surely the Linux kernel team ought to have some process for notifying the top distributions of an upcoming LPE, just out of practicality.

reply
semiquaver 45 minutes ago
In what sense do you believe that the reporter did not notify the security team of the relevant software? The vulnerability is in the kernel. Reporter responsibly disclosed using the kernel’s security report mechanism and waited until a patch was ready.

Distros are downstream of kernel, that doesn’t entitle them to expect to be contacted directly by every security reporter. That’s not on them. Distros that are big enough should be plugged into the linux security team for notifications.

Security researchers cannot be held responsible for broken lines of communication within the org charts of projects that they study. They’re providing a valuable public service already, how much more do you want?

reply
ragall 31 minutes ago
> that doesn’t entitle them to expect to be contacted directly by the reporter

Yes it does. That's how it's always been done and distros can ship a fix well before it ends up in a kernel release.

reply
999900000999 11 minutes ago
Counterpoint. End users have a right to mitigate this issue on their systems.

It is a really really bad look for Linux, puts a bit of water on all hype around switching from Windows.

reply
roxolotl 3 minutes ago
It does? The disclosure even says the concern for single user systems is very low. If someone has access to your single user system, remote or otherwise, you’ve already lost on the sort of device people would be switching from windows to Linux on.
reply
weavejester 3 minutes ago
Hype around switching from Windows servers?
reply
vhantz 3 minutes ago
As opposed to all other operating systems with no CVEs ever?
reply
jasonmp85 9 minutes ago
[dead]
reply
akerl_ 19 minutes ago
Who knows how many attackers had found this vulnerability and had already been using it prior to this research finding it?
reply
Quarrelsome 13 minutes ago
well now everyone does, so the irresponsible disclosure makes it significantly worse.
reply
akerl_ 12 minutes ago
It’s your opinion that it’s irresponsible and that it makes something worse.
reply
Quarrelsome 8 minutes ago
and its your opinion that it doesn't. Shall we continue stating the obvious? We are communicating using glyphs. This language is English. We are on Hacker News. This branch of the conversation is extremely unproductive.
reply
akerl_ 4 minutes ago
I asked a question and you replied with a statement. Your statement didn’t frame itself as an opinion but as fact.

The hilarious bit is that the idea that they needed to coordinate is clearly broken even in just this example. They did give prior notice to the Linux developers, who issued a patch. And they’re still getting raked over the coals in this comment page by armchair quarterbacks who have decided they needed to coordinate with specific distros. If they’d coordinated with those distros, somebody would have a pet distro that didn’t make the cut and they’d be pissed about that.

There are risks no matter how they do it, and there will be people who are pissed no matter how they do it. Security researchers don’t owe anybody a specific methodology.

reply
deng 20 minutes ago
> It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix.

Yes, this was clearly a marketing stunt to promote Xint code.

I, for one, will never use Xint code and will advise everyone to never use it. To anyone working there: enjoy your 15 minutes, I hope this backfires right in your face.

reply
semiquaver 53 minutes ago
> Note that for Linux kernel vulnerabilities, unless the reporter chooses to bring it to the linux-distros ML, there is no heads-up to distributions.

Why would they imply it is incumbent on the reporter to liaise with distributions? That seems to assume a high level of familiarity with the linux project. Vulnerability reporters shouldn’t be responsible for directly working with every downstream consumer of the linux kernel, what’s the limiting principal there? Should the reporter also be directly talking to all device manufacturers that use Linux on their machines?

IMO reporter did more than enough by responsibly disclosing it to linux and waiting for a patch to land.

Aren’t there people in the linux project itself with authority over and responsibility for security vulnerabilities? One would think they would be the ones notifying downstream distros…

reply
sega_sai 46 minutes ago
The reporter took time to check and mention on their website specific distributions Ubuntu/RHEL/SUSE. One would have thought reporting to security teams of at least those would be responsible.
reply
semiquaver 35 minutes ago
“One” would have thought? Can you point to a written policy that says that’s how it should be?
reply
happyopossum 22 minutes ago
No, not can I point to a written policy that states one should cover one’s mouth when they cough.

Everyone involved here failed to do the right thing, and hiding behind the lack of written words is weak sauce.

reply
anikom15 28 minutes ago
The tenets of decency don’t need to be written down.
reply
tob_scott_a 21 minutes ago
If you can't write it down, why would you expect it to be universal and enforceable? Different cultures exist and have different opinions on what "decency' means, after all.

A security researcher's ethical obligations are to protect users over vendors (barring any contractual agreement in place). From what has been discussed in this thread, they meet that bar.

Sure, they could have gone the extra mile to ensure the distros were in a good place to patch before they published the exploit. That's a kindness you can wish for, but don't disparage them for not going that extra mile. It's a bonus.

It's also possible that it simply didn't occur to them to do so this time. There's certainly lessons to be learned either way. I don't know that the right lessons will emerge from hostility.

reply
Quarrelsome 11 minutes ago
> If you can't write it down, why would you expect it to be universal and enforceable?

and this is the problem. It used to be the case that if you were smart enough to find an exploit you were also smart enough to realise what would happen if you irresponsibly disclosed it. I guess these tools have made that pattern no longer apply.

reply
scragz 9 minutes ago
different cultures have different views on disclosing vulnerabilities to distros before the public?
reply
froh 3 minutes ago
it's trivial to find out how to report a security issue like this to Linux distros.

Google search: https://share.google/aimode/eihDKXZJy94Z5lC1p

and it's beyond me to not think about doing this and instead exposing everyone and their neighbor to this exploit up front.

I'm certain this is even a felony in some legislations, rightfully so.

reply
sparker72678 48 minutes ago
Sure, maybe it's not a _requirement_, but now we're all in more pain because the reporters are more interested in Fame than Safe Remediation.
reply
skywhopper 47 minutes ago
The reporter made a website explicitly calling out Ubuntu, RedHat, Amazon, and SUSE but didn’t notify them, and you think that’s reasonable? That they might not have known those distributions are downstream from the kernel team?
reply
ectospheno 58 minutes ago
The Bleeping Computer link below mentions a potential remedy until a patch is ready.

https://www.bleepingcomputer.com/news/security/new-linux-cop...

reply
jayofdoom 53 minutes ago
This workaround only applies to kernels with the impacted code compiled as a module. RHEL, Fedora, and Gentoo (we use a modified Fedora config) all are configured to build this in directly. Without a patch or config change (as Sam from Gentoo was alluding to), those distributions remain vulnerable.
reply
jcul 34 minutes ago
There was some discussion on the GitHub issues about workarounds to disable it, even though it is baked in.

https://github.com/theori-io/copy-fail-CVE-2026-31431/issues...

https://github.com/theori-io/copy-fail-CVE-2026-31431/issues...

reply
pitrdevries 19 minutes ago
This worked as a mitigation on distros with the module compiled into the kernel: https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464d...

Basically: sudo grubby --update-kernel=ALL --args=initcall_blacklist=algif_aead_init

sudo reboot

reply
holowoodman 52 minutes ago
The potential remedy doesn't work on RedHat and derivatives because the affected code is not a module there but statically compiled in.
reply
uberduper 39 minutes ago
`initcall_blacklist` is a thing.
reply