CVE-2026-98432 - Linux Kernel IPv4 TCP Use-After-Free Issue

What happened? — Facts from the sources

On 30 October 2026, Amazon Web Services published security bulletin 2026-160-AWS addressing CVE-2026-98432, a vulnerability in the Linux kernel's IPv4 TCP connection-handling code. According to AWS, the issue affects vulnerable kernel versions starting with the 4.4 series.

The vulnerability is classified as a use-after-free (UAF) flaw. This occurs when software accesses a memory object after that object has already been released. In an operating system kernel, such an error can cause a crash, memory corruption, disclosure of memory contents or, under certain conditions, remote code execution.

AWS explains that an attacker does not necessarily need an account on the target system. Exploitation may involve specially crafted IPv4 TCP traffic, particularly packets containing IP header options.

Vendor advisories also describe the possibility of remote code execution. AWS has reported a demonstration involving hosts with a Multipath TCP (MPTCP) listener. This does not mean that every Linux installation is equally exposed or that the same exploitation scenario applies to every TCP configuration.

For infrastructure teams and architects, the immediate questions are which systems run an affected kernel and whether their network exposure and configuration make exploitation possible.

What causes the vulnerability?

The underlying problem is a race condition during concurrent processing of TCP connection requests.

One execution path may be handling a retransmitted connection request while another releases a memory structure containing IPv4 options. A similar condition can occur during socket migration.

As a result, kernel code may continue reading from memory that has already been freed. This is a concurrency and object-lifetime management problem rather than a conventional application-level vulnerability.

Oracle's technical description explains that the fix uses the Read-Copy-Update (RCU) mechanism. RCU allows memory reclamation to be deferred until readers that may still reference the object have completed their work.

From an architectural perspective, the issue illustrates a fundamental point: even well-designed and carefully secured applications depend on lower-level components whose vulnerabilities can affect the entire service.

How serious is the threat?

Vendor severity assessments differ.

Amazon Linux assigns CVE-2026-98432 a CVSS 3.1 score of 8.1 and classifies it as Important. Updated Red Hat information classifies the vulnerability as Critical, with a reported score of 9.8.

These differences do not necessarily indicate conflicting technical findings. Vendors assess vulnerabilities in the context of their own products, deployment assumptions, configurations and potential exploitation paths. Severity ratings may also change as investigations progress.

A single CVSS score should therefore not be treated as a complete patch-prioritisation decision.

The practical risk depends on the kernel version and configuration, the exposure of TCP services, existing security controls and the business criticality of the affected system.

A vulnerability that may allow a remote attacker to compromise kernel memory clearly warrants urgent investigation. However, the existence of such a flaw does not establish that every Linux server can be compromised in the same way.

What does this mean for systems architecture?

Architectural commentary — author's assessment

The central challenge is not simply installing a kernel update. It is knowing who owns the relevant infrastructure components and who is responsible for maintaining their security.

In traditional environments, the server owner or infrastructure team is usually responsible for operating system updates. In cloud and container environments, the responsibility model is often more complex.

Virtual machines and IaaS. For self-managed instances such as Amazon EC2, the customer is responsible for updating the kernel. A patch being available from the cloud provider does not mean that it has been installed across the customer's servers.

Kubernetes. Containers share the operating system kernel of their host node. Updating an application container image does not patch a vulnerable host kernel. Remediation may require updated node images, node replacement or restarts, with appropriate measures to maintain service availability.

Managed services. Responsibilities depend on the service model. Some infrastructure is patched directly by the provider. In other cases, customers must upgrade their platform version, replace nodes or carry out additional actions.

Network infrastructure. A load balancer does not automatically protect a backend host from kernel-level vulnerabilities. AWS specifically highlights Network Load Balancer configurations using TCP listeners, which may forward packets containing IPv4 options to backend targets.

For enterprise architects, this reinforces the importance of maintaining a dependency model that extends beyond applications and APIs. Operating systems, base images, container platforms and patch ownership should also be visible.

Without this information, even a formally established vulnerability management process can overlook affected components.

How can the risk be mitigated?

Vendor information and guidance

AWS has released updated kernel packages for Amazon Linux 2 and Amazon Linux 2023. For self-managed instances, the recommended remediation is to install the relevant updates and reboot the system so that the patched kernel is actually running.

Updated node images have also been made available for Amazon EKS. The required action depends on whether an organisation uses self-managed nodes, managed node groups, Karpenter or EKS Auto Mode.

For Amazon ECS, AWS Fargate, Lambda and other managed services, customers should follow the guidance specific to each service. The division of patching responsibilities is not identical across these offerings.

AWS also describes interim mitigation measures, including disabling MPTCP and filtering IPv4 packets containing IP header options. These measures may reduce exposure, but they are not a substitute for permanently remediating the affected kernel.

Changes to network filtering must also be assessed for their potential impact on legitimate traffic and service availability.

Architectural recommendation — author's assessment

An organisation should assess the impact of CVE-2026-98432 by identifying potentially vulnerable systems, evaluating their network exposure and assigning clear ownership for remediation.

Priority should be given to systems running affected kernels that expose reachable TCP services, particularly where those systems support business-critical processes.

After patching, verification should go beyond confirming that the update package was installed. Teams should establish that the system is actually running a corrected kernel version.

Systems that cannot be updated immediately should be documented, along with their temporary mitigations, responsible owners and planned remediation dates.

Key takeaway for architects

CVE-2026-98432 is a reminder that system security does not end at application code, an API Gateway or a load balancer.

A kernel vulnerability can affect multiple applications and services simultaneously, even when none of those applications contains the flaw itself.

From an enterprise architecture perspective, the essential capability is maintaining an accurate understanding of dependencies between applications, runtime platforms and infrastructure.

The key question is: can the organisation identify every system that depends on a vulnerable component, determine who is responsible for patching it and verify that the remediation is effective?

The ability to answer that question matters more than simply having a patch management procedure on paper.