Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Significant raise of reports

lwn.net

Post reply on HN
Print view View original

81–90 of 164 posts

Re: Significant raise of reports

#81

Post by bri3d »

piinbinary wrote: post #44

I'd be very curious to know what class of vulnerability these tend to be (buffer overrun, use after free, misset execute permissions?), and if, armed with that knowledge, a deterministic tool could reliably find or prevent all such vulnerabilities. Can linters find these? Perhaps fuzzing? If code was written in a more modern language, is it sill likely that these bugs would have happened?

> Can linters find these? Perhaps fuzzing?

That's what syzbot / syzkaller does, as mentioned in the article, with somewhat similar results to the AI-fuzzing that they've been experiencing recently.

The issue that Linux maintainers have in general is that there are so many of these "strict correctness and safety" bugs in the Linux codebase that they can't fix them all at once, and they have no good mechanism to triage "which of these bugs is accessible to create an exploit."

This is also the argument by which most of their bugs become CVEs; in lieu of the capability to determine whether a correctness bug is reachable by an attacker, any bug could be an exploit, and their stance is that it's too much work to decide which is which.

Re: Significant raise of reports

#82

Post by franktankbank »

DarkNova6 wrote: post #76
chromacity wrote: post #70

> people will finally understand that security bugs are bugs, and that the only sane way to stay safe is to periodically update, without focusing on "CVE-xxx" Linux devs keep making that point, but I really don't understand why they expect the world to embrace that thinking. You don't need to care about the vast majority of software defects in Linux, save for the once-in-a-decade filesystem corruption bug. In fact, t…

And this is the best-case scenario. Because once updates become opt-out it simply becomes an attack vector of another type. If the updated code is not open source, you are trusting blindly that not some kind of different remote code execution just happened without you knowing it.

If you don't personally review every line then you are already trusting blindly.

Re: Significant raise of reports

#83

Post by geraldcombs »

tyre wrote: post #79

I wish they wouldn’t call it “AI slop” before acknowledging that most of the bugs are correct. Let’s bring a bit of nuance between mindless drivel (e.g. LinkedIn influencing posts, spammed issues that are LLMs making mistakes) vs using LLMs to find/build useful things.

If I read the sentence correctly they're saying that past reports were AI slop, but the state of the art has advanced and that current reports are valid. This matches trends I've seen on the projects I work on.

Re: Significant raise of reports

#84

Post by crote »

zozbot234 wrote: post #62
crote wrote: post #53

Earlier quoted context omitted.

It's the classic "misunderstanding" that UB or buggy unsafe code could in theory corrupt any part of your running application (which is technically true), and interpreting this to mean that any codebase with at least one instance of UB / buggy unsafe code (which is ~100% of codebases) is safety-wise equivalent to a codebase with zero safety check - as all the safety checks are obviously complete lies and therefore po…

If you're talking about Rust codebases, I'm pretty sure that writing sound unsafe code is at least feasible. It's not easy , and it should be avoided if at all possible, but saying that 100% of those codebases are unsound is pessimistic. One feasible approach is to use "storytelling" as described here: https://www.ralfj.de/blog/2026/03/13/inline-asm.html That's talking about inline assembly, but in principle any othe…

It's not impossible, it is just highly unlikely that you'll never write a single safety-related bug - especially in nontrivial applications and in mixed C-plus-Rust codebases. For every single bug-free codebase there will be thousands containing undiscovered subtle-but-usually-harmless bugs.

After all, if humans were able to routinely write bug-free code, why even worry about unsoundness and UB in C? Surely having developers write safe C code would be easier than trying to get a massive ecosystem to adopt a completely new and not exactly trivial programming language?

Re: Significant raise of reports

#86

Post by hyperpape »

franktankbank wrote: post #82
DarkNova6 wrote: post #76

Earlier quoted context omitted.

And this is the best-case scenario. Because once updates become opt-out it simply becomes an attack vector of another type. If the updated code is not open source, you are trusting blindly that not some kind of different remote code execution just happened without you knowing it.

If you don't personally review every line then you are already trusting blindly.

As blind as my belief that Asia exists, because I haven't personally navigated there. Hell, I've used electricity (using it right now), but I couldn't do the experiments you need to do to get myself to an 1850s level of understanding of how it works, much less our current level.

I trust that Linux has a process. I do not believe it is perfect. But it gives me a better assurance than downloading random packages from PyPi (though I believe that the most recent release of any random package on PyPi is still more likely safe than not--it's just a numbers game).

Re: Significant raise of reports

#87

Post by thinkharderdev »

tyre wrote: post #79

I wish they wouldn’t call it “AI slop” before acknowledging that most of the bugs are correct. Let’s bring a bit of nuance between mindless drivel (e.g. LinkedIn influencing posts, spammed issues that are LLMs making mistakes) vs using LLMs to find/build useful things.

I think they are saying what you want them to say. In the past they got a bunch of AI slop and now they are getting a lot of legit bug reports. The implication being that the AI got better at finding (and writing reports of) real bugs.

Re: Significant raise of reports

#88

Post by rcxdude »

chromacity wrote: post #70

> people will finally understand that security bugs are bugs, and that the only sane way to stay safe is to periodically update, without focusing on "CVE-xxx" Linux devs keep making that point, but I really don't understand why they expect the world to embrace that thinking. You don't need to care about the vast majority of software defects in Linux, save for the once-in-a-decade filesystem corruption bug. In fact, t…

I think part of it is that, especially at the kernel level, it can be hard to really categorise bugs into security or not-security (it has happened in the past that an exploit has used a bug that was not thought to be a security problem). There's good reason to want to avoid updates which add new features and such (because such changes can introduce more bugs), but linux has LTS releases which contain only bug fixes (regardless of security impact) for that situation, and in that case you can just stay up to date with very minimal risk of disruption.

Re: Significant raise of reports

#89

Post by miki123211 »

chromacity wrote: post #70

> people will finally understand that security bugs are bugs, and that the only sane way to stay safe is to periodically update, without focusing on "CVE-xxx" Linux devs keep making that point, but I really don't understand why they expect the world to embrace that thinking. You don't need to care about the vast majority of software defects in Linux, save for the once-in-a-decade filesystem corruption bug. In fact, t…

And if you're the kind of person who cares about that, you pay a vendor that gives you 10 years on the same distro version.

Or just use an off-brand RHEL I guess.

Re: Significant raise of reports

#90

Post by zozbot234 »

crote wrote: post #84
zozbot234 wrote: post #62

Earlier quoted context omitted.

If you're talking about Rust codebases, I'm pretty sure that writing sound unsafe code is at least feasible. It's not easy , and it should be avoided if at all possible, but saying that 100% of those codebases are unsound is pessimistic. One feasible approach is to use "storytelling" as described here: https://www.ralfj.de/blog/2026/03/13/inline-asm.html That's talking about inline assembly, but in principle any othe…

It's not impossible, it is just highly unlikely that you'll never write a single safety-related bug - especially in nontrivial applications and in mixed C-plus-Rust codebases. For every single bug-free codebase there will be thousands containing undiscovered subtle-but-usually-harmless bugs. After all, if humans were able to routinely write bug-free code, why even worry about unsoundness and UB in C? Surely having de…

Rust is not really "completely new" for a good C/C++ coder, it just cleans up the syntax a bit (for easier machine-parsing) and focuses on enforcing the guidelines you need to write safe code. This actually explains much of its success. The fact that this also makes it a nice enough high-level language for the Python/Ruby/JavaScript etc. crowd is a bit of a happy accident, not something that's inherent to it.
Post reply on HN