A Linux Kernel Update Still Needs a Running-Kernel Receipt

A Linux server downloads a repaired kernel package. The package manager exits cleanly. The dashboard turns green, and the maintenance ticket closes. Three weeks later, the machine is still running the old kernel because nobody completed the restart.

That gap matters this week. On 18 September 2026, the US Cybersecurity and Infrastructure Security Agency added three Linux kernel vulnerabilities to its Known Exploited Vulnerabilities catalogue. The entries cover CVE-2025-39682 in kernel TLS handling, CVE-2026-53266 in an ebtables address rewrite, and CVE-2025-39964 in the kernel’s cryptographic socket interface. CISA marked all three as supported by evidence of active exploitation and set a 21 September deadline for covered US federal agencies (CISA: Known Exploited Vulnerabilities catalogue).

The deadline is not a claim that every Linux machine was remotely exposed or compromised. Each defect sits in a particular kernel subsystem, and the path to it depends on the running kernel, enabled features, configuration, and the attacker’s existing access. The Hacker News independently described the same three catalogue additions while noting those different mechanisms (The Hacker News: CISA flags three Linux kernel vulnerabilities).

The durable lesson is smaller and more useful than “Linux is under attack.” A package receipt proves that repaired files reached a machine. It does not prove that the machine booted them, that every image and node pool received them, or that evidence from the earlier exposure window was checked. Kernel patching needs a running receipt.

What CISA added, and what it did not say

CISA’s catalogue is a prioritisation tool. An entry means the agency has evidence that attackers have exploited the vulnerability somewhere. It does not provide a public victim list, an exploit chain for every distribution, or proof that your host exposes the affected path. As of 22 September 2026, the three entries list ransomware use as unknown and require forensic triage for covered agencies.

The first entry, CVE-2025-39682, concerns kernel TLS, often shortened to kTLS. This feature moves some Transport Layer Security record processing into the kernel. CISA describes a flaw in handling a zero-length record on the receive list. The bad state can cause later records to be processed under the wrong assumptions about queues and zero-copy handling. Debian’s tracker carries the upstream technical description and links the repair to the kernel source history (Debian Security Tracker: CVE-2025-39682).

The second entry, CVE-2026-53266, sits in ebtables, the older bridge-filtering framework used around Ethernet traffic. The flaw affects an optional source-address rewrite for Address Resolution Protocol packets. Under a particular arrangement of packet memory, the code could write into a fragment that was not made writable first. CISA classifies it as an out-of-bounds write, while Debian’s record preserves the narrower upstream explanation (Debian Security Tracker: CVE-2026-53266).

The third, CVE-2025-39964, involves AF_ALG, a Linux socket interface through which user-space software can request kernel cryptographic operations. Concurrent writes to the same socket could interleave data and leave the socket’s internal state inconsistent. The upstream repair disallows that unsafe concurrent use rather than trying to make ambiguous input ordering reliable (Debian Security Tracker: CVE-2025-39964).

Those descriptions are not interchangeable. One flaw concerns a TLS receive path. One concerns bridge packet rewriting. One concerns concurrent use of a cryptographic socket. Grouping them under “three Linux zero-days” may make a sharper headline, but it makes poor operational guidance. Different code paths imply different prerequisites, affected products, mitigations, and evidence.

CISA’s 18 September action does establish urgency. The agency gave covered federal systems three days, until 21 September, and each entry says to apply vendor instructions, assess internet exposure, and follow its forensic-triage requirements. The unusually short window is a reason to bring these flaws forward in the queue. It is not permission to skip the work of identifying the correct vendor package or proving that the repaired kernel is active.

The catalogue also warns that open-source components can appear inside many products. A Linux kernel may arrive through Ubuntu, Debian, Red Hat Enterprise Linux, Amazon Linux, a cloud image, an appliance vendor, a container-hosting platform, or an embedded product. The upstream commit answers whether source code contains a repair. The product vendor answers whether its shipped build needs an update.

A kernel version is not a simple greater-than comparison

Teams often meet a Linux advisory with one familiar command: uname -r. That command is useful because it reports the running kernel release. It cannot, by itself, tell you whether a vendor backported a repair into an older-looking version string. Linux distributions routinely maintain a kernel line and apply selected fixes without moving every customer to the newest upstream release.

Ubuntu’s advisory pages make the resulting matrix visible. As of 22 September 2026, its CVE records list many kernel packages across supported releases, cloud flavours, real-time variants, hardware enablement stacks, and architecture-specific builds. A package may be fixed for one release, still under investigation for another, absent from a third, or outside support. The status for CVE-2026-53266 alone varies across that package and release matrix (Ubuntu: CVE-2026-53266).

The same is true for CVE-2025-39682 and CVE-2025-39964. Ubuntu’s records expose package-level status rather than asking administrators to compare one upstream number with every machine (Ubuntu: CVE-2025-39682; Ubuntu: CVE-2025-39964). That is the right model. Distribution, release, kernel flavour, package build, and support state belong in the decision.

A scanner that says “kernel 6.8 is vulnerable” may therefore be wrong in either direction. The vendor may have backported the repair into its 6.8 package, making the apparent old version safe for that defect. Another machine may show a newer upstream-looking release while running an unsupported custom build that never received the vendor patch. Version comparison without provenance produces confidence, not proof.

Start with ownership. Record which repository or image pipeline supplies each host’s kernel. For ordinary distribution hosts, preserve the package name and installed build. For managed Kubernetes nodes, record the node image and release channel. For immutable images, find the image digest and build run. For appliances, use the appliance vendor’s bulletin rather than assuming the visible kernel string maps directly to a public distribution.

Then ask the vendor’s exact question. Is this product, release, architecture, and kernel flavour affected? Which package or image contains the repair? Does the vendor prescribe a reboot, a live patch, a mitigation, or migration away from an unsupported build? A generic CVE page can start the search. It cannot finish it.

This precision is not bureaucracy. It prevents two expensive mistakes. The first is emergency work on systems whose vendor already shipped the repair months ago. The second is clearing a host because its version string looks newer while the running artifact still lacks the fix. Both mistakes come from treating “Linux” as one product.

Installed is not running

A kernel package has an unusual deployment boundary. Most application updates replace a file and affect the next process start. A conventional kernel update writes a new kernel and related files to disk, then arranges for a bootloader to choose them later. The old kernel remains in memory and continues controlling the machine until a reboot activates the new one.

Picture a server running release A. The package manager installs repaired release B at 10:00 and exits successfully. At 10:01, the filesystem contains B, but every system call, network packet, namespace, and device operation still passes through A. If the maintenance system asks only whether B is installed, it will mark a machine repaired while the vulnerable code remains active.

That is the receipt gap. Package state answers “what is available for the next boot?” Running state answers “what code holds kernel authority now?” The second question decides whether the patch has taken effect.

The exact commands differ by distribution, but the evidence model does not. Capture the running release from the operating system. Capture the vendor package or image that should be active. Compare them using the vendor’s package semantics. If the host uses live kernel patching, capture the live-patch status and the vendor’s statement that the relevant function is covered. A live-patch client showing “healthy” is not enough if that CVE was outside the applied patch set.

Reboots add another quiet failure mode: the machine may boot a different entry than the operator expected. A stale bootloader configuration, failed image rollout, pinned node pool, or rollback can bring the old kernel back. The receipt must be collected after the restart, not inferred from the command that requested it.

Virtual machines and fleet orchestration make the gap easier to hide. An autoscaling group may replace most instances while leaving a long-lived exception. A Kubernetes upgrade may move one node pool and leave another on an older image. A repair job may skip hosts that were offline, drained, or excluded by a maintenance tag. A green percentage can conceal the exact machines that missed the transition.

Containers do not carry their own kernels. A container image can be rebuilt with current user-space packages while every container on the node still shares the host kernel. Rebuilding the application image does not repair a host-kernel vulnerability. The relevant inventory unit is the node, virtual machine, or underlying managed service boundary.

Serverless and fully managed services require a different receipt. Customers may not see or control the kernel at all. In that case, collect the provider’s service notice, affected-service statement, or support confirmation. Do not run disruptive host-level instructions inside a service that does not expose a host. Responsibility changes, but the need for evidence remains.

Exploited does not mean remotely reachable from the internet

The Known Exploited Vulnerabilities label is meant to change priority. It should not erase prerequisites. A kernel flaw can be serious and actively exploited while still requiring local code execution, a particular namespace, a loaded subsystem, crafted traffic that reaches a narrow path, or another vulnerability earlier in the chain.

Public reporting on 21 September described possible consequences ranging from crashes and incorrect cryptographic processing to memory corruption and higher privilege. Those are useful starting points, not one universal attack story. The Hacker News distinguishes the AF_ALG race, the ebtables write, and the kTLS record-handling defect rather than presenting one common remote entry point. Its report also notes different severity assessments and affected kernel paths.

This distinction changes the first response. An internet-facing Linux host deserves prompt attention, but “internet-facing” alone does not prove that an unauthenticated request can call the vulnerable operation. A build worker that runs untrusted jobs may have a more plausible local route than a tightly configured web server, even when the web server has the public address. A container host that allows untrusted workloads may deserve priority because tenant code already reaches the shared kernel.

Prioritise by both evidence and reach. Put hosts first when they combine an affected running kernel with untrusted local code, multi-tenant workloads, exposed packet-processing roles, sensitive credentials, or a high-consequence control-plane function. Include developer workstations if they run untrusted builds, downloaded tools, or broad container workloads. Do not hide them behind the label “endpoint” when they hold production access.

Configuration can narrow risk, but it needs to be verified. A subsystem believed to be unused may be loaded on demand. A feature disabled in the base image may be enabled by one workload. A namespace policy may differ between two clusters that share the same template. Treat a mitigation as a temporary, tested control tied to the vendor’s advisory, not a guess based on a component name.

The opposite error is to wait for a perfect exploit narrative before patching. CISA has already supplied the important external signal: exploitation evidence exists. If your vendor says the running product is affected, install the repair on an accelerated schedule. Use prerequisite analysis to order work and guide triage, not to manufacture reasons for delay.

A calm position can hold both facts. These entries do not prove that every Linux server was remotely compromised. They do justify urgent, evidence-based patching of affected products and a review of systems where attackers or untrusted workloads may already have a route to the kernel.

Patching closes the next window, not the earlier one

Suppose a host ran an affected kernel from 1 August until its verified reboot on 22 September 2026. The reboot closes that exposure window going forward. It does not answer what happened during the previous seven weeks.

CISA explicitly marks forensic triage as required for the three catalogue entries. For a federal agency under the directive, that field carries formal obligations. For everyone else, it supplies a useful operational clue: the agency does not consider package installation alone a complete response.

Triage should match the system and the likely route. Preserve the host’s running-kernel version before reboot if your process allows it, along with package history, boot history, kernel and system logs, workload events, identity changes, and network records held outside the machine. If a kernel-level attacker succeeded, local records may be incomplete. Central logging, cloud control-plane events, identity-provider records, and network telemetry provide an independent view.

Do not turn the absence of one indicator into a clean bill of health. Public reporting does not provide a complete, universal indicator set for every exploitation path. A search for one process name or network address can find known activity, but a negative result proves only that the queried evidence did not contain that item.

Scope the effort according to exposure and consequence. A single-user development machine with no untrusted workloads and a short affected window does not demand the same response as a shared build host that handled code from outside contributors. A packet-processing gateway, Kubernetes worker, or privileged automation runner may justify deeper review because successful kernel exploitation could affect many workloads or valuable credentials.

The strongest triage question is concrete: what could an attacker have reached from this host during the affected interval? Record service identities, cloud instance roles, mounted secrets, signing keys, deployment credentials, control sockets, administrative sessions, and adjacent systems. If evidence suggests exploitation, that authority map tells responders what to rotate, rebuild, or investigate next.

A reboot also destroys some volatile evidence. That creates tension with the need to activate the repair quickly. Teams should decide the order before an incident, not improvise while a deadline passes. For high-consequence hosts, a practical sequence is to isolate or drain the workload, capture the approved volatile evidence, update or replace the host, verify the running repair, then investigate from preserved records. The exact collection belongs to an incident-response plan and trained staff.

Rebuilding can be safer than trying to certify an important host after credible kernel compromise. A kernel controls process visibility, memory, filesystems, and network operations. If evidence shows that an attacker obtained that level of authority, local cleanup cannot provide much assurance. Restore the service on a known-good image, rotate authority exposed to the old host, and retain the original system for investigation where policy permits.

Build a receipt that survives the maintenance window

A useful kernel-patch receipt fits on one page per fleet slice. It names the asset group, vendor advisory, affected package or image, expected repaired state, rollout time, restart method, running-state query, exceptions, and owner. Attach machine-readable results when the fleet is large, but keep the decision understandable to someone who did not run the update.

The sequence below is deliberately vendor-neutral. Replace each placeholder with the package, image, command, and support statement for the product you actually operate.

1. Identify the product, not merely the CVE. Record the distribution or appliance, release, architecture, kernel flavour, support state, and source of updates. For managed services, record the provider and service tier instead of inventing host access you do not have.

2. Resolve affected status through the vendor. Save the advisory or package-status page used for the decision. Note the exact repaired package build, image version, or provider statement. If the vendor still lists the product as under investigation on 22 September 2026, record that uncertainty and apply any published mitigation while following up.

3. Capture the pre-change running state. Save the host identity, boot time, running kernel release, installed kernel packages or image, relevant node-pool version, and live-patch state. This snapshot defines the earlier exposure window and prevents a later dashboard from rewriting history.

4. Install or roll out the repair. Use the vendor-supported package, image, live patch, or service update. Keep the package-manager or orchestration result, but label it accurately: deployment accepted, not repair proven.

5. Activate the repair. Reboot, replace, or drain and recreate the node when required. For a live patch, prove that the patch covering the named CVE is active. Keep service availability checks separate from security-state checks because an application can be healthy on an old kernel.

6. Query the running state after activation. Collect the running release from every host or a defined, complete inventory. Compare it with the vendor’s fixed state. Check that the host booted the intended image and that no old node returned to the pool.

7. Reconcile exceptions and the exposure window. List skipped, failed, offline, unsupported, or provider-managed systems. Give each one an owner and deadline. Decide whether the time before verified activation calls for triage, credential rotation, workload migration, or replacement.

The fifth and sixth steps are where many patch programmes become theatre. “Reboot requested” is an action. “Host build-17 booted the vendor-fixed kernel at 03:14 UTC and rejoined the pool after checks” is evidence.

The receipt should be cheap enough to repeat. A query that depends on one engineer opening dozens of terminals will not survive a large fleet or a weekend incident. Put running-kernel collection into fleet inventory, node admission, or compliance reporting. Alert on disagreement between installed and running state. Expire exceptions automatically instead of letting “temporary” become a kernel branch.

Test the restart path too. Kernel maintenance finds operational debt because a machine that has not rebooted for a year may depend on stale mounts, deleted configuration, manual firewall state, or a service that no longer starts cleanly. The problem is untested recovery, which the team should fix before the next urgent restart.

For critical services, rehearse replacement rather than preserving one immortal host. Immutable images, rolling node pools, and tested failover turn a kernel repair into a normal release. The security benefit comes with an availability benefit: the team knows it can replace the machine that holds the most authority.

The durable control is proof of active code

These three CISA entries will eventually leave the front page. The installed-versus-running gap will remain. It appears in kernels, hypervisors, firmware, browser relaunches, long-lived application processes, and containers built from a repaired base but never redeployed.

Patch management often measures distribution because distribution is easy to count. The repository offered an update. The package downloaded. The deployment job succeeded. Each event matters, yet none says what code is serving work now.

Move the control one step closer to reality. For every repair that requires activation, define the post-change query before rollout begins. Ask what the system will report when the fixed code is actually in authority. Save that answer against a complete asset list and keep the failures visible.

For the Linux flaws added on 18 September 2026, the immediate work is clear. Check vendor status for the exact product. Accelerate repairs where the running build is affected. Reboot or replace when required. Prove the active kernel afterward. Preserve and review the earlier exposure window in proportion to the host’s reach.

A green package dashboard is useful. A running-kernel receipt is what lets you close the incident.

If you want more calm, practical security explanations, the newsletter sends one email per month. The signup is on this site.

Sources

• CISA: Known Exploited Vulnerabilities catalogue, accessed 2026-09-22

• The Hacker News: CISA flags three Linux kernel vulnerabilities exploited in the wild, accessed 2026-09-22

• Debian Security Tracker: CVE-2025-39682, accessed 2026-09-22

• Debian Security Tracker: CVE-2026-53266, accessed 2026-09-22

• Debian Security Tracker: CVE-2025-39964, accessed 2026-09-22

• Ubuntu: CVE-2025-39682, accessed 2026-09-22

• Ubuntu: CVE-2026-53266, accessed 2026-09-22

• Ubuntu: CVE-2025-39964, accessed 2026-09-22