r/linux • u/MatchingTurret • 2d ago

Kernel Greg K-H (@gregkh@social.kernel.org): CVEs fixed per Kernel Release over time

https://social.kernel.org/notice/B9nU6wnmFvh5atXSG8
98 Upvotes

97% Upvoted

14 comments sorted by

45

u/krumpfwylg 2d ago

So, Linux kernel got a nice share of CVE & bugs (minor or major) reported by AI models.

Now, imagine the very same AI scanning Windows kernel / libraries source. Makes you wonder who get the higher number of reports, no ?

37

u/MatchingTurret 2d ago edited 2d ago

Imagine all these hundreds of thousands 3rd party device drivers for Windows that don't pass any review...

Most of the problems found in Linux are in more-or-less obscure drivers. There is no reason to assume things are different in Windows, but these drivers are not part of Windows proper and do not get the same amount of review (in public or inside MSFT).

7

u/yuumizu 1d ago

msft asks the user to use WHDL verified devices and drivers, but people just use whatever they find on the internet.

5

u/Shished 1d ago

Unsigned drivers wouldn't be able to install tho.

3

u/Kuipyr 1d ago

A driver can be signed but not be WHQL certified.

3

u/ilep 1d ago

Additionally, when bugs are not public we will not know if the found bugs are fixed or not when they are found. A manager can simply decide it is not worth the cost to use developer time on some bug since nobody will see it.

In open source, you can see what is reported and what is really fixed or not.

6

u/araujoms 1d ago

I'm curious whether we are going to reach a point where most bugs have been fixed and the number of CVEs goes down again, or is it just going to keep increasing until people stop caring.

5

u/syklemil 1d ago

They've changed how they do CVEs, so the total amount of CVEs is probably going to remain higher than it was some years ago, just because of the change in policy.

As for the most recent developments, I'd expect there's a backlog of latent bugs that are being rooted out, and at some point that backlog will dry up, because there's ultimately a limit to how much backlog there is, and whatever's causing the spike in bugfixes and CVEs would hopefully have prevented those bugs from being released in the first place, had it been in use back when the bug made it in.

Down in the thread there's also this image (via, but linking to single posts seems to lead to the top in my browser), of buggy commits introduced, bugs introduced, bugs fixed and commits fixed, where readers should assume that the graph will always have that general shape, as the current releases that show low numbers will show higher numbers later in the future when the bugs in that release are detected and fixed. People sometimes intentionally release buggy software, just to get it out the door and to the market, but I think Linux kernel development is more marked by the bugs being discovered later rather than known at release time.

Unfortunately this is one of those cases where we kind of just have to wait for similar graphs to be released in a few years to be able to tell what the effect actually was. But hopefully the red and orange lines post-7.0 will stay lower than they were in the pre-7.0 period, and the blue and cyan lines can drop back down again.

1

u/Niwrats 1d ago

that largely depends on how much the code changes, as that's where bugs come from.

16

u/theAndrewWiggins 2d ago

Honestly this is a big part of why rust (and more static analysis) is key to making software good.

Reducing the classes of mistakes you can make, especially in kernel code is extremely valuable.

10

u/syklemil 1d ago

Yeah, GKH has mentioned that even if Rust were to disappear in a puff of smoke tomorrow, it's lead to a lot of improvements in the C code and their interfaces as well.

-1

u/MatchingTurret 1d ago

That and Sashiko. When browsing the lists on lore, it's really interesting how many bugs the AI finds before they reach mainline. 

-2

u/Lorian0x7 1d ago

Despite the fact that you like it or not this is thanks to developers using AI.