CVE-2026-98432: Patch Linux TCP Listeners Across AWS

CVE-2026-98432 is a Linux kernel use-after-free in IPv4 TCP connection handling. The important operational detail is not simply that a fixed package exists: the corrected kernel must be running, which normally means scheduling a reboot or replacing the affected node. AWS updated its service-specific guidance on November 2, 2026, giving teams a clearer map for EC2, EKS, ECS, Lightsail, load-balanced targets and other Linux workloads.

This guide explains the vulnerable path, shows how to prioritize reachable listeners, and provides a safe inventory lab that does not transmit exploit traffic. It also separates temporary traffic filtering from complete remediation so teams do not mistake a compensating control for a fix.

What changed in the latest guidance

The Linux kernel CVE team disclosed the issue on October 15. Its advisory says the bug was introduced in Linux 4.4 and has been fixed across supported stable branches. The team assigns a CVSS 3.1 score of 9.8 and recommends updating to the latest stable kernel rather than cherry-picking a single commit. AWS published service guidance and updated it on November 2. Red Hat also updated its critical-impact bulletin that day, while Canonical reported that fixes for several supported Ubuntu releases were still in the -proposed pocket at the time of writing.

Response principle: inventory the running kernel and the reachable IPv4 TCP surface together. A package database that lists a fixed kernel does not prove the host booted into it.

How CVE-2026-98432 works

The vulnerable code handles incoming IPv4 TCP connections that carry IP options. During connection setup, tcp_v4_syn_recv_sock() transfers an options object from a request socket to a child socket. A concurrent path can still read the same object while another path frees it. That race creates a use-after-free in kernel memory.

The upstream description identifies two related paths: concurrent processing of a retransmitted SYN while a SYN-ACK is built, and request-socket migration when net.ipv4.tcp_migrate_req=1 or a relevant BPF reuseport program is involved. The fix defers freeing the object until after an RCU grace period by using kfree_rcu().

• Primary exposure: Linux hosts accepting untrusted IPv4 TCP connections.
• Trigger characteristic: connection requests carrying IPv4 options. These are distinct from ordinary TCP options in the TCP header.
• Potential impact: kernel crash, memory corruption, information exposure or code execution, depending on the environment and exploitability.
• IPv6 nuance: the upstream advisory says IPv6 is not affected by the first issue because that path duplicates the options. Do not use that fact to defer IPv4 remediation on dual-stack systems.

AWS reported no evidence of active exploitation in its bulletin. That is useful context, but not a reason to postpone patching. Network reachability, kernel privilege and the breadth of TCP-facing Linux services make exposure reduction and controlled rebooting time-sensitive.

Prioritize by reachability, not by hostname

A flat list of Linux instances is not enough. Start with systems where untrusted clients can reach a listening IPv4 TCP port and where packets are delivered to the target without an intermediary terminating the connection. Then add the running kernel, distribution advisory status and replacement strategy.

For a broader baseline around public exposure, security groups and workload ownership, compare this response with the AWS Cloud Security Checklist. Teams running Kubernetes should also align node replacement with the checks in our Kubernetes node migration audit.

Patch and reboot correctly

1. Capture the running state

Record both the running kernel and installed kernel packages before changing anything. This creates evidence for the change ticket and exposes hosts where a fixed package is installed but not active.

cat /etc/os-release
uname -r

# Debian and Ubuntu
dpkg -l 'linux-image*' | awk '$1 == "ii" {print $2, $3}'

# RPM-based distributions
rpm -q kernel kernel-core 2>/dev/null

2. Use the distribution package, not a guessed version

Kernel package versions differ by distribution because vendors backport fixes. Do not compare only the upstream version string or assume every kernel below a single number is vulnerable. Check the operating system vendor advisory for the exact fixed package and support channel.

For Amazon Linux, AWS lists the following update commands and says Amazon Linux 2023 systems pinned to a release must use release 2023.12.20261102 or later. These commands intentionally include the required reboot.

# Amazon Linux 2
sudo yum update kernel && sudo reboot

# Amazon Linux 2023, kernel 6.1
sudo dnf update kernel --releasever=latest && sudo reboot

# Amazon Linux 2023, kernel 6.12
sudo dnf update kernel6.12 --releasever=latest && sudo reboot

Canonical’s November 2 notice said fixes for Ubuntu 22.04 LTS, 24.04 LTS and 26.04 were available in -proposed, with standard archive publication to follow after testing. Production teams should follow the current Ubuntu CVE page and their normal kernel acceptance policy rather than enabling a proposed repository fleet-wide without validation.

3. Reboot or replace, then prove the change

After the maintenance action, compare the running kernel with the vendor’s fixed package. For immutable nodes, confirm the new AMI or image ID as well as uname -r. For clusters, drain and replace a small canary set first, verify application health, and continue within disruption budgets.

uname -r
uptime -s
who -b
systemctl --failed --no-pager
journalctl -k -b --priority=err..alert --no-pager

Temporary filtering is not complete remediation

Red Hat and AWS describe an interim nftables control that drops incoming IPv4 TCP packets whose IPv4 header contains options. Standard TCP options remain in the TCP header, so the match is narrower than blocking all TCP options. Still, any firewall change can disrupt legitimate routing, diagnostic or specialized traffic. Test it in a representative non-production environment, preserve console access, and monitor the counter before wider use.

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

Validate the ruleset before loading it. Keep the removal command in the same change ticket. After the fixed kernel is active, remove the temporary table unless policy deliberately retains it.

sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

# Remove after confirmed kernel remediation
sudo nft delete table inet cve_2026_98432

Safe lab: rank a synthetic Linux fleet

This lab models an exposure queue without scanning hosts or sending crafted packets. Run it on an isolated workstation with Bash 4 or later. The patched column must come from your vendor-specific validation process; the script does not infer patch status from a generic version comparison.

Prerequisites and sample inventory

mkdir -p cve-2026-98432-lab && cd cve-2026-98432-lab
cat > nodes.csv <<'CSV'
host,service,public_ipv4_tcp,mptcp,patched
edge-01,EC2,yes,no,no
api-eks-01,EKS-node,yes,yes,no
batch-01,ECS-Fargate,no,no,yes
admin-01,EC2,no,no,no
CSV

Create and run the triage script

cat > rank.sh <<'BASH'
#!/usr/bin/env bash
set -euo pipefail

printf '%-14s %-14s %-10s %s\n' HOST SERVICE STATUS ACTION
tail -n +2 "${1:-nodes.csv}" | while IFS=, read -r host service public mptcp patched; do
  if [[ "$patched" == "yes" ]]; then
    status="VERIFIED"
    action="Record evidence"
  elif [[ "$public" == "yes" && "$mptcp" == "yes" ]]; then
    status="URGENT"
    action="Patch/reboot or replace now"
  elif [[ "$public" == "yes" ]]; then
    status="HIGH"
    action="Patch/reboot in priority window"
  else
    status="REVIEW"
    action="Patch; confirm no indirect reachability"
  fi
  printf '%-14s %-14s %-10s %s\n' "$host" "$service" "$status" "$action"
done
BASH
chmod 700 rank.sh
./rank.sh

Expected output:

HOST           SERVICE        STATUS     ACTION
edge-01        EC2            HIGH       Patch/reboot in priority window
api-eks-01     EKS-node       URGENT     Patch/reboot or replace now
batch-01       ECS-Fargate    VERIFIED   Record evidence
admin-01       EC2            REVIEW     Patch; confirm no indirect reachability

Troubleshooting and cleanup

• If columns shift, make sure values contain no commas and the file uses Unix line endings.
• If tail or Bash behaves differently on macOS, run the lab in a disposable Linux container or VM.
• If patch state is unknown, enter no and keep the system in the queue until vendor evidence is available.

cd ..
rm -r cve-2026-98432-lab

Detection and validation ideas

Detection should support remediation, not replace it. Review kernel logs and crash telemetry for unusual faults around IPv4/TCP processing, correlate bursts of SYN retransmissions with IPv4 options, and alert on unexpected exposure changes to Linux TCP listeners. If you deploy the temporary nftables rule, collect its counter so the SOC can distinguish normal zero activity from packets actually being dropped.

• Search journalctl -k, kdump and cloud instance health events for kernel oops, panic or unexplained restarts.
• Inventory MPTCP listeners and systems with net.ipv4.tcp_migrate_req=1; these details affect prioritization but do not define the entire vulnerable population.
• Compare security-group, NLB, Global Accelerator, PrivateLink and VPC Lattice paths with the actual target operating system.
• Record the post-reboot kernel, boot time, image ID, node replacement event and application health check in the ticket.

A clean log does not prove a host is safe. The decisive evidence is a vendor-confirmed fixed kernel running on the system, or removal of the reachable vulnerable workload.

Conclusion

CVE-2026-98432 deserves a reachability-led response. Start with public or untrusted IPv4 TCP listeners, especially direct pass-through paths such as NLB TCP targets and self-managed cloud instances. Apply the operating system vendor’s fixed kernel, reboot or replace the node, and verify what is actually running. Use packet filtering only as a tested bridge to that outcome.

The cloud service matrix will continue to change as managed images roll out. Recheck the live AWS bulletin and the relevant distribution advisory immediately before each maintenance window.

Primary references

• Linux kernel CVE announcement for CVE-2026-98432
• AWS Security Bulletin 2026-160-AWS
• Red Hat Security Bulletin RHSB-2026-016
• Canonical update on Ubuntu fixes
• Debian Security Tracker entry