Linux 7.1-rc5 is now listed on kernel.org as the current mainline release candidate, published on 2026-05-24. The available artifacts are the full linux-7.1-rc5.tar.gz source archive and patch options marked as full and incremental.
That is a small release note on paper. It is still useful. A fifth release candidate usually means the branch is no longer in the early churn phase, but it is not a stable kernel either. Treat it as a test target, not a production default.
What is known#
Kernel.org lists 7.1-rc5 under the mainline track. The release timestamp is Sun, 24 May 2026 20:48:06 -0000. The source package is named linux-7.1-rc5.tar.gz, with patch material available in full and incremental form.
The source item does not include a changelog summary, regression list, CVE note, exploit context, or maintainer commentary. So the safe claim is narrow: the fifth release candidate for Linux 7.1 is available from the official kernel release channel.
That narrowness matters. Kernel release candidates often attract broad claims from downstream posts: performance claims, security assumptions, or “ready soon” language. None of that is in this source item. If you need the actual code delta, compare the rc tags or inspect the corresponding patch set rather than relying on the release listing alone.
Why it matters#
Mainline release candidates are where integration risk becomes visible. Driver maintainers, distro kernel teams, platform vendors, and people running unusual hardware can use rc builds to find breakage before the stable release lands.
For security teams, the value is different. An rc is not something to rush into production for hardening. It is a preview of the kernel line that will soon influence downstream kernels, CI baselines, compatibility tests, and patch planning. If a subsystem you depend on is moving in 7.1, rc5 is late enough to start serious validation without pretending the branch is finished.
There is also a supply-chain point here. Kernel.org is the canonical distribution point for upstream Linux source archives and patches. If you are testing this build, fetch it from the official source and verify it using your normal release verification process. Do not treat reposted archives, random mirrors, or unverified build bundles as equivalent.
What not to overclaim#
Do not read “rc5” as “stable.” Release candidates are published precisely because the kernel still needs testing across hardware, filesystems, drivers, architectures, and workloads that upstream maintainers cannot fully reproduce on their own.
Do not infer a security fix from the release listing alone. The source item does not name vulnerabilities, affected versions, or patches tied to CVEs. Some kernel changes may have security relevance, but that must be established from commit history, advisories, or maintainer notes.
Do not infer that production distributions will ship this exact kernel soon. Distros carry their own schedules, backports, configuration choices, and support policies. A mainline rc can be important upstream while still being irrelevant to a managed production fleet until a vendor packages, tests, and supports it.
What to check next#
If you maintain kernel-facing software, test against 7.1-rc5 in CI where practical. Focus on the parts most likely to break silently: kernel modules, eBPF programs, storage paths, networking behavior, virtualization, GPU drivers, and platform-specific hardware support.
If you run production systems, the practical move is simpler: track the branch, but wait for stable or your vendor’s supported package unless you have a clear testing reason. Release candidates are for finding problems early, not for reducing operational risk by default.
For deeper review, compare the incremental patch against the previous release candidate and inspect the subsystems you actually depend on. The kernel release listing tells you that the artifact exists. The patch tells you what changed. Your workload tells you whether it matters.