CVE-2026-98432: How to Find and Patch Vulnerable Linux Hosts

A server can have every application package updated and still be running the old kernel. That gap matters when the vulnerability is in the kernel's network path, and it is why “the package manager says everything is current” is not a complete incident response.

CVE-2026-98432 is a use-after-free flaw in Linux's IPv4 networking code. Red Hat describes a race during TCP connection-request processing that can free socket options while another operation is still using them. Its current bulletin rates the issue Critical and says a remote, unauthenticated attacker may cause a crash or potentially execute code. AWS describes the affected path more narrowly as IPv4 TCP handshakes involving crafted packets with IP options, and says researchers demonstrated remote code execution against hosts with an MPTCP listener. AWS also says it is not aware of exploitation in the wild. These descriptions are not identical, so follow the advisory for your exact distribution and product rather than treating one vendor's summary as a universal exploit guarantee. Red Hat's advisory and AWS's bulletin were checked on November 2, 2026.

This is a hands-on response guide, not an exploit walkthrough. It shows how to build an inventory, check vendor status, update the host kernel, verify the kernel that is actually running, and avoid the common mistake of patching an image while leaving existing nodes untouched. The steps are drawn from vendor advisories and standard Linux administration commands.

First, understand what “patched” means

A vulnerability record is not a universal list of safe kernel version numbers. Linux distributions routinely backport security fixes into a vendor kernel while keeping the version string's upstream-looking base unchanged. A kernel numbered 5.15.x can contain a security fix that is absent from another 5.15.x build. Compare your installed package against the vendor's fixed package or advisory status, not against an upstream version guessed from a headline.

There is a second distinction: the kernel package installed on disk is not necessarily the kernel executing now. Linux loads the kernel during boot. Updating it generally requires a reboot or a controlled replacement of the node before the fix is active. AWS explicitly calls for updating and rebooting self-managed EC2 hosts, and Red Hat says a kernel update is the complete remediation; its filtering rule is only a mitigation. AWS's bulletin and Red Hat's mitigation section explain those steps.

Keep three states separate in your records:

• Package available: the vendor has published a fixed kernel package or image.
• Package installed: the host has downloaded and installed that package.
• Fixed kernel running: the host has booted the fixed kernel, or has been replaced by a node that did.

Only the last state confirms that the host is actively using the kernel fix.

Step 1: Find the machines you actually own

Start with your asset inventory, not a single SSH session. Include virtual machines, physical servers, Kubernetes workers, container hosts, appliances you manage, and old instances that are stopped but may return. A container image scan alone will not tell you which kernel the container host is running. Containers share the host kernel, so assess and patch the nodes beneath them.

For each host, record its cloud or data-center location, distribution and release, kernel package, current running kernel, workload role, and whether untrusted IPv4 TCP traffic can reach it. Do not infer reachability from an application's intended design. Check security groups, load balancers, firewall rules, and listening sockets.

On a Linux host, collect a starting snapshot:

printf 'hostname: '; hostname -f 2>/dev/null || hostname
printf 'os: '; . /etc/os-release && printf '%s %s\n' "$ID" "$VERSION_ID"
printf 'running kernel: '; uname -r
printf 'architecture: '; uname -m

If you administer a group of machines, gather the same fields through your existing configuration-management or cloud-inventory system. Avoid building a one-off scanner that silently misses nodes. A report should identify unreachable hosts and failed commands as unknown, not as patched.

Step 2: Check the right vendor advisory

Search for CVE-2026-98432 in the security tracker for the operating system and kernel flavor actually installed. That includes specialized cloud kernels, real-time kernels, HWE kernels, immutable images, and vendor-managed container nodes. Read both the affected-status and fixed-package fields. “Under investigation” is not the same as “not affected,” and a fix for one release does not establish the fix status for another.

The vendor pages can change while fixes roll out. As of November 2, 2026, AWS says fixed Amazon Linux 2 and Amazon Linux 2023 kernel packages are available and instructs customers to update and reboot. AWS also lists updated EKS-optimized Amazon Linux 2023 AMIs, while its page describes the Auto Mode rollout as still progressing. On the same date, Red Hat's bulletin says it is expediting fixes, and notes that traffic filtering can reduce exposure but cannot fully prevent the issue. Those are examples of why a single “Linux is patched” status is misleading: the answer depends on distribution, product, node type, and the exact time the advisory was checked. AWS security bulletin; Red Hat security bulletin.

Capture the advisory URL and the time you checked it in the change record. Recheck it before deployment if the remediation spans several days. Do not copy a fixed package version from another distribution or cloud image and assume it applies to your fleet.

Step 3: Update the host, not just the workload

For Amazon Linux 2, AWS currently documents:

sudo yum update kernel
sudo reboot

For Amazon Linux 2023, the bulletin documents:

sudo dnf update kernel --releasever=latest
sudo reboot

AWS notes that instances pinned to a particular Amazon Linux 2023 release need a release containing the fixed kernel. Follow the live bulletin and the relevant release advisory, especially if you pin repository versions. AWS security bulletin.

For other distributions, use their supported package manager and upgrade path. For example, a Debian-family system commonly uses apt, while a Red Hat-family system uses dnf or yum, but the command syntax is not the key decision. The decisive check is whether the distribution tracker says the installed kernel package for that release contains the fix. If no fixed package is available yet, do not substitute an unrelated kernel build on a production host without a supported migration plan.

Before rebooting, confirm that you have a recovery path: console access, a tested maintenance window, a healthy replacement node, or a rollback plan. Kernel changes affect the whole machine. For a cluster, drain and replace nodes in controlled batches, preserve capacity, and confirm that the new node image includes the fixed kernel before sending workloads to it.

Step 4: Verify what is running after remediation

After reboot or node replacement, check the live kernel:

uname -r

Then verify the installed kernel package using the distribution's package tools and compare it to the vendor's fixed package information. Keep both results. uname -r answers “what is running now?” Package queries answer “what is installed?” Neither alone answers whether the vendor considers that exact build fixed.

For a systemd-based host, verify uptime or boot time if the change record needs evidence that a reboot occurred:

uptime -s

For a fleet, collect the result from every in-scope node and reconcile it against your inventory. A successful update command on one representative machine is not fleet-wide proof. Include nodes that failed to reboot, were cordoned, or were replaced from an older image. If an automated scanner reports a vulnerable package after the reboot, investigate whether it is detecting the on-disk package, a stale image, or a separate kernel flavor rather than suppressing the finding without evidence.

Step 5: Treat cloud and Kubernetes layers separately

A cloud provider may patch its own managed control plane or service infrastructure while leaving customer-managed virtual machines for the customer to update. The provider's bulletin spells out that boundary. AWS, for example, says self-managed EC2 Linux instances remain the customer's responsibility and distinguishes them from services where AWS is applying infrastructure updates. It also has separate steps for EKS node AMIs, ECS on EC2, Fargate, and Bottlerocket. Read the section for the exact service you use. AWS security bulletin.

For Kubernetes, the pod's image is not the kernel boundary. Check the node operating system, node image release, and the mechanism that replaces nodes. Updating a launch template or node group does not necessarily replace already-running workers immediately. Confirm rollout status, drain or recycle old nodes, and verify the running kernel on each new node. If your cluster uses a managed automatic-update mode, confirm the provider's rollout status and your disruption-budget behavior instead of assuming that “managed” means “already complete.”

Also include edge cases in your inventory: autoscaling groups that can recreate an old image, warm pools, disaster-recovery regions, build agents, and long-lived development machines. A newly created node can reintroduce the old kernel if its image source was not refreshed.

What about the temporary firewall mitigation?

Red Hat describes an nftables rule that drops incoming IPv4 TCP packets containing IPv4 options. The vendor explicitly warns that the filter reduces exposure but cannot fully prevent the vulnerability, and that it may affect workloads. It should be treated as a temporary risk-reduction measure, reviewed and tested against your network, not as proof that the host is safe. Remove the rule after the fixed kernel is active, following the vendor's procedure. Red Hat's advisory includes the rule, validation, and removal commands.

Avoid applying network filters blindly across a fleet. First establish whether your traffic uses IPv4 options, whether the rule is compatible with your existing firewall framework, and how you will persist, monitor, and later remove it. Test in a representative non-production environment. If the vendor's exact mitigation is not relevant to your distribution or firewall manager, ask that vendor for its supported guidance rather than translating a rule from memory.

A compact response checklist

• [ ] Inventory hosts, cloud nodes, container hosts, and rebuildable images.
• [ ] Identify distribution release and kernel flavor per host.
• [ ] Check the distribution or cloud vendor's current CVE-2026-98432 status.
• [ ] Separate package availability, package installation, and the running kernel.
• [ ] Prioritize hosts reachable by untrusted IPv4 TCP traffic.
• [ ] Apply the vendor-supported fixed kernel or image.
• [ ] Reboot or replace nodes using a controlled rollout.
• [ ] Verify uname -r and the vendor package status on every in-scope host.
• [ ] Refresh autoscaling, Kubernetes, and disaster-recovery images.
• [ ] Track any temporary mitigation and remove it after patch verification.

The useful operational lesson is not “every Linux version is vulnerable” or “one firewall rule fixes it.” It is that a kernel security response has to trace the fix all the way from the vendor advisory to the kernel executing on each machine. The package manager is one checkpoint in that chain, not the finish line.

I write practical guides on software engineering, infrastructure, and AI. Subscribe if you want more walkthroughs like this.

How do you verify that a kernel fix reached every node in your fleet: package inventory, image rollout checks, or both?

Sources

• Red Hat: RHSB-2026-016, Use-after-free in kernel IPv4
• AWS: CVE-2026-98432 Linux kernel IPv4 TCP use-after-free bulletin
• Red Hat CVE record: CVE-2026-98432