The 24-day gap
A critical Linux kernel fix that did not reach users for weeks, and what the Network and Information Security Directive (NIS2) and the Cyber Resilience Act (CRA) do not yet answer. European Union (EU) / International edition, 11 pages, free.
At a glance
A critical Linux kernel flaw, listed as Common Vulnerabilities and Exposures (CVE) entry CVE-2026-98432, was fixed upstream on 5 October 2026. On 29 October, 24 days later, Canonical (Ubuntu) and Red Hat (Red Hat Enterprise Linux, RHEL, versions 8, 9 and 10) still had no fixed kernel, while Debian, SUSE and Oracle Linux did. Two days earlier an artificial intelligence (AI) model had been shown building a working root exploit in about 53 minutes. Thousands of European entities have a legal duty to apply “state of the art” security measures, and for these weeks the state of the art was a patch they could not install.
Key findings
- Remote, before login. A use-after-free in the Internet Protocol version 4 (IPv4) Transmission Control Protocol (TCP) connection path, reachable without any account. Rated 9.8 by the kernel CVE team; Red Hat raised its rating to 8.1 (Important) on 29 October.
- Not a Multipath TCP (MPTCP)-only bug. The defect is in plain TCP/IPv4. MPTCP is also more common than assumed: on by default in Ubuntu 26.04 and used automatically by Go 1.24+ servers.
- The gap is downstream. Upstream fixed it fast and stable kernels shipped 11–15 October. The exposure was created in the distribution step, between upstream and the customer, where commercial distributors such as Canonical and Red Hat test and ship fixes.
- The window is shrinking on one side only. Exploit development time is collapsing; upstream-to-customer patch time is not.
- The law has a gap too. NIS2 Article 21 expects compensating measures when no patch exists but says little about what is proportionate. The CRA puts duties on commercial distributors, not on the volunteer upstream, and its main requirements apply only from 11 December 2027.
- Small member states carry more risk. Where one operator runs a whole sector, the same window becomes a national exposure. Cyprus is used as a case study.
What to do now
Block inbound IPv4 packets carrying IP options, disable MPTCP where it is not needed, record the risk decision in writing, ask your vendor for a fix date in writing, and install the fixed kernel as soon as it ships. Patch status changes quickly; check vendor advisories before acting.
Who it is for
Chief information security officers (CISOs) and security teams running Linux, NIS2 essential and important entities, national computer security incident response teams (CSIRTs) and competent authorities, EU policy teams working on NIS2 and the CRA, and Linux vendors such as Canonical and Red Hat, and open-source foundations.
Turn the gap into a decision
We help leadership teams set patch-latency targets, document risk decisions for NIS2, and prepare for the Cyber Resilience Act.
Download the full report
Free. Tell us who you are and we'll give you the report as a PDF (Portable Document Format) file straight away.
