Hong Kong: At Open Source Summit China, Greg Kroah-Hartman, maintainer of the Linux stable kernel, wants you to know that on an average week, the Linux security team issues sixty — 60 — Common Vulnerabilities and Exposures (CVE) security bulletins. Don’t stress. That’s just life in Linux.
Also: Windows update breaks Linux dual boot – but there is a fix for some users
But first, here are a few words about Linux and CVEs. Linux runs the world. It’s on your Android phone; it’s in your air-conditioning unit; it runs the web, powers supercomputers; the cloud; and maybe even your PC. You name it, Linux runs it. Yes, even iPhones, which use it for 4G and 5G.
CVEs track the world’s software security problems. For a CVE, or at least a Linux CVE, that means show-stopping problems. Lost data due to a bug? Not a CVE. The latest update just slowed your computer down to a crawl? No, not a CVE. Killed your server like a bug smacking a windshield at speed? Now, we’re talking about a CVE.
In February 2024, the Linux kernel developer team took over assigning CVEs for the Linux kernel. They did so because new government regulations, such as those from the European Union, required open-source projects to take responsibility for known vulnerabilities.
In addition, as Kroah-Hartman explained at the time, because while the CVE “system overall is broken in many ways… this change is a way for us to take more responsibility for this, and hopefully make the process better over time.” It also made sure that no other group could assign Linux CVEs without the Linux developers getting their say.
Also: 5 Linux terminal apps that are better than your default
Wait. Isn’t 60 CVEs a week about problems that can stop your computer dead in its tracks something to worry about? Well, yes. Then, again, no.
You see, Kroah-Hartman explained, today, the Linux kernel has “38 million lines of code. You only use a little bit of this. My laptop uses about one and a half million lines of code. …. Your phone, the most complex beast out there, uses about 4 million lines of code. So, out of everything, you’re really using a small portion, but everybody uses a different portion, and that’s an important thing to remember.”
The Linux kernel team doesn’t have a clue which portion you use in your product. Their job is to produce the core code that everyone uses. Each with its own unique configuration and use case.
Also: 10 things I always do immediately after installing Linux – and why
Kroah-Hartman quoted Ben Hawkes, a computer security expert, white hat hacker, and former manager of Google’s Project Zero, who summed up the situation nicely: “CVE doesn’t do a great job of capturing these nuances of the Linux kernel ecosystem. It’s hard to capture the fact that a bug can be super serious in one type of deployment, somewhat important in another, or no big deal at all – and that the bug can be all of this at the same time. Vulnerability remediation is hard.”
That’s why there are so many CVEs pouring out at such a frantic pace. Because with so many different systems and use cases out there, any bug can be a security bug. As Linus Torvalds said once, “security problems are just bugs.”
That, I might add, is with the kernel security team members being reactive. They respond to reported bugs and vulnerabilities. They triage incoming bug reports, determine if a security issue exists, and work with the relevant maintainers to fix the bug. They don’t go looking for bugs.
Once a fix is available, it is merged into the weekly stable kernel releases, which are pushed out to users as soon as possible. It is up to users to test and determine if a particular issue affects their specific use case.
Also: This lightweight Linux distro is the best way to revive your old computer. Here’s how
This crew doesn’t take embargoes or use pre-announcements. Why not? Because they believe – with reason – all these approaches do is lead to information leaks. Instead, they aim to get fixes out to users as quickly as possible. Typically, this is done within a week of having a patch available. This approach ensures that users are promptly notified of security issues and can update their systems accordingly.
–>
These stable releases include bug fixes and security issues backported from the mainline kernel. The team relies on a large community of testers, including companies and individuals, to ensure their stability and security.
What you can do to keep your system safe — whether it’s a car or 10,000 servers in a data center — is simple. Kroah-Hartman’s rule is “If you’re not using the latest stable/long-term kernel system, your system is insecure.”
By that, he means update your kernel almost every week. Now, most of you will find that notion as scary as dealing with 60 CVEs a week.
Also: 10 Linux keyboard shortcuts I depend on for maximum efficiency
The thing is, Kroah-Hartman said, “We have proof this can be done. Debian runs over 80% of the world’s servers and they’re using stable kernel updates. Android, billions of devices out there, takes every stable kernel update on a couple months lag, but they’re doing it and keeping their devices secure. There’s nothing more complex than embedded into the system, and there’s nothing more common and easy to use than a Debian server.
He hopes that, eventually, everyone will start using the quickly updated but ever more secure stable Linux kernels. People, he concluded, “think that the lack of change is stable, but, that’s only true if the world around you doesn’t change. Think of the infamous Intel Spectre and Meltdown bugs. Your hardware didn’t change. The world realized your hardware was broken. So, if you’re in a closed system that never changes, some banks have mainframes in the corner that never connect to the outside world, wonderful. Run that forever. Otherwise, if you’re attached to the world and the world changes, you’d better keep up to date.”
In short, don’t get worked up about the sheer volume of CVEs. Just be sure to check that nothing in the latest bunch affects your setup. Far more often than not, it won’t. To be truly safe, though, start updating your Linux kernel far more often than most of you do today.