I still think it’s worth revisiting kernel release history pieces like this one, even years after the fact, because the changes that land in a given kernel version often quietly shape the distributions and hardware support we take for granted today. Linux kernel 5.18 was released by Linus Torvalds on May 22, 2022, and while Torvalds’ own announcement was characteristically understated — “no unexpected nasty surprises this last week, so here we go with the 5.18 release right on schedule” — the release actually packed in a substantial set of performance, security, and hardware support improvements that are worth understanding in detail, especially if you’re trying to build a mental timeline of how the kernel has evolved.
The Release Cycle Behind 5.18
Every mainline kernel release follows a predictable rhythm: roughly a two-week merge window where new code is accepted, followed by a series of release candidates (RCs) over several weeks to stabilize and bug-fix before the final release. Following a moderate release-candidate phase after Kernel 5.17, mainline Linux Kernel 5.18 became available for download, and true to form, Torvalds described the release cycle as typical of the eight release candidates that preceded it — no bad surprises, no significant or difficult additions, and no bugs that meaningfully hampered development. Immediately following release, the merge window for kernel 5.19 opened, continuing the kernel’s relentless, never-stopping development cadence.
Security Enhancements
Security-focused improvements were a meaningful theme in this release. Kernel 5.18 added support for Intel Indirect Branch Tracking on Intel CPUs, a hardware feature designed to help prevent certain classes of exploits that rely on redirecting program execution through indirect function calls — a technique commonly used in control-flow hijacking attacks. Alongside this, the kernel introduced stricter compile-time bounds checking for memcpy() operations, tightening up one of the most common sources of buffer-related vulnerabilities in C codebases.
On the storage side, a new kernel keyring called “machine” was introduced, containing the TPM’s Machine Owner Keys (MOK) — relevant to secure boot chains and systems that rely on the Trusted Platform Module for cryptographic attestation. The Xen USB driver was also hardened specifically against malicious hosts, an improvement aimed at virtualized environments where a compromised or malicious hypervisor host could otherwise attempt to attack a guest through USB device emulation.
One of the more talked-about (and genuinely controversial) additions was Intel’s Software Defined Silicon (SDSi) driver. This driver validates cryptographically signed licenses to enable dormant features already present in Intel silicon. Some in the community raised concerns that this could be an early step toward a business model where CPU functionality is deliberately locked behind paid unlock licenses, rather than shipping hardware with its full advertised capability enabled from the start. When pressed for specifics on exactly how the feature would be used commercially, Intel reportedly declined to share details at the time, which only fueled further speculation and scrutiny from the kernel community.
Performance Improvements
On the performance front, several changes targeted real-world workload efficiency. Better process scheduling performance was implemented specifically for AMD Zen CPUs, improving how the kernel distributes work across cores on one of the most widely deployed consumer and server CPU architectures at the time. The kernel also introduced fprobe, a faster function-call probing mechanism built on ftrace that provides quicker instrumentation across multiple functions using a single handler, compared to the older kprobes and kretprobes mechanisms — a meaningful improvement for anyone doing kernel-level performance tracing and debugging.
Filesystem performance also saw attention. The ext4 filesystem received bug fixes and improvements in ordered data mode that improved commit latency, while Btrfs gained support for two new ioctl() operations enabling direct reading and writing to a file’s extents, plus cross-mount reflink and deduplication support. Btrfs also gained “encoded I/O” support for its send/receive functionality — when using compression, the sending side previously had to decompress data and the receiving side had to recompress it before writing; this release let userspace tools read and write compressed extents directly, avoiding that redundant decompression/recompression cycle entirely.
The io_uring subsystem, the kernel’s modern high-performance asynchronous I/O interface, also received general improvements in this release, continuing its rapid maturation as an alternative to older, less efficient I/O models for applications that need to handle large volumes of concurrent I/O operations with minimal overhead.
Hardware and Architecture Support
Kernel 5.18 broadened hardware support considerably across several architectures. On ARM, 32-bit systems gained support for separate interrupt and virtually-mapped kernel stacks, while AArch64 (ARM64) gained support for the new QARMA3 pointer-authentication algorithm and shadow-stack build support. RISC-V architectures picked up support for the “Sv57” page-table format, a new performance monitoring implementation using the SBI PMU and Sscofpmf extensions, support for the SBI CPU-idle extension, and support for restartable sequences. 32-bit PowerPC systems gained live patching support along with the BPF program-packing memory allocator.
Graphics driver support saw real, user-facing improvements too. FreeSync video mode was enabled by default in this release, meaning users with supported monitors got smoother, tear-free variable refresh rate output without any manual configuration required. The AMDGPU driver received further updates preparing for future hardware, work progressed on supporting Intel’s Arc graphics processors and Intel Alder Lake N, and support for higher DisplayPort rates was added as well.
Wireless and connectivity hardware also expanded. New wireless hardware support was added for MediaTek MT7916, MT7921U, and Broadcom BCM43454/6 chipsets, alongside support for Intel M.2 WWAN cards for mobile connectivity. The Realtek W89 driver gained AP mode support, 6 GHz band support, and a new hardware scan feature.
Storage hardware support notably included Apple hardware. Kernel 5.18 added the initial open-source Apple NVMe driver, addressing the unusual fact that Apple’s NVMe implementation in M1 Macs isn’t connected via the standard PCIe bus for data transfer and instead runs a proprietary real-time operating system — a genuinely unusual hardware design that required dedicated driver work to support properly under Linux. The release also added support for 64-bit integrity checksums on NVMe devices, and separately, 64-bit ARM systems gained Tesla FSD (Full Self-Driving) chip support, reflecting the kernel’s reach into increasingly specialized automotive and embedded silicon.
Filesystem Changes
Beyond the Btrfs and ext4 improvements already mentioned, kernel 5.18 made a notable filesystem deprecation: support for the ReiserFS file system was formally deprecated, marking the beginning of the end for a filesystem that had largely fallen out of active use and maintenance in the broader Linux ecosystem. A new keep_last_dots mount option was added to the exFAT filesystem, preventing exFAT from stripping trailing periods from file names — a small but meaningful compatibility fix for interoperability with systems that legitimately use trailing dots in filenames. The EROFS read-only filesystem also saw improvements to meta buffer operations, and more broadly, this release stopped clearing VolumeDirty state during writeback for certain filesystem operations, an important change intended to avoid unnecessarily shortening the lifespan of storage devices.
Compiler and Toolchain Modernization
A structurally significant change in 5.18 was a shift in the C standard the kernel targets. The kernel had historically been limited to the older C89 standard, which lacked features increasingly needed by modern kernel development, so the project moved to C11, a switch made feasible because the minimum required GCC compiler version (5.1) already fully supported it. This kind of toolchain modernization doesn’t produce flashy headlines, but it matters enormously for the kernel’s long-term maintainability, giving developers access to modern language features going forward.
The release also included some preparation work for a broader rearchitecting of kernel headers aimed at significantly faster build times, introducing early pieces of that restructuring within the task scheduler subsystem — groundwork that would continue to pay off in later kernel releases through reduced compilation time across the kernel tree.
Networking and Bridge Improvements
The bridge subsystem gained support for multiple spanning trees, and the express data path (XDP) mechanism gained fragment support, both relevant to advanced networking configurations and high-performance packet processing setups. Various improvements were also made to IPv6 configuration handling and several networking protocols, including performance optimizations across the networking stack, alongside broader driver API and core networking functionality improvements documented in the kernel’s networking changelog for this cycle.
Tracing and Observability
Kernel 5.18 introduced support for “user events,” which allow userspace processes to create and write to trace events that are isolated from kernel-level trace events, only surfacing trace information when tracing is actively enabled. Combined with the fprobe mechanism mentioned earlier, this release meaningfully expanded the kernel’s built-in observability tooling — genuinely valuable for anyone doing performance debugging or building monitoring infrastructure that needs low-overhead visibility into what a running system is actually doing.
What This Release Represented in Context
Kernel 5.18 is a good illustration of how most kernel releases actually work in practice: there’s rarely a single “headline” feature that defines a version. Instead, each release is an accumulation of dozens of smaller, individually modest improvements across architecture support, filesystems, security hardening, networking, and tooling — the kind of steady, incremental engineering that, viewed over several years, adds up to dramatic overall improvement. Torvalds’ own framing — encouraging developers to simply “run boring old plain 5.18” before getting excited about the next release — captures this well: stability and incremental progress, not dramatic reinvention, is the normal rhythm of kernel development.
How Kernel 5.18 Reached End Users
It’s worth understanding that a mainline kernel release like 5.18 doesn’t immediately show up on your desktop the moment Torvalds announces it. Distributions maintain their own packaging and testing pipelines, and different distributions adopt new kernel versions on very different timelines depending on their release philosophy. Rolling-release distributions like Arch Linux typically ship a new mainline kernel within days or weeks of release, once basic compatibility testing clears. Fixed-release distributions with a more conservative update cadence, such as Debian stable or Ubuntu LTS releases, generally stick with whatever kernel version shipped with that particular release for the majority of its support lifetime, only updating for critical security backports rather than jumping to each new mainline version.
This is exactly why “which kernel am I running” and “which kernel features are actually available to me” are two different questions in practice. A Debian stable system released around the same time as kernel 5.18 might have shipped with an entirely different kernel version, backported with specific security fixes rather than the full upstream feature set. Checking your actual running kernel with uname -r and cross-referencing your distribution’s specific kernel packaging documentation is the only reliable way to know exactly what’s available on a given system, rather than assuming based on the mainline kernel release notes alone.
Long-Term Support and Kernel Maintenance
Not every kernel release receives the same level of ongoing maintenance. The vast majority of mainline releases, 5.18 included, are what’s called a “stable” release in kernel terminology — meaning it receives bug-fix backports only until the next mainline version supersedes it, typically a window of just a couple of months. A smaller subset of kernel versions are designated Long Term Support (LTS) releases, receiving security and bug fixes for several years, specifically to give distributions and embedded device manufacturers a stable foundation to build long-lived products on without needing to constantly rebase onto entirely new kernel versions.
This distinction matters enormously for anyone choosing a kernel version for production infrastructure or embedded hardware with a multi-year support requirement — picking a random short-lived stable release like 5.18 for something meant to run untouched for years would mean losing security patch coverage relatively quickly, whereas selecting a designated LTS kernel provides a much longer runway of maintained fixes.
Why Kernel Version History Still Matters
Even years later, understanding what changed in a specific kernel release is genuinely useful for system administrators and developers. If you’re troubleshooting hardware compatibility on an older system, or maintaining infrastructure running a specific long-term-support kernel branch, knowing precisely which version introduced support for particular hardware, filesystem features, or security mitigations lets you make informed decisions about whether upgrading is worthwhile, and exactly what you’d gain by doing so. You can always check which kernel version is currently running on a given system with:
uname -r
And cross-reference that against kernel release notes on kernelnewbies.org or similar changelogs to understand exactly what capabilities are (or aren’t) available.
Summary
Linux kernel 5.18 arrived in May 2022 as a solid, if unremarkable-on-the-surface, release — exactly as Torvalds framed it. Underneath that modest framing sat meaningful security hardening (indirect branch tracking, stricter memcpy bounds checking, hardened Xen USB handling), real performance gains (AMD Zen scheduling improvements, Btrfs and ext4 filesystem enhancements, io_uring refinements), and broad hardware enablement spanning ARM, RISC-V, PowerPC, new wireless chipsets, and even Apple Silicon NVMe support. It’s a snapshot of exactly how the Linux kernel actually improves release after release: not through singular dramatic leaps, but through the steady accumulation of contributions from a genuinely enormous, distributed developer community.
References
- Linux Kernel Newbies — Linux 5.18 changelog: https://kernelnewbies.org/Linux_5.18
- The Linux Kernel Archives: https://www.kernel.org/
- Linux kernel mailing list (LKML) archives: https://lkml.org/
- 9to5Linux — Linux Kernel 5.18 Officially Released: https://9to5linux.com/linux-kernel-5-18-officially-released-this-is-whats-new