Hacker Newsnew | past | comments | ask | show | jobs | submit | staticassertion's commentslogin

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


This couldn't be more backwards. This has literally nothing to do with bandwidth. The kernel is a CNA, they are explicitly the ones to do this.

The reason they don't is because Linus and Greg have repeatedly, publicly stated that they don't want to because they don't believe that vulnerabilities conceptually make sense for the linux kernel and they refuse to engage in the process.


> they don't believe that vulnerabilities conceptually make sense

That's exactly what I wrote: "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".

But there is also a question of bandwidth. If a maintainer asks to bring a specific vulnerability to distros-list, the kernel security people will be reasonable. I did it last March.


How does that square with this comment from greg from today?

https://www.openwall.com/lists/oss-security/2026/05/01/3

(About heads up to distros)

> Nope, sorry, we are NOT allowed to notify anyone about anything "ahead of time" otherwise we will have to tell everyone about everything. That's the only policy by which all the legal/governmental agencies have agreed to allow us to operate in, so we are stuck with it.


I don't know, this is the one that I mentioned:

https://www.openwall.com/lists/oss-security/2026/03/30/5

You can see my name under "Timeline", I asked kindly for both distros-list and a longer embargo than usual and got them.

I guess Greg is not allowed to notify distros-list, but someone else is?


He's full of shit lol

Yes.

Greg and Linus do not believe in the entire concept of "vulnerabilities" in the Linux kernel and do not believe in the methods that distros use like cherry picking, therefor they typically are against issuing CVEs, scoring CVEs, describing vulnerabilities at all (if you use the word "vulnerability", your patch will be rejected), etc.

It's fundamentally their position to not work the way that you describe.


That doesn't really seem to map onto the situation since Greg himself released a 6.12 with the patch earlier today.

I don't know what you mean at all. I'm just repeating known kernel policy here. What does 6.12 have to do with anything?

What is your interpretation of why Greg KH released a version of 6.12 with this fix in it today, other than to help distributions avoid this vulnerability?

Why would he ever... not release a new version? I don't get what you're trying to say - I'm stating Greg's explicit policy on the topic. If he did something outside of that policy, that wouldn't change anything.

If he doesn't believe in the "concept of vulnerabilities" then it is remarkable that he released a 6.12 targeted on this one fix. Why would he do that otherwise?

Sorry but he literally doesn't and nothing you say is going to change that he has explicitly stated that. This isn't up for debate, go ask him yourself, literally go to the first blog post on his site.

As for the latest patch, Greg is currently being forced to clean up a big fucking mess by external parties. And he's miserable about it.


I would like to read more about this. Do you have a source?

http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignmen...

I'd start with Greg's own words. You can probably find more on it from Spender/grsecurity's blog.


The claims you make upthread are very hard to match with the text you link to, did you past the wrong URL?

No, that's the correct URL.

That's mostly on Greg, a bit on the author.

The patch was available. Upstream just doesn't communicate vulnerabilities because they have a personal dispute with distros about how to handle patching.

In a just world, those companies would be held legally accountable for negligent practices. The Linux kernel upstream has made it clear for decades that security is a dirty word.

LPEs on Linux are obscenely commonplace.


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


right, which is why it is confusing that the animosity is aimed at the reporters rather than the kernel security team.

Not really confusing. Linux is a sacred cow.

There would be a lot of people gloating if this happened to MS.


Microsoft has a long and sordid history of cheerfully doing anything they can to fuck everyone over just to make a few more percentage points of profit.

Linux is a free kernel that literally revolutionized the computing landscape.


Yes, this is the sacred cow status being referred to.

It might be a scared cow, but at least deservedly so. There is imho a difference between accidental incompetence (debatable, even) and active malice. Microsoft has done a lot of the latter so gets bashed more, nor surprise there.

"You keep using that word..." or term in this case.

There are only 2 words in this term, and neither one even slightly applies.

A sacred cow is called a sacred cow because there is no reason for it to be sacred.

Linux is perfectly subject to criticism, and so not at all sacred.

Linux has earned a stunning amount of respect and gratitude by actually providing stunning utility and quality. IE, it's not just a random object like a cow that everyone decided to worship for no reason.

Spoken as a freebsd user who has plenty of critiques of the entire linux ecosystem.


> Linux has earned a stunning amount of respect and gratitude by actually providing stunning utility and quality. IE, it's not just a random object like a cow that everyone decided to worship for no reason.

I agree.

> A sacred cow is called a sacred cow because there is no reason for it to be sacred.

Here we diverge. Linux earns sacred cow status when people interpret legitimate criticism of it as an attack that must be debunked or dismissed. And there's plenty of that happening in this forum; you may not be treating it as a sacred cow, but plenty of people are.

And to expound on why it even matters, it does a disservice to Linux to treat it this way: if you can't engage with its flaws, you'll never help fix them, and instead attack people who try.


I think both parties share some blame here.

What process? Wasn't the default state of things to just let any random person of the street spam vulnerability reports without validation or quality control?

Where would you have them write a detailed report if not a website?

That seems literally borderline impossible.

I think they've almost certainly seen it written out, just not as an acronym. I figured out what it stood for based on context and knowing the full phrase, but I don't recall actually seeing the LPE acronym in recent memory. Whereas with CVE it's the opposite: I almost never see it written out, and even now find it non-obvious what the E stands for, bizarrely enough.

You should re-evaluate your probabilities, I too have heard frequently of CVEs, but never of an LPE.

I'm sure lots of people have heard of CVEs, but have you actually read many? LPE is an extremely common term. It's like not knowing RCE. These are the terms used.

I'm as stunned as you are. I have to read CVEs on a weekly cadence (like contractually required to) and LPE/RCE are kind of the main keywords we look for in them. Also increasingly TOCTOU. If anyone who actually has to respond to CVEs told me they had never seen these terms before I would judge them as being unserious.

I'll raise my hand here and risk downvotes from very smart people who are smarter than me, but I've heard of CVE but not LPE or RCE. I know what the latter two terms are but am not used to seeing them in acronyms.

So what's missing is that keeping up-to-date with CVEs is important and some CVEs are Internet-nerd famous. Remember Heartbleed? Even some casual gamers I know had heard of it. And everyone who's mildly serious about sysadmin knows you want to defensively keep systems patched against important CVEs. The second layer of that, what the exploits actually are or do, is a second-layer term of art, one that one might miss the jargon for even if one has familiarity with the concepts.

To me, the fact that the page is obviously AI-assisted is way more upsetting than some guy not knowing what an acronym means. There's something about AI prose that is just so fucking tedious. It makes the mind glaze over.


To be clear, I'm not suggesting that you if have heard of CVEs therefor you must have heard of LPE. I'm saying if you have read many of them you would have seen these terms.

I obviously do not expect someone who has merely heard of various CVEs before to know anything about the contents of those CVEs. The other poster said they had "read many CVEs", which I took to mean they have read many CVE disclosures, where the term is extremely common. Perhaps they meant that they've read about CVEs, in which case I can see why the term would not be on their radar.


some people just don't have a good memory for acronyms. It's one thing to learn the concept of a privilege escalation, but an entirely different thing to play mental memory with TLAs (three letter acronyms). Acronyms remove all the context from a term which makes them way harder to memorize. A bit like knowing your friends vs knowing their phone numbers.

I could see it for someone who is only somewhat in tune with security work today.

Back in the day those of us breaking into shitty php sites didn't use LPE, we used "privesc", IIRC.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: