Linux Kernel Team Publishes 432 CVEs In Two Days 92
Ancient Slashdot reader alanw shares a post from the OSS Security mailing list, where sysadmin Jan Schaumann wonders what to do after the Linux kernel cranked out 432 CVEs in a little over 24 hours: "I understand the position that CVEs were always a flawed way to track or prioritize security changes... But this onslaught really shows it's not feasible to attempt to prioritize individual kernel changes. I'm not sure what to do here going forward." The Register reports: The nixCraft team speculated on social media that AI bug reports are a likely reason for all those kernel CVEs, which wouldn't be without precedent - Linus Torvalds himself said in May that the Linux kernel security mailing list had become "almost entirely unmanageable" due to AI-assisted bug hunting. Nonetheless, Torvalds has described AI as a useful tool for Linux development while still noting it can be a drag for maintainers, both from a workload standpoint and the fact "it keeps finding embarrassing bugs." [...]
Unfortunately for Linux sysadmins, the position in which they find themselves in this current mess isn't one that's readily solved. CVEs might be a messy way to track and prioritize security updates, especially when hundreds of them are published over a short period, but without something better, it falls to IT and security teams to determine which vulnerabilities affect their systems and which kernel updates they need to deploy. Senior kernel maintainer Greg Kroah-Hartman replied to Jan's post, pushing back on the idea that the kernel's CVE volume is uniquely unmanageable. The kernel isn't special, he argues -- companies everywhere are finally realizing they need to re-evaluate how they update all of their systems and devices, something that's traditionally been "woefully ignored."
On the "just always update" approach, Greg says that's precisely what the kernel community endorses: "This is what the kernel developer community recommends and supports. If you want support from us, do this." Can't manage it yourself? Pay a company for support, or "just use Debian or Yocto as their security practices are amazing." He points to Android as proof the approach scales, calling it "the largest deployment of software in the world" -- billions of devices kept updated "with one very-overworked developer guiding it all."
As for reviewing every CVE individually, he notes this can be largely automated by intersecting the files a CVE touches with the files you actually build, which typically trims the relevant set "down to about 10% of the overall total" -- the approach enterprise distros already take for their customers. Panic-mode selective patching gets a blunt "Good luck with that!" -- regulations like the EU's Cyber Resilience Act are set to legislate that habit away ("rightfully so," in his view), and "your insurance company might wish to have a talk with you as well."
Greg also warns the flood isn't over: "The number of llm-found issues is only on the rise right now, it's going to be a very long 18 months at the least to dig ourselves out of this mess, and people had BETTER be updating their systems all along the way if they expect to be secure in any way." As for the 432-CVE burst itself, he explains it was simply him catching up on a weeks-old, publicly visible review queue over the weekend -- delayed by "a perfect storm of 6 weeks straight of conferences and vacations" -- so it shouldn't have come as a surprise to anyone watching the public git repo.
Unfortunately for Linux sysadmins, the position in which they find themselves in this current mess isn't one that's readily solved. CVEs might be a messy way to track and prioritize security updates, especially when hundreds of them are published over a short period, but without something better, it falls to IT and security teams to determine which vulnerabilities affect their systems and which kernel updates they need to deploy. Senior kernel maintainer Greg Kroah-Hartman replied to Jan's post, pushing back on the idea that the kernel's CVE volume is uniquely unmanageable. The kernel isn't special, he argues -- companies everywhere are finally realizing they need to re-evaluate how they update all of their systems and devices, something that's traditionally been "woefully ignored."
On the "just always update" approach, Greg says that's precisely what the kernel community endorses: "This is what the kernel developer community recommends and supports. If you want support from us, do this." Can't manage it yourself? Pay a company for support, or "just use Debian or Yocto as their security practices are amazing." He points to Android as proof the approach scales, calling it "the largest deployment of software in the world" -- billions of devices kept updated "with one very-overworked developer guiding it all."
As for reviewing every CVE individually, he notes this can be largely automated by intersecting the files a CVE touches with the files you actually build, which typically trims the relevant set "down to about 10% of the overall total" -- the approach enterprise distros already take for their customers. Panic-mode selective patching gets a blunt "Good luck with that!" -- regulations like the EU's Cyber Resilience Act are set to legislate that habit away ("rightfully so," in his view), and "your insurance company might wish to have a talk with you as well."
Greg also warns the flood isn't over: "The number of llm-found issues is only on the rise right now, it's going to be a very long 18 months at the least to dig ourselves out of this mess, and people had BETTER be updating their systems all along the way if they expect to be secure in any way." As for the 432-CVE burst itself, he explains it was simply him catching up on a weeks-old, publicly visible review queue over the weekend -- delayed by "a perfect storm of 6 weeks straight of conferences and vacations" -- so it shouldn't have come as a surprise to anyone watching the public git repo.
Great news (Score:4, Informative)
It's always better for the team and users to be aware of vulnerabilities than to be unaware.
Re:Great news (Score:5, Insightful)
Re: (Score:2)
Security through obscurity never works. Eventually, it gets found out.
Re: (Score:2)
Re:Great news (Score:5, Insightful)
Jan Schaumann wonders what to do after the Linux kernel cranked out 432 CVEs in a little over 24 hours: "... this onslaught really shows it's not feasible to attempt to prioritize individual kernel changes. I'm not sure what to do here going forward."
So he literally says "it's not feasible to prioritize" and "I'm not sure what to do". Is that 'complaining', where you come from? Cos it sounds like overwhelm and turning to colleagues for support.
People making strawmen about people complaining makes them look bad.
Re: (Score:2)
So he literally says "it's not feasible to prioritize" and "I'm not sure what to do". Is that 'complaining', where you come from?
Yes:
Thanks, dictionary.com [dictionary.com]! I wish everyone was smart enough to use you!
Re: (Score:2)
aw you even made a little link, that's so cute.
here's a few other ones you should check out:
Re:Great news (Score:4, Insightful)
I can see his point though.
One place I worked, you have 2 weeks to fix any 'high' severity issues anywhere on your estate (and a 'high' CVE was a 'high' issue unless you could prove it really wasn't). You could get exceptions to the 2 weeks thing, but it was a lot of paperwork, and was always "we'll get to it in a month or so", not "we don't need to fix this one, so it'll get wrapped into the next bi-annual systems refresh". Patching can cause significant disruption, if not to end users, then to the schedule of work being done on the systems (some of which might be for things equally as important as security).
When you've got maybe a half dozen new CVEs a week, you can at least triage them. If they send you 100 a week, then you've got a lot of triage work on your hands. You've got to research each one, figure out the attack vectors, likelihood, how it fits in your environment - and then get suitable sign off that you triaged it right, and so prioritised it right.
So I can see his point, even if it wasn't made very well. Right now though, I'd say there's no point triaging, just patch as soon as humanly possible. AI's finding these issues, and AI will exploit them if you don't patch - so get 'em done. Once we're past this 'glut' you can maybe go back to being a bit more targeted.
Re: (Score:2)
This wouldn't be so difficult to deal with if security patches were not intermingled with new feature patches. WTF?
Re: (Score:2)
Re: (Score:2)
The issue isn't awareness, it is how to process such massive amounts of data. This is more than the average security/IT team can possibly process in a timely manner.
Sounds like they need to increase their staffing then. I wonder if there are any IT people looking for jobs right now...
Re: (Score:2)
This is more than the average security/IT team can...
Don't care. You've had time: this is no surprise to anyone that's been paying the least bit of attention for several years now, and isn't still stupidly indulging AI denial. The excuse window has closed: if your business is security and you didn't know at least as 18 months ago that you could expect to see exactly what is happening today, you're a seat warmer and no one cares what you think. And you're going to be obsolete soon as well.
Re:Great news (Score:4, Interesting)
Note that this isn't even new to AI, the kernel has always been a flood of CVEs. The AI spotlight puts a bigger spotlight on it, but it has been a mess.
The real problem is that the average security team is mismanaged and forced to use terrible tools that report on yet fail to reconcile the status of the CVEs on behalf of the user and instead drives the team to have to figure out how to take care of it themselves.
Some twisted security mindset of going direct with CVEs as 'the most thorough vendor neutral approach' without instead leveraging distribution security advisories. So you end up with a security tool claiming you have thousands of security issues on an up-to-the-minute patched instance of the latest enterprise linux distribution because they backport and tools don't understand the version numbers.
Re:Great news (Score:5, Interesting)
Depends on the number of realistically 'false positives'.
I've known a few people who find the kernel CVEs particularly unreasonable as they tend to aggressively assume security implications. If they grant a CVE to a 'mere bug', no one is going to get too grumpy over that specific item. If someone believes they have a vulnerability and do not see a CVE, then people get riled up. So some feel the kernel is just granting CVEs to avoid pushing back.
The other headache is the monolithic nature of the project. "Linux" covers just everything. A potential security issue in a device never seen outside of PA-RISC systems 20 years ago? It's a "Linux" issue, so every x86 system will be flagged as 'affected' by security software that cannot deal with nuance
Of course, we are here mainly because the kernel team largely recognizes the practice of trying to apply only security updates while avoiding 'only bug' fixes as pretty insane. So err on the side of caution make CVEs extra unmanageable because realistically it was a pretty crappy strategy for such a complex project anyway.
Broadly speaking, CVEs are usually pretty bogus, but a small percentage are very real and critical issues. You can't use the 'score' to really measure this either, it's not very good in the first place, and for example I saw the exact same issue in a C library and a python binding for that C library, and for whatever reason they graded the C library as 'minor' and python binding for that library 'critical', despite the python binding being nothing but a ctypes wrapper around the c library...
Re: (Score:2)
Depends on the number of realistically 'false positives'.
The users will (for the most part) need someone to interpret the information for them, but that's been true of pretty much everything since before the industrial revolution. Everything is complicated now.
Re: (Score:2)
Problem is that ultimately, the CVEs tend to lose meaning. The relative risk of a CVE becomes impossibly diluted because most of them aren't of practical security consequence. It's a lot of work to keep up the charade that CVEs are something that need to be handled as "more than bugs" and that you can somehow get a better consistent experience by avoiding bugfixes but still get CVEs to maintain security..
Very critical things have CVEs that are really important, but the CVE facet of it does not really set
Re: (Score:2)
it's a complete disaster for end-users to think they should be managing CVEs directly, which is precisely what the security community frequently demands
From TFS:
Re: (Score:3)
So that's describing the sane way to go. Problem is security teams aren't "sane".
For example, security team demands we account for CVEs, and we reply we use RedHat so RHSAs are the better curated source and here's all the information.
Nope, they don't "trust" vendors and we should independently account for CVEs. To the extent RHSAs cite CVEs, ok, but they don't speak to *every* CVE (notably, a lot of Android specific CVEs that don't apply to the RHEL builds), and we aren't allowed to just take RedHat's wor
Re: (Score:2)
So that's describing the sane way to go. Problem is security teams aren't "sane".
It seems to me that there is a general lack of sanity in the world. This is only one of the most personally irritating personifications.
Nope, they don't "trust" vendors
That's fair in general, but that still doesn't mean that you should chase every CVE immediately... I know, see above
Re: (Score:3, Insightful)
When Microsoft patched hundreds of issues, people claimed it was because they were incompetent morons who couldn't write decent code. When the Linux kernel patches hundreds of issues, it's all good.
Interestingly Linus Tech Tips just did a video proclaiming the Year of the Linux Desktop is finally here. A bit hyperbolic perhaps, but they made some good points. The Steam Box is solid hardware, and Steam OS in desktop mode is one of the better distros. One thing that really stood out is how well meaning it fel
it keeps finding embarrassing bugs. (Score:3)
Is there any other kind?
Re:it keeps finding embarrassing bugs. (Score:5, Insightful)
Is there any other kind?
Sure there are. Some bug reports, you look at them and dig in and say "Damn, that's obscure. It depends on subtly-wrong but arguably-correct-in-isolation mistakes in four different places. How the hell did they even find that?".
Granted that it's more common to glance at it and just be ashamed, or to look at it and say "Really? You think an attacker can do A, B, C, D, and E, all at the same time? Oh, and to do B or D they'd already have to have the system mostly compromised. Okay, I'll fix it, but no way in hell is that actually exploitable."
Re: (Score:2)
nobody can predict the winners (Score:2)
You should simultaneously believe both that nearly all AI investment is a bubble and also that AI tools are not going way.
Re: (Score:2)
Just expect LLM tools to become a lot less powerful or a lot more expensive. Actual developers being cheaper has been observed in several places already. And the token prices still do not cover cost.
Re: (Score:3, Interesting)
But you are.
Even Anthropic's most eye-watering token cost is vastly cheaper than a developer salary in terms of work done per dollar.
The bun Rust rewrite for ~$160k in 11 days for what's estimated would have taken a team of developers a year pretty much settles it.
That's about 90% of my salary at about 5x my estimated performance.
For reference, bun was 535,000 lines of Zig.
Of course, it can't do all things this way, but imagine it had been done with GLM5.2 in
Re: (Score:2)
Your sub-100 IQ never ceases to amuse me.
You don't know shit. If you do indeed teach people, you are doing them a harm.
You do know that insults where the other side has strong proof they are not true do not work, right? Well, probably that is already beyond you. This is Kindergarten level though and not flattering for you. You may at least want to try to be a bit original, not completely dumb in your attempts to insult. This is just boring.
Re: (Score:2)
You do know that insults where the other side has strong proof they are not true do not work, right?
Look at you- lol.
You construct this fantasy bubble around yourself where you did not just insult me while offering zero refutation of actual factual points I made (bun Rust rewrite)
And you continue to act as if that is not how we got here.
You are so fucking deluded. Again- if you teach anyone, it's a fucking crime for that institution to still employ you. But I'm betting it's not actually true. I'm betting maybe it was true at some time, and you can't get past the fact that they let you go long ago.
Well, probably that is already beyond you. This is Kindergarten level though and not flattering for you. You may at least want to try to be a bit original, not completely dumb in your attempts to insult. This is just boring.
Your
Re: (Score:2)
Still pathetic. Try again?
Re: (Score:2)
Re: (Score:2)
I see you have chosen to double down on the pathetic. Well, I guess this is all you can do.
Re: (Score:2)
Ah, yes, the last defense of the mentally incapable: "Academics know nothing!". In actual reality it is almost always academics that brought an area to the level where it actually became possible to "do".
Re: (Score:2)
An academic doesn't deny reality [bun.com] in order to soothe their own cognitive dissonance.
Re: (Score:2)
And even MORE pathetic. How can you exist like that, understanding nothing?
Re: (Score:2)
Exactly! THIS is what all the hype is really about (but is not well explained). Software, world wide, is almost a 1 trillion dollar business. AI *if it never did anything else useful - ever* can accelerate that trillion dollar business (slated to be 2.2 trillion within a decade) from profit margins of 60% to 90% or more. Hundreds of billions a year, just in the US, in additional revenues and profits. And accelerating over time as software gets cheaper, better, faster; and the AIs get cheaper, better, f
Re: (Score:3)
We're calculating our current burn rate and it looks like we're spending an extra Sr. Dev salary per person for mediocre to average, but quickly generated code.
That's for developers. The product managers are burning 5x more tokens.
Re: (Score:2)
But beyond the investment bubble- AI itself is very real.
When the dotcom bubble burst, it's not like e-commerce went away.
All the datacenters that were built- they didn't go away.
2 of my organizations datacenters were dotcom datacenters that were abandoned by Verio and picked up by us on the cheap, where we utilized them profitably for going on 2 decades now.
Re: (Score:2)
For how many years is it a bubble by now? Come on people, short sell the AI companies if you dare.
Debian is indeed good (Score:4, Insightful)
They have an unparalleled level of oversight and accountability for a free distribution. It's worth dealing with the outdated packages. These days, on topic, at least you can get current kernels from backports.
Re: (Score:2)
Running Debian with your own kernels is easy, except for the really deranged grub automation. I mount /boot ro to prevent it getting clobbered all the time.
Re: (Score:2)
I did it for a while, it's nice that they package the necessary files with the kernel, but it's nicer to not have to. These days I get a current kernel and a ntsync module without having to do anything special.
Re: (Score:2)
One reason I run my own kernels is that the module system is a vulnerable spot. Hence I run monolithic kernels. Has saved me a couple of times from having to patch fast. Not that big a thing, but the effort is low.
Re: (Score:2, Insightful)
They have an unparalleled level of oversight and accountability for a free distribution. It's worth dealing with the outdated packages.
Sorry, but "outdated" always irritates. It is such a developer biased view. As someone who is not a developer and with a factory to run, your outdated is my stable! Your right to more features or avoiding a workaround isn't larger than that of my employees to keep working. There's millions more of us than of you!
Re: (Score:2)
On one hand, stability is more important than new shiny. On the other, I have long awaited features which aren't available in some software versions, including in KDE where I really don't want to replace the whole thing.
Re: (Score:1)
In the real world, most non-geek people I know never update anything, be it phone, computer or other electronic gadget.
It's not hard to figure out why: everyone has been bitten at least once by a bad update, and remembers it bitterly. Otoh not everyone has been hacked, or at least not-every-device-they-own has, so on balance the inconvenience from upgrades is bigger than the inconvenience from hacks.
With the AI-bugfinding floodgates open, we will be on a rollercoaster ride for months, mos
CVE management is just broken... (Score:3)
In the industry, so many security teams mandating CVE management software that is absolutely stupid and pushes off all the hard bits to the user.
It sees 6.12.0-211.34.1.el10_2... Well... none of that makes sense so it just assumes that it's just plain 6.12.0 and demands the user reconcile the reality. Now the security vendor *could* maybe integrate with the major linux distributions advisories... But no, more CVEs is better, when you demo that your product finds hundreds of CVEs, that just proves it is being thorough as far as upper management is concerned.
They offer up sound guidance here, skip direct CVE management and lean on your distributor. If you are doing CVEs direct, at *least* use the patched files to cross-reference against your build to see if it even in theory could matter. However the problem is the business of the security industry doesn't prioritize those, and so we have stupid tools inflicted on people, and pushing back against those tools carries a stink of "must not care about security then".
Going to get worse before it gets better (Score:2)
Even before tools like Mythos were made available, security professionals were seeing a large increase in AI detected bugs, some of which were, indeed, critical (Mythos and it's ilk have only increased the numbers). The statements of those security professionals were that the next few years are going to be some of the most intense that the security teams have ever experienced, but that it was likely things will eventually get better for those that are able to survive the storm (and not everyone will) as t
Re:Going to get worse before it gets better (Score:5, Insightful)
Most maddening for open source projects is the number of false positives exacerbated by multiple people trying to 'help' by running effectively the same security audit as a bunch of other people have done and trying to open issues that are duplicate...
Huge pain in the ass dealing with contributions from people who don't understand enough to analyze their LLMs "findings" and just pass them through "in case they are helpful".
Might be nice once the fad of "everyone contribute by running duplicate reviews" subsides though.
Re: (Score:2)
It recently happened to me twice that, very quickly after opening a bug report for an OSS project on GitHub, a random dev with a very junior pedigree popped up, sending a PR to fix the issue.
The weird thing is that those PRs came with a strong vibecoding-bot vibe attached to them, not in the quality of the code, but rather in the way their devs handled interaction with the project's ecosystem - disregarding existing PRs and open tickets relating to the same issue, and not even attempting meaningful disc
Re: (Score:2)
Think the root is that folks see GenAI as their ticket to unskilled participation in a very highly paid industry.
However things go, that will not be the outcome, and I at least look forward to people being disinterested when it doesn't work that way (either they don't get to participate, or the industry won't be a high pay one anymore).
Re: (Score:2)
It is actually not that many, because the LLM peddlers are massively overstating things. And it is not even hard to find ones. For example, those "273 zero-days in FF" turned out to be 3 (!) in the actual patch notes, two of them use-after-free which really do not need LLMs to be found. GCC can do it. Good coding practices (setting pointers to NULL after freeing memory) prevent exploitability.
My take is these CVEs will be a lot of low-risk ones, many without exploits. In a kernel, these should definitely be
Re: (Score:2)
My take is these CVEs will be a lot of low-risk ones, many without exploits
Should be extremely simple, right? Just ask the LLM to write an exploit. Should be easy in an agentic chain. Too bad LLMs can't actually compile code.
Re: (Score:2)
No, I meant there may not be known exploits. Using an LLM does not change that. The thing is, many potential security bugs are really "risks" and it is not clear whether they are exploitable. May require special circumstances that are unknown. May actually be prevented by something else, but that something else can break in the future. May require a race-condition with really low probability and that is only there on some hardware. May not be exploitable at all, but better be careful. In a kernel, defensive
Re: (Score:2)
No, I meant there may not be known exploits. Using an LLM does not change that.
OK, ask the LLM to create some known exploits. If you're agentic, you can have it submit the patch automatically. Then if the kernel team is sufficiently agentic, they can approve the patch automatically and get it integrated. They are not quite there yet, but we don't need to do anything.
These problems all have solutions.
Re: (Score:3)
OK, ask the LLM to create some known exploits. If you're agentic, you can have it submit the patch automatically. Then if the kernel team is sufficiently agentic, they can approve the patch automatically and get it integrated.
I hope we NEVER get there. The last thing you want to do is let automated systems automate their own solutions that are automatically pushed out without any human overview and testing. You will suddenly wake up one day to "your" system farming crypto tokens for some random wallet somewhere....
Re: (Score:2)
Indeed. Also, LLMs are completely unsuitable to do a full code review. They miss a lot of critical things.
Re: (Score:2)
Seriously, have you read what I wrote? Something can be a security problem and NOT be exploitable.
Re: (Score:2)
The problem with that is, the patch will not take into account other parts of the system, coding standards, readability, and it will end up making the codebase harder to maintain. Do this at scale, and you will end up with a codebase which is unmaintainable.
That is assuming the patch really does fix the problem at all in the end. LLM's can't imagine exploit types which were not in their training data, so there are no guarantees at all this will be the case.
Re:Going to get worse before it gets better (Score:5, Insightful)
GCC can do it.
But it didn't.
Good coding practices (setting pointers to NULL after freeing memory) prevent exploitability.
But they didn't.
You can frame it any way you want, the end result is that exploits were found and patched. You assertion that it could have been done another way is irrelevant since those tools and practices have been available for a long time, and yet the zerodays persisted.
Re: (Score:2)
Unless "AI' unleashes a slew of new and improved security attacks because no one understands how it works enough to defend against them. There is an article on theRegister quoting some security guy that putting "AI" in a loop is only asking for clanker security attacks because the clanker can keep banging at the target in myriad different ways until it puts together a string of exploits resulting in a gonzo-whopper of an exploit: the Singularity has arrived, Kurzweil will get a hernia from his erection.
Probably just AI (Score:3)
I.e. low-hanging fruit being found because AI looks at things a bit differently. Should clear up soon.
Kind of does not make the kernel much more secure in general as AI only finds simple to find bugs, but needs to be done as attackers will use AI as well. Unfortunately, attackers can randomize the process, so this helps only against low/no-clue LLM-based attacks. But the no-clue AI fueled attackers are going to be a real problem for a while, hence this still is a good thing. Just do not read too much into it.
Re: (Score:2, Flamebait)
Kind of does not make the kernel much more secure in general
Ah yes. gweihir. The resident AI denialist.
This one has been lurking on any given firewalled network interface for 7 years: https://www.cve.org/CVERecord/... [cve.org]
This one is a subtle race in openvpn: https://www.cve.org/CVERecord/... [cve.org]
Two examples of either making the kernel demonstrably more secure, or identifying and correcting non-trivial problems. There are hundreds more [kernel.org], in case you'd like to get some of the shit out of your head.
Re: (Score:3)
LLMs have two effects here:
1. They help the white hats find and fix bugs
2. They help the black hats find and exploit bugs
These two effects cancel each other out to some extent (depending on which "team" is more proactive in its bug-discovery and consequent activities).
Eventually all of the low-hanging-fruit will be picked, and the current deluge of AI-induced CVEs will be reduced to only those bugs that were subtle enough not to be noticeable by anyone except the latest-and-greatest AI models.
Re: (Score:2)
Re: (Score:2)
And that is the problem here. While LLMs generally do not find complex bugs, they find simple bugs that humans have somehow overlooked. (Yes, that is a thing.) And for the black-hats they can do that fast. Even worse is the situation that LLMs can generate (crappy) exploit code from patches. Crappy exploit code still works. With high security requirements (as a kernel has), you want to patch even non-exploitable things fast now, because they could become exploitable later and then you run into this new patc
Re: (Score:2)
Re: (Score:2)
Nope, except occasionally by accident. They find things like use-after-free, which is so simple even "gcc -fanalyzer" finds them. LLMs cannot do complex reasoning. And that means they cannot generally find complex bugs. Your believe in magic does not change actual reality.
You also seem to be confused as to what "complex" means. It does not mean "unusual" and it does not mean "esoteric". It means "requires a complex reasoning chain" and LLMs cannot generally do those.
Re: (Score:2)
Nope. The problem here is that YOU cannot read.
Re: (Score:2)
Eventually all of the low-hanging-fruit will be picked, and the current deluge of AI-induced CVEs will be reduced to only those bugs that were subtle enough not to be noticeable by anyone except the latest-and-greatest AI models.
I mostly agree, although it will be bugs found by humans that remain. In highly visible software, humans still find a lot more than even the "frontier" models. And they find _different_ problems. LLMs cannot do logical reasoning. That limits what they can find and the fake reasoning they use instead has very limited reasoning depth. The same limit is not present ins smart humans. (Dumb ones, like the cult-of-the-LLM members, have the same limitation....)
The second thing that will likely happen is that soft
Re: (Score:2)
Kind of does not make the kernel much more secure in general
Ah yes. gweihir. The resident AI denialist.
Actually, I'm starting to think that this "gweihir" is actually somebody's bot tasked to argue against LLMs. Bot running one of the cheaper models, as his (its?) arguments on oftentimes quite lacking in thought and argumentation...
Re: (Score:2)
"AI only finds simple to find bugs" is ignorance.
Re: (Score:2)
1. That is not what I wrote. A simple mind could mistake it for that though.
2. What is true is that LLMs generally only find simple bugs. I have actual research on this.
There is ignorance and then there is ignorance. You have the second kind.
So who pays for support.....? (Score:1)
Make no mistake... (Score:5, Insightful)
AI is advancing rapidly and will become increasingly capable of analyzing machine code directly to uncover vulnerabilities and defects.
And unlike open-source projects, there won't be a large community ready to help identify, fix, and review those issues.
The clock is ticking...
Re: (Score:1)
Not really as the dude said:
He points to Android as proof the approach scales, calling it "the largest deployment of software in the world" -- billions of devices kept updated "with one very-overworked developer guiding it all."
The fact is there are billions of Android devices that are running out of date stuff AND it's not a huge disaster.
AI? (Score:4, Insightful)
Does everything these days have to be "AI" to be a news item? How about: Research group were given massive compute power via free so called "AI servers" to search the Linux Kernel for security problems.