What the advisory describes, function by function
The Ubuntu page describes a memory-handling flaw in how IPv4 TCP connections are established. When a client sends a SYN, the kernel creates a connection request; at the end of the handshake, tcp_v4_syn_recv_sock() creates the child socket. According to the page, this function hands the request's IP options to the child socket without copying them. If a retransmitted SYN is processed at the same moment on another CPU, the kernel can read those already-freed options while building the SYNACK: that is the use-after-free, in ip_options_build().
The page reports a similar race during request migration between sockets, when net.ipv4.tcp_migrate_req=1 or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program is in place. The fix it describes delays freeing the memory until an RCU grace period has ended, using kfree_rcu(), in inet_sock_destruct() and tcp_v4_reqsk_destructor(). IPv6 is not affected by the first flaw; the page says a similar migration issue exists there and will be handled separately. Keep in mind what it does not say either: remote exploitability is not publicly demonstrated in the pages we read.
Two scores, two issuers: 9.8 and 8.1
The two numbers do not contradict each other; they describe different things. Ubuntu shows a High priority and a CVSS 3 score of 9.8, rated Critical. Red Hat publishes a CVSS v3.1 score of 8.1, with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. The Red Hat page also lists the cve.org value for comparison: 9.8 with AC:L. Only the attack complexity changes: low (AC:L) on one side, high (AC:H) on the other.
Red Hat's 8.1 reflects a tight-timing race, where the attacker has to make two code paths coincide on two CPUs; its description speaks first of a crash, with possible memory corruption. The page states that these scores are preliminary and subject to review. So do not keep a single figure: 9.8 according to Ubuntu, 8.1 according to Red Hat. In the vectors published by Red Hat and cve.org, the flaw is reachable over the network without authentication (AV:N, PR:N), which is enough to take it seriously without presenting it as an attack under way: neither page we read reports one.
The published status on 30 October 2026
Scroll the table
| Source or version | Status read on the page | What it means for you |
|---|---|---|
| Ubuntu 24.04 LTS (noble) | Vulnerable, fix in progress; listed version 6.8.0-149.149 | No fixed kernel to install yet |
| Ubuntu 22.04 LTS (jammy) | Vulnerable, fix in progress; listed version 5.15.0-203.213 | No fixed kernel to install yet |
| Ubuntu 26.04 LTS | Vulnerable, fix in progress; listed version 7.0.0-43.43 | No fixed kernel to install yet |
| Ubuntu 20.04 LTS (focal) | No version listed; check the status on the page | Reopen the page before drawing any conclusion |
| Red Hat | CVSS v3.1 8.1, no mitigation offered, no fixed package listed, Bugzilla 2553390 | No official workaround; follow the ticket |
| Debian, AlmaLinux, Rocky and others | Not read for this article | Read your vendor's advisory; do not infer from Ubuntu |
| A version number on an advisory | It is not a fixed version until the status has changed to fixed | Compare `uname -r` with that number only after the status change |
An installed kernel is not a running kernel
An apt upgrade or a dnf update drops a new kernel into /boot, but the system keeps running the one loaded at the last boot until it restarts. uname -r answers the only question that matters here: which kernel is running right now. The package list answers a different one: which kernels are sitting on disk. When the fix ships, a VPS can therefore show "up to date" in its package manager and stay vulnerable for weeks.
The reverse is true today: installing today's updates does not fix this CVE, because the pages list no fixed kernel. Docker containers change nothing, they share the machine's kernel. On a full virtual machine that kernel is yours; on a container-type VPS it is the host's, and you have to ask the provider. The restart procedure itself is detailed in the PwnEscape and Vghost guide linked under this article, so there is no need to repeat it here.
Check your VPS in ten minutes
Read the running kernel
uname -rcat /proc/version
Note the full string, suffix included (-generic,-aws,-kvm,el9…). That is what you will compare with your distribution's page, and the suffix tells you which kernel variant to look for.List installed kernels and any pending restart
Debian, Ubuntu:
dpkg -l 'linux-image*' | grep '^ii'thenls /var/run/reboot-required
RHEL, AlmaLinux, Rocky:rpm -q kernelthensudo needs-restarting -r
If the newest installed kernel differs from the oneuname -rreports, a restart is pending.Look for a published fix
Debian, Ubuntu:
sudo apt updatethenapt list --upgradable 'linux-image*'
RHEL, AlmaLinux, Rocky:sudo dnf updateinfo list --cve CVE-2026-98432thensudo dnf check-update kernel
An empty list does not prove you are protected: it only says your repository offers nothing yet.Read what the candidate package announces
Debian, Ubuntu:
apt changelog <package-listed-in-the-previous-step> | grep -n 'CVE-2026-98432'
RHEL, AlmaLinux, Rocky:sudo dnf updateinfo info --cve CVE-2026-98432
If the identifier appears, the package announces the fix; note its version number and confirm it on your distribution's page before concluding.Read the network exposure
sudo ss -4tlnpsysctl net.ipv4.tcp_migrate_req
The first command lists the IPv4 TCP ports in listening state, so the only places a TCP handshake arrives; that is our reading of the advisory, not a statement from it. The second shows the migration setting (0or1). That setting does not close the flaw: the first flaw described exists without it.Reopen the page on the day you decide
Open your distribution's page, note the status of your kernel variant and the last-updated date it shows. Record them with the date you read them: these pages move, and a status read three days ago is not today's status.
Acting without a confirmed fix
- Close what does not need to be reachable — every IPv4 TCP port open to the whole Internet is a possible entry. Restrict SSH, databases and administration to the addresses that need them with
ufworfirewalld. That reduces the surface without fixing a public port such as 443. - Do not count on a workaround — Red Hat offers none, and the part of the Ubuntu page we read lists none. Setting
net.ipv4.tcp_migrate_reqto0does not cover the first flaw described. - Prepare the restart window — pick the slot, warn your users, check that your services restart on their own (
systemctl is-enabled <service>) and take a backup or snapshot first. - Detect the fix as soon as it ships — run
apt list --upgradable 'linux-image*'ordnf check-update kernelevery day, or reread the page. Depending on its configuration, automatic updating installs the kernel without restarting. - Keep a fallback way in — locate your provider's emergency console before the restart, not during it: a kernel that fails to come back is handled from there.
- Watch for crashes — Red Hat describes mainly a crash.
journalctl -k -p err --since '7 days ago'andlast -x rebootshow an unexpected restart or an unusual kernel message to compare with the publication date.
Livepatch: an option, with one condition
A live patch applies a fix to the running kernel without a restart. It exists only once the vendor or the service provider has produced it, and it covers only the CVEs that provider has handled. With Canonical's Livepatch service, canonical-livepatch status --verbose lists the applied fixes; on other distributions, third-party services such as KernelCare play that role. The rule is the same everywhere: as long as the identifier CVE-2026-98432 is not in the list of applied fixes, you are not covered, even if the service shows as active.
None of the pages we read mentions a livepatch for this CVE on the reading date. And a livepatch does not excuse you from the next kernel: still plan the restart to the fixed version, at the slot you will have chosen.
Write down the date, not only the status
In your operations notebook, record for each server the running kernel, the status read on the page and the date you read it. In this guide, the status described is that of 30 October 2026; it may have changed by the time you read it. This guide is provided as is: administering your server remains your responsibility, with no support from us.
The day a fixed kernel appears
Read the page first: the status of your variant must have changed to fixed and show a version number. The Ubuntu page does not list a single package but several (linux, linux-aws, linux-azure, linux-gcp…): follow the line that matches the suffix shown by uname -r, not the line of the default linux package.
Then install with sudo apt upgrade (Debian, Ubuntu) or sudo dnf upgrade kernel (RHEL, AlmaLinux, Rocky), restart with sudo reboot, and check with uname -r that the running string matches the announced fixed kernel. If it still matches the old one, the restart did not switch to the new kernel: look at the default boot entry before declaring the server fixed. Finally, record the installed number in your notebook.
The official documentation
Ubuntu page for CVE-2026-98432 (published 15 October 2026, updated 29 October 2026): https://ubuntu.com/security/CVE-2026-98432
Red Hat page for CVE-2026-98432 (CVSS 8.1, Bugzilla 2553390): https://access.redhat.com/security/cve/CVE-2026-98432
Both pages were read on 30 October 2026; they may have changed since.
