Hacker News

>the reporter should not be the one responsible for reporting separately to every single downstream of the thing they found a vuln in.

Not "separately to every single downstream", there is the "linux-distros" mailing list for disclosures: https://oss-security.openwall.org/wiki/mailing-lists/distros

This random blogpost from 2022 serves as a proof that disclosing kernel vulnerabilities to the distros list is a well-known practice: https://sam4k.com/a-dummys-guide-to-disclosing-linux-kernel-...

I agree it's a shame that the process isn't more streamlined and the kernel developers aren't forwarding the reports to the distros list.

> a notification should have gone out from the kernel team to a curated list of distro security folk

Who would curate that list though? You don't need permission from the kernel team to spin up a new distro. I can go and create fork of Debian or Arch or whatever today and the kernel team would never know (and neither should they).

This is completely in the responsibility of the distros. If you don't like this model, use something like FreeBSD.

> they are in a much better position to coordinate and communicate with the maintainers than random reporters are.

They openly refuse to do this and have been given authority by MITRE to work against any such process.

Two things can be true simultaneously: the Linux kernel ecosystem should have done better at communicating this to their downstreams, and publicly sharing the exploit was irresponsible.

It is not the responsibility of the initial reporter to communicate to distributions, but the fact that those responsible failed to do that, doesn't give everybody else a free pass.

If the maintainers were unresponsive, sure -- but it seems slightly hard to buy that a responsible reporter trying to make a big splash and a good impression wouldn't first check "did this make it out to the distros?" before making sysadmin's days real shitty, even if technically they could point fingers at other parties. At which point, if they're paying paying any attention at all to what they reported, they may have realized that a mistake was made.

I worked at the industry's first commercial vulnerability lab (Secure Networks) in the mid-90s, and many of my friends at the time founded X-Force. Commercial vulnerability research has always been about marketing: marketing pays for the vulnerability research. That doesn't make it any less prosocial.

Your advertising for them on HN would help them too, I bet.

To be clear, the vulnerability existed in Linux, not in Xint Code. It existed whether this group disclosed it or not. Knowledge of it and exploits may have already been bought and sold among various groups with various motives including crime, terrorism, or cyberwarfare who likely made good money off it if this happened.

In that world, the vulnerability has more value to those who seek to exploit it for their own motives, regardless of the consequences. They hope that no one else stumbles on it and fixes it, preventing them from continuing to use it to do bad things.

In the world where it is disclosed, there is more value in fixing the vulnerability as the maintainer’s reputation is at risk (and potentially monetary loss or legal liability if they are shown to be negligent).

So if I found a vulnerability that lets hackers withdraw withdraw all the money in your account without a trail on where the money went, you'd be fine with them disclosing it to the public at the same time as the bank learns about it?

Even when there is no known use case of the attack (other than the security researcher's)?

> The vulnerability exists for me either way, and I'd rather have the chance to know about it and minimize risk

By the time you hear about it, the money could be gone because 1000 hackers heard about it from the researcher before you did.

> than to be surprised by the fix and hope nothing bad happened in that meantime.

Hope is not a good strategy here.

> Immediate public disclosure is the only choice that isn't irresponsible as far as I'm concerned.

No, it's really not.

High severity vulnerabilities are responsibly handled by quietly neutralising them with subtle patches that do not reveal the vulnerability, waiting for those patches to distribute. Then patching or removing the root cause of the vulnerability (at which point opportunists will start to notice), and finally publicly disclosing it when there are already good mitigations in place.

Example: spectre/meltdowm mitigations.

I've been asked to use this approach myself when reaching out to maintainers. Sometimes it's possible to directly fix the vulnerability as a "side effect" by making a legitimate adjacent change.

With immediate disclosure the provider can decide to shut down while it is fixed. Or to notify users and make it their decision. Or to be prepared with a diversified infra and switch over to a non-vulnerable path. e.g, BSDs are not affected by CopyFail

“The choice that maximizes potential damage isn’t irresponsible, because it means I can mitigate my own systems immediately.”

That’s what you’re saying here.

Those groups care about whether millions of computers are vulnerable, likely including your computer. If "immediate public disclosure" was done in all cases every vuln would be exploited and patches would be much lower quality. Shortening the disclosure timeline might be a good idea, 90 days is starting to feel long.

The Venn diagram of mainstream distros and individual Linux users is virtually a circle.

Ubuntu/RHEL is vulnerable and so are most Linux users by extension.

> Kernel LPEs are not rare. This was a particularly simple and portable one, but the underlying raw capability is a CNE commodity.

I absolutely 100% agree with this and I'm glad to see somebody saying it. Any system that is one LPE away from being compromised is already insecure.

A LOT of websites are tenants on WHM/CPanel hosts. Not to mention how many agencies use it for their clients Wordpress sites.

I thought that was the entire design goal of the Unix model, didn't it originate in the times when hundreds of users logged on to a shared mainframe? There are still public Unix servers like SDF out there. SELinux is just an extra layer so that if someone gets root (ex. due to an exploit in your setuid code or cron jobs etc) it's not game over.

I'm quite sure there are many application hosting providers which rely on container runtime such as runC (default runtime of containerd/Docker), and a shared kernel between users.

When the exploit is an advertisement for an exploit detection company, not doing the right thing is a bad look

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.

Why wouldn't the linux security team notify the main linux distributions?

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...

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.

> expecting people to always do the right thing is fantasy level thinking.

Most people in tech think like the techie in this comic strip.

https://xkcd.com/538/

This is probably more common than you think. VMs are expensive, both in resources and cost (if you’re using something commercial). OS-level isolation (shared kernel, cgroups, namespaces) is used pervasively

Argument from uncertainty is not a good way to reason about this.

I could equally ask: "Who knows how many attackers learned about this vulnerability from this disclosure, and used it before the distributions fixed it?"

well now everyone does, so the irresponsible disclosure makes it significantly worse.

And now it was changed back. I'm goin' insane.

> “Shared hosting providers” These haven’t been a thing since VMs

That is unfortunately not true. i left my last one only a few years ago and they're still going strong without me.

I doubt it will and I hope it doesn't.

External security research happens for one of only a few reasons typically:

1) hobbyists who are learning or just like to do it for fun 2) bug bounties (good luck with those in most open source) 3) marketing for security companies 4) non-public research going to CNO/CNE

If you want to kill 3, the output of 1 will not come close to 4 and the public is NOT better off with fewer public bugs.

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.

As opposed to all other operating systems with no CVEs ever?

Hype around switching from Windows servers?

What happens if someone does the exploit in WSL?

You clearly have no idea how often windows has unpatched privesc exploits.

>> puts a bit of water on all hype around switching from Windows.

Said no one ever...present post excluded :-))

There are a zillion of distributions. The mailing list at https://oss-security.openwall.org/wiki/mailing-lists/distros includes some I never heard about and misses some famous ones (Mint, POP OS.)

The bug is in the kernel, so it's OK to notify only the kernel team. Then they should notify the distributions they are in contact with.

The first message about Copy Fail that I see in the archive https://www.openwall.com/lists/oss-security/2026/04/ is from April 29. I run apt on my Debian 13 yesterday and got the fixed kernel.

Do I expect that every distribution is already patched? I don't. However each of us choose the distribution to run. Security can be one of the criteria for the choice. I played safe and I'm using Debian. Other people can make a different tradeoff maybe based on their personal threat analysis.

There are people running end of life kernels and distributions in production, or with pinned old kernels especially on ARM SBCs. I know both. Those are other choices made at the user end of the process.

IMHO the disclosure and fix process was run in the proper way from the researcher to the end user.

I don't get why the initial reporter should have to do that legwork. The kernel maintainers should be doing that.

The kernel team has been at odds with the CVE process and the oss-security community about this stuff for many, many years now. It's a big part of why the kernel team established a CNA and started flooding CVE notifications; they don't believe that security problems are different than non-security problems, and refuse to establish norms or policies based on the idea that they are.

“One” would have thought? Can you point to a written policy that says that’s how it should be?

If you notify the kernel and they ship a fix, it seems reasonable to expect that they will communicate the fix to the distros.

I see this as an organizational failure of the Linux ecosystem. There should be better communication between distro and kernel development.

What is the heuristic for who should get the heads up? Should they notify amazon but not google simply because they named amazon linux in the report? Seems to me the answer to my first question gets messy fast.

No, you're in more pain, but other defenders with different postures benefit from having faster and fuller disclosure.

Agree it's not a good look for these folks, notwithstanding that disclosure is mostly theater.

Exactly. Any security person absolutely KNOWS that the distros are still going to be vulnerable. They're exploiting this process loophole to knowingly cause chaos and gain notoriety.

At this point this is not really white-hat/ethical hacking anymore.

Ofc the kernel-distro security loophole is stupid and should be patched ASAP, but that doesn't absolve this company of wrongdoing.

you must be unfamiliar what used to happen before hard deadlines were set on disclosure. it was much worse for the users.

here is a good start: https://projectzero.google/vulnerability-disclosure-faq.html...

there is ~3 decades of more context if you search for it.

Bashing on the reporter is pointless feel-good. This is a massive vuln. It was 4 weeks after Kernel had a patch. They had no way to know if others parties had also discovered the vuln. Lord Knows how many millions of systems could already have been rooted. The reporter is not their minion.

If I call 911 to report a fire at an oil storage facility - and they ask me to alert the hospital, then phone the neighboring county's Sheriff Dept., and then...yeah. Either I'm way out in the sticks (and known to/trusted by the 911 operator), or else the 911 service is run by children.

> Without read permissions you cannot execute the binary

This is not correct, as when the binary is setuid-someone-else, you are not the one executing it; they are.

  $ cat hello.c 
  
  #include <stdio.h>
  
  int main(void)
  {
      (void) puts("Hello, world!");
      return 0;
  }
  
  $ clang-21 -Weverything hello.c -o hello
  $ sudo chown root:root hello
  $ sudo chmod 4711 hello
  
  $ ls -l hello
  -rws--x--x 1 root root 16056 Apr 30 22:22 hello
  
  $ ./hello
  Hello, world!
  
  $ id
  uid=1000(aaron) gid=1000(aaron) groups=1000(aaron),27(sudo),46(plugdev),100(users)

this ld.so magic will lose the suid bit

    $ /bin/ld.so `which sudo`
    sudo-rs: sudo must be owned by uid 0 and have the setuid bit set

loader

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...

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

F44 is safe as the kernel is greater than 6.18.22

For compiled-in kernels you can also work around it without rebooting via apparmor, seccomp or SELinux at the least, there may be eBPF or other methods too.

In the original thread they admitted multiple times that they rushed it out for marketing reasons.

Couldn't the product itself disclose to the vendors?

I don't know what exactly can load this module but the servers are running for many weeks and I suppose that if something will load this module, it stays loaded until the next reboot.. no ?

I tried to rmmod on all servers and rmmod always returns `ERROR: Module algif_aead is not currently loaded`, that's why I think it's fine. Of course I take a look on https://security-tracker.debian.org/tracker/CVE-2026-31431 for the updates.