Live data from Hacker News

Over 400 Linux CVEs published in the last 24 hours alone

lore.kernel.org

41–50 of 52 posts

Re: Over 400 Linux CVEs published in the last 24 hours alone

#41

Might need to silently archive those Microsoft Patch Tuesday jokes...

If they were there this whole time but only discovered now, were they really a threat? The reflexive response to this is "those could be exploited for years and we'd never know", but if it was discovered, it obviously wasn't impacting you personally. If they were under lock and key at the NSA and only judiciously used for secret spy BS, that's effectively the same as not existing. Clearly they weren't discovered by a…

> I want to make the case that it has been the more secure OS this whole time.

Your phone is ringing, caller ID says its Theo de Raadt from OpenBSD. :)

Re: Over 400 Linux CVEs published in the last 24 hours alone

#44
Nearly every bug is at best a denial of service. If the service worked as expected, there wouldn't be any bug. CVSS considers any denial of service a security issue. Therefore, all bugs should have CVE numbers. The Linux team took this to heart, became a CNA, and assigns CVEs to pretty much every bug.

Re: Over 400 Linux CVEs published in the last 24 hours alone

#45

I guess very few around here remember the minor fuzz about this from a few years ago? The Linux Kernel Project became their own CNA (CVE Numbering Authority). A CVE is now slapped onto practically every bug fix that is back ported to a stable kernel, resulting in a flood of CVEs. A blog post about this, published at the time: https://sigma-star.at/blog/2024/03/linux-kernel-cna/ The title is editorialized (i.e. the OP…

It's malicious-compliance CVE filing. Other interesting coverage of the issue by Risky Biz, https://news.risky.biz/risky-biz-news-the-linux-cna-mess/.

Given the broken nature of the CVE process, see for example Daniel Stenberg of cURL fame's frequent comments on this, I'm undecided whether this is a good thing, a bad thing, or a bit of both.

Re: Over 400 Linux CVEs published in the last 24 hours alone

#46
post #23
post #4

I am assuming that many of these are found with automatic analysis tools that are very creative (i.e. LLMs) and there may be a high proportion of very "cornered" cases. I think there needs to be a triage method that would amount to the severity, likeliness, and detection dimensions used to rank risks in a systematic framework [1]. I think if this could be submitted (or estimated) along with such bug reports, it could…

The linux kernel team disagrees with your approach but what do they know? > Note, due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify. This…

I was too busy waxing my armchair and didn't do any reading on the actual practices. Thank you for replying with this. It makes sense. I wonder if this level of purity will survive the test of time; since there are paid kernel developers, the situation could be very different from e.g. an entirely volunteer-maintained project.

Re: Over 400 Linux CVEs published in the last 24 hours alone

#47
post #33
post #27

Earlier quoted context omitted.

This has nothing to do with LLMs.

That doesn't excuse the point. Thanks to LLMs, We'll see more of this and more embargoed vulnerabilities now revealed like this on a regular basis. Given that Linux allows the use of AI assistance [0] you'll be very disappointed to see that people will use LLMs to find even more CVEs and bugs much quicker. That also means they will be fixed much quicker which should be a good thing; as long as the core developer is i…

What do you use instead and what makes it more secure?

Re: Over 400 Linux CVEs published in the last 24 hours alone

#50
post #7
post #4

I am assuming that many of these are found with automatic analysis tools that are very creative (i.e. LLMs) and there may be a high proportion of very "cornered" cases. I think there needs to be a triage method that would amount to the severity, likeliness, and detection dimensions used to rank risks in a systematic framework [1]. I think if this could be submitted (or estimated) along with such bug reports, it could…

In my company, the security team isn’t technical. They see CVE, find a vulnerable system, it gets flagged. We have to patch it. We patched for a CVE last week that a malicious usb sound card device could be use the gain root. On a Vm? Is that something we really need to worry about??

On a headless VM, almost certainly it's not a worry, since that bug needs a physical port and the driver binding to a plugged-in device (so basically it's never reached). You could even prove it running lsmod showing the module is not loaded (so "not applicable"). Unfortunately the CVSS score doesn't carry reachability information, and not just for the kernel CVEs.
Post reply on HN