Linux 5.10 and 5.15 End of Life (December 2026) and CVE-2026-98432
Two Linux longterm kernel branches reach their projected end of life in December 2026: 5.10 and 5.15. kernel.org publishes the month, not a day; we serve the last day of that month, December 31, 2026, as the date. After it, the stable team stops publishing fixes for the branch. The branches to move to are 6.12 and 6.18, both projected to December 31, 2028.
Every longterm branch on kernel.org
| Branch | kernel.org projection | Date we serve |
|---|---|---|
| 6.18 | December 2028 | December 31, 2028 |
| 6.12 | December 2028 | December 31, 2028 |
| 6.6 | December 2027 | December 31, 2027 |
| 6.1 | December 2027 | December 31, 2027 |
| 5.15 | December 2026 | December 31, 2026 |
| 5.10 | December 2026 | December 31, 2026 |
kernel.org states the month only and says plainly that these dates are projected and not set in stone: a new longterm kernel usually starts with a two-year projection, which is extended when enough of the industry commits to helping maintain it. A projection can move later. Plan on the published month and check again before you rely on an extension.
CVE-2026-98432: fixed on 5.10 and 5.15, no release for 4.19 or 5.4
On October 15, 2026 the Linux kernel CVE team published CVE-2026-98432, a use-after-free in the kernel's IPv4 TCP code (fix title: "ipv4: free inet_opt and ireq_opt after an RCU grace period"). A remote peer that sends connection requests carrying IPv4 options can race the setup of a connection against its teardown, and the kernel then reads and writes memory it has already freed while it builds its SYN-ACK reply. No login and no user action is needed on the target, only a listening TCP service. The kernel team's record lists every release since Linux 4.4 as affected until the fix.
The kernel team's record lists the fix in stable releases 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and mainline 7.3, and kernel.org has published all of them. There is no 4.19 or 5.4 release in that list. Neither is a longterm line on kernel.org any more: 5.4 reached end of life on December 3, 2025 and 4.19 on December 5, 2024. A self-built kernel, appliance or device firmware still on either line stays exposed unless whoever ships that kernel backports the fix; ask them whether they have.
Who scored it what (each vendor's page read on 2026-10-30). The kernel CVE team, which issues the kernel's CVEs, gives it a CVSS 3.1 base score of 9.8, Critical: network attack, low complexity, no privileges. SUSE scores it 8.1 and rates it important, Oracle Linux gives a preliminary 8.1, and Amazon Linux rates it Important at 8.1: all three set attack complexity to High, because the attacker has to win a race. Red Hat sides with the kernel CVE team: its CVE data rates it Critical at 9.8, a score Red Hat has now marked verified, and its VEX file carries 9.8, Critical (earlier on 2026-10-30 its CVE data showed Important at 8.1). Canonical gives it an Ubuntu priority of High. These are the publishers' scores, not our EOL Risk Score.
CVE-2026-98432 is not in CISA's Known Exploited Vulnerabilities catalog (catalog read 2026-10-30), and we found no report of exploitation in the wild. Anthropic's Frontier Red Team, which found the bug using Claude, describes a working proof of concept that ran commands as root on a server with a Multipath TCP (MPTCP) listener. The Go security team notes that Go programs enable MPTCP on Linux listen sockets by default as of Go 1.24, that the underlying bug is not specific to MPTCP, and that the fix is a patched kernel.
Distribution kernels
Distribution kernels get the fix from the distribution, on its schedule: check Red Hat, Ubuntu, SUSE, Oracle Linux and Amazon Linux. On 2026-10-30 Canonical's tracker listed the kernel in Ubuntu 16.04, 18.04 and 20.04 as Vulnerable, with no fix shown as in progress; all three are past standard support, so whether and how a fix arrives for them is Canonical's call. Ubuntu 14.04 is listed as not affected.
Who the kernel.org date applies to, and who it does not
The kernel.org date is the one that matters when there is no distribution standing behind the kernel:
- Custom and self-built kernels on servers, build farms and container hosts that track an upstream longterm branch directly.
- Embedded devices and appliances whose firmware was built on a longterm branch. The device keeps running; whether the vendor keeps rebasing onto a supported branch is the question to ask them.
- Vendor device kernels derived from a longterm branch, where the vendor depends on upstream stable releases for its security fixes.
- Distribution releases that are themselves out of support. Once the distribution stops, nobody is backporting into that kernel package either.
What to do before December
- Find every kernel you build or ship yourself. Inventory tools report a version string; what matters is who publishes the fixes for it. Separate distribution kernels from upstream-tracked ones.
- Take the CVE-2026-98432 fix first. On an upstream-tracked kernel that means the fixed stable release for your line (listed above) or anything newer on it. A kernel on 4.19 or 5.4 has no such release: move it to a maintained line, or get the backport in writing from whoever ships it.
- For upstream-tracked 5.10 and 5.15 systems, plan the move to 6.12 or 6.18 now. A kernel rebase on an embedded product is a test cycle measured in months, not an afternoon.
- For devices and appliances you buy, ask the vendor which kernel branch the current firmware is built on and what their plan is after December 31, 2026. It is a fair question for a procurement or security review.
- For distribution kernels, check the distribution release date, not this one: RHEL, Ubuntu, Debian, SLES.
Frequently Asked Questions
When do Linux kernels 5.10 and 5.15 reach end of life?
kernel.org projects end of life for both the 5.10 and the 5.15 longterm branches in December 2026. kernel.org publishes the month, not a day, and calls the date projected: it can be extended if there is enough industry interest in maintaining the branch.
Does the kernel.org end-of-life date apply to my RHEL, Ubuntu or Debian kernel?
No. Distributions maintain their own kernel packages and backport fixes into them, so a distribution kernel is supported for as long as the distribution release is, regardless of the kernel.org date for the version number it started from. The kernel.org date applies to anyone running an upstream longterm kernel directly: custom builds, embedded devices, appliances and many vendor device kernels.
Which Linux longterm kernel should I move to?
The two newest longterm branches on kernel.org are 6.12 and 6.18, both projected to December 2028. The 6.1 and 6.6 branches are projected to December 2027.
Is CVE-2026-98432 fixed on Linux 5.10, 5.15, 5.4 and 4.19?
The kernel CVE team's record lists a fixed stable release for 5.10, 5.15 and every newer longterm line. It lists no release for 4.19 or 5.4, which are no longer longterm lines on kernel.org, so a kernel still on either depends on its vendor backporting the fix. Distribution kernels get the fix, if at all, from the distribution. 5.10 and 5.15 themselves are projected to stop receiving fixes in December 2026.
Related
- Linux kernel — every branch, live status and EOL Risk Score
- RHEL minor versions — the other place a kernel quietly stops getting fixes
- Exploited & Unpatchable — CISA KEV entries on end-of-life software
- How we verify our dates