Hacker News Reader

Comment by aduwah | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com