If all kernel bugs are security bugs, how do you keep your Linux safe?
Penguins need their sleep, but Linux admins must never rest.
Want to know what's happening with Linux kernel development? Subscribe to the Linux Kernel Mailing List. Want to know what's what with the Linux kernel at a deep level, but without tracking every last detail? Subscribe to Linux Weekly News (LWN).
But, if you want a broad, quick overview of the state of the Linux kernel, do what I did: catch Jonathan Corbet, Linux kernel developer, and LWN editor-in-chief, giving one of his state-of-the-kernel presentations at a major Linux conference.
At Open Source Summit North America in Seattle, Corbet agreed with Linus Torvalds, who had said earlier at the same show that everything's "calm and steady and boring" with the next kernel, Linux 6.9. That calmness is good news.
Also: Thinking about switching to Linux? 10 things you need to know
However, Corbet also said there's some concerning news: "In the kernel, just about any bug, if you're clever enough, can be exploitable to compromise the system. The kernel is in a unique spot in the system ... it turns a lot of ordinary bugs into vulnerabilities."
Now, there's nothing new about that situation. All operating system bugs have the potential to become exploitations. This fact is underlined by Linux kernel developers recently starting to issue their own Common Vulnerabilities and Exposures (CVE) notifications. And as Corbet explained: "Since just about any bug could be a vulnerability, we're going to be careful, and we're going to be cautious. And we're going to assign a CVE number to just about anything that looks like it could be a vulnerability at some point in the future."
Also: 5 Microsoft Edge features that might make it my new favorite Linux browser
That approach means there are now hundreds of Linux kernel CVEs. Since February alone, Corbet said there have been 800 new assigned CVEs.
What can you do to ensure the safety and security of your Linux systems? Simple: Make sure your distribution runs long-term stable (LTS) kernel releases. These releases have fixed CVEs, and as new issues are patched, they're ported into the LTS kernels.
That said, it should be remembered that Corbet pointed out that LTS releases won't be supported as long as they used to be. LTS versions are now supported for only two years, not six. So, as of January 2024, Linux 4.14 was no longer supported. At the end of the year, this release will be joined in retirement by the 4.19 kernel. By 2026, only the two most recently released LTS versions will be supported.
Also: Long-term support for Linux kernel to be cut as maintenance remains under strain
If you're not sure what version you're using, run the following command from the shell:
$ uname -r
If you get any result besides a blank, you're running an LTS.
Why aren't the kernel developers supporting versions for longer? The answer is a decrease in use (very few people, for example, were still running the six-year-old 4.14 kernel) and the practical difficulties of maintaining outdated software. This change underscores a broader shift toward current versions, which are easier to support and secure.
Also: Sparky Linux is a blazing-fast distro that can keep your older machines running for years
If you're attached to a particular Linux kernel version, your distro builder may be willing to help you. Canonical, for example, provides its LTS Ubuntu versions with 12 years of support. OpenELA, a trade association of Linux distributor CIQ, the company backing Rocky Linux, Oracle, and SUSE, is also offering -- via kernel-lts -- a new lease of life for the 4.14 kernel. OpenELA may also provide extended support for other LTS Linux distros as they near the end of life.
But, looking ahead, many of you may be updating your main Linux distributions more often if you want to be safe. And, trust me, you want to keep your Linux machines secure. We recently came too close to a major security bug, XZ, slipping into Linux.
Outside of security issues, Corbet said the Linux kernel developers had recently finished "the busiest development cycle yet". That cycle was for the 6.7 kernel release, which boasted an impressive 17,000 commits and was released in early January.
Looking ahead, the forthcoming 6.9 release has "only" about 14,000 commits. But the effort behind the scenes is not just about volume. Measuring commits or lines of code (LoC) is a loser's way of looking at programming work. What matters most is the quality and range of features, such as memory management enhancements and the integration of Rust code on ARM64 architectures.
Also: How to replace Windows with Linux Mint on your PC
Moving away from code, Corbet noted that the Linux kernel developer team has been trending in a good way lately. Each of the recent cycles has seen at least 200 first-time contributors. It wasn't that long ago we worried about the Linux kernel developers graying out. With this wave of new programmers, Corbet sees "the community staying vibrant and forward-moving".
Still, as Corbet also remarked, we need to encourage companies "to better support our community." That's because maintainers and long-time developers are burning out. They need more money and support. Without this assistance, we can expect more burnout, frustrated developers, a drop in code quality, and, eventually, more security problems.
Corbet suggests looking at the Linux Kernel Contribution Maturity Model to see how your business is doing. The bottom line is companies must treat Linux work as a top priority and not as an afterthought. This effort might not contribute directly to the bottom line, but, at this point, almost all businesses depend on Linux to keep running -- and you can ignore this fact at your peril.