Hacker News Reader

Comment by semiquaver | Hacker News Reader

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

View on HN

Especially since the reporter is explicitly asked not to notify the distro teams first.

https://docs.kernel.org/process/security-bugs.html

```As such, the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the “linux-distros” mailing list UNTIL a fix is accepted by the affected code’s maintainers and you have read the distros wiki page above and you fully understand the requirements that contacting “linux-distros” will impose on you and the kernel community. ```

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.

> […] 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.

They believe there is no difference being able to get root and not being able to get root? It seems to me that to-be(-root) and not-to-be(-root) are quite different.

No, they believe that almost all bugs in an operating system kernel are also likely to be security bugs. The ones which get domain names, POC exploits, and CVE assignments are the ones which were found by security researchers. But the bugs that get found and fixed by kernel developers regularly without fanfare are also very likely to be exploitable. It's just that nobody took the time to cook up an exploit chain. To kernel maintainers, it's silly to assign CVEs to just some of the likely exploitable bugs just because a security firm found them. So they decided to take the reigns and handle CVEs themselves, to ensure all potentially exploitable bugs are marked as such.

It's such a bizarre viewpoint. I wonder when Linus will see sense.

IMO it's pretty obviously not a view that they seriously hold, it's just one of those technical justifications people come up with to avoid admitting something they don't want to admit - in this case that Linux has a poor security track record.

Linus? You mean, the same Linus who thinks "security people are f*cking morons", and "security bugs are just bugs"?

Linus is the reason why kernel team doesn't talk to distros. For them bugs are bugs, security related or not.

https://lkml.iu.edu/hypermail/linux/kernel/1711.2/01701.html...

I think it's an extension of the premise that you should just be taking the whole stable tree with all its patches constantly, whether they're labeled as security fixes or not, because you can never really know for sure some bugs weren't security bugs.

I don't agree with the premise, but I do think it's a sincerely held one.

I dunno, if you think about it for more than a few seconds you can see the obvious holes in it, like it's definitely true that some bugs are "may allow RCE", but you also can do a LOT better than not even trying. And even if you do say "we're not putting the effort in to backport security fixes" (which is fine), that doesn't entail "security bugs are just bugs".

These are smart people. If it wasn't about their own project I really think they'd have a different point of view. I wonder what they say about Microsoft's security bugs for example!

I don't think I said I agreed with them, or that the position had no flaws, I just said I thought their stance was sincerely held.

People can earnestly believe illogical or inconsistent things. Arguably those are even easier to get stuck believing, as you already had to accept some friction in the inconsistencies earlier in your internalizing them, so now you're even further into sunk costs around it.

The kernel begrudgingly admitted of the existence of LTS releases, they really don't like long-lived kernels and people not tracking at or near the latest release.

> I wonder when Linus will see sense.

Literally never. Why would he? He's surrounded by sycophants. And we have Greg for whenever Linus isn't involved anymore, and Greg is just as boneheaded.

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.

Ffs, we're talking about open source projects here. Those mailing lists, mentioned there, ARE PUBLIC.

Make them private? Now you have a nice stream of zero days, long before fixes are available, making bad actors who made it in filthy rich.

If you're suggesting a private disclosure channel, made for all the maintainers of the ~600 actively maintained distributions (including those that pop into existence just to get access to the disclosures), then that would be a point you could make. But, that text above is reasonable, because the mailing lists they're referring to are public.

Open source code process must assume bad actors are involved (because they have been historically, and will be always and forever). So, this isn't some "easy" scenario. Talking to the guy that can fix it first, and assumed the distributions contain bad actors, then disclosing to them once the fix is available, is reasonable, and I don't see an alternative.

I would be interested in seeing what the thoughts are on a proper disclosure cycle, for those 600 distributions. Seems very complex.

> and you fully understand the requirements that contacting “linux-distros” will impose on you

Imposing requirements on the reporter? No.

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.

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

No, nor 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.

The tenets of decency don’t need to be written down.

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.

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

From my point of view, they told the kernel security team which is in charge of fixing this. If it’s important for them to tell other people, then it should’ve been written down and further reiterated when they made their report.

The skills to detect code exploits is not the same as the skills to navigate an informal org chart to the satisfaction of an amorphous audience if end users (i.e. us on HN).

That said… as they are a company that supposedly specializes in this field, and is trying to sell a product, I do believe they should do better. Right now, I don’t have much confidence in their product.

different cultures have different views on disclosing vulnerabilities to distros before the public?

Yes :) The blackhatter would obviously sit on it until they can sell it or use it, the whitehatter collaborate the kernel and distros to patch, and the greyhatter argues on HN whether the latest *fail was responsible enough or not.

Yes? "Different cultures" doesn't just mean different countries; there are many cultures within infosec.

There is little difference in culture here. Nearly all open source work is done in English.

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?

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.

The reporter clearly knows the distro fixes have not been shipped, read their report. They chose to disclose anyway.

>They chose to disclose anyway.

yes, because 30 days had passed from the time the patch landed in the kernel, as per industry standard.

approximately every security researcher, including the likes of google and other big names you may know, does a 90+30 disclosure, which is what happened here. they do this for good reason, which has been figured out over decades of experience in reporting thousands and thousands of vulnerabilities.

the only security researchers i know of that dont like 90+30 actually argue for shorter timelines (or immediate disclosures).

What do you think went differently in this case versus other high profile vulnerabilities that had binaries already available for major distros? I feel like it often (usually?) works out that major distros have kernel packages incorporating the fixes already available.

Is this just down to luck, a quirk in the timing about when Linus merged the fix versus when the release gets cut?

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.

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.

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

Mind explaining how sitting on it a month after the patch landed is 'faster'? To my mind, that's a month where attackers could analyze commit logs, but maintainers are not acting with urgency to ship fixes.

No, I wouldn't, because my own preferences are towards immediate disclosure. Tavis Ormandy dropped Zenbleed out of the sky onto us. It wasn't comfortable, it was a scramble for us, but I don't blame Tavis for it; he made a principled call. Better that people know, than that information be concealed from them while designated elites perform a process.

I'd also prefer immediate disclosure, but I don't get how waiting a month without telling anyone is good regardless of which side you land on.

>I'd also prefer immediate disclosure

wait, what?

you are in another comment thread, of this very post, calling these reporters bumbling and incompetent for their disclosure. "merely bumblingly incompetent and overly eager to get their marketing pitch out the door" - that is your quote.

you also said "Basic care would involve making sure the patches had made it into the wild before ending the embargo", which is the literal opposite of immediate disclosure.

but now you are saying they should have just dropped it with no reporting at all? because that is what "immediate disclosure" means. pop up the exploit script on twitter and call it done.

Yes, if you release the vulnerability as soon as possible, that's a good choice. If you have an embargo and make sure that fixes get out to users in a timely manner before ending the embargo, that's also a reasonable choice.

If you're going wait a month between landing the patch (possibly notifying attackers), but not notify the people who may get the patch to users, it seems like something was mishandled.

What if you try to go with the second option but the vendor barely puts any effort into getting the fix out to user and then it's a year later and the vulnerability is still under embargo? Maybe you decide that the next time you find a vulnerability you want to light a fire under the vendor by giving them a fixed deadline to get the fix out to users. A month seems like a reasonable deadline for that sort of thing.

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

Good for them. But just because some folks cannot afford 24/7 response teams and on-call personnel that doesn't make them or their systems any less important.

Lots of non-profits and academic institutions had to scramble because of the Linux kernel team's position of non-communication to distros.

The conversation about how Linux handle these things is a good and worthy one to have and one "non-profits and academic institutions" need to have when they select distributions. I'm just here to push any of that scrutiny off the vulnerability reporters; Linux is lucky to have them, even if it's mishandling their reports. Vulnerability researchers don't owe these people anything.

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.

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

Reply on news.ycombinator.com