CVE-2026-98432: Ubuntu Kernel Status and Host Triage
Check the live Ubuntu package status, separate upstream kernel fixes from distribution updates, and build the evidence needed to close a host patch ticket safely.
In This Lesson
Move from a time-stamped vendor status check to a host-specific package decision, then collect post-update proof without confusing an upstream branch fix, a CVSS score, or social attention with Ubuntu remediation evidence.
- Read the dated vulnerability snapshot
- Match Ubuntu release and kernel package
- Separate upstream and distribution fixes
- Understand the TCP race defensively
- Interpret severity and exploitation signals
- Build a defensible host record
- Run safe Ubuntu inventory and update commands
- Review sources and defensive-use scope
Workflow: Identify → Verify
Use three decisions to prevent a generic scanner finding from becoming an unsupported patch-closure claim.
Identify
Record the Ubuntu release, running kernel, installed package name, and kernel flavor on the actual host.
Match
Find that exact package and release in the live Ubuntu tracker; treat work-in-progress labels as unresolved.
Verify
Apply approved vendor updates, reboot or activate as required, and prove which kernel is now running.
CVE-2026-98432 Defensive Overview
This vulnerability is a remotely reachable Linux kernel use-after-free involving TCP and IPv4 options. The operational task is not merely to recognize the score; it is to map a real Ubuntu host to a vendor package row and verify the running result.
Dated Vulnerability Status Snapshot
Ubuntu priority
High. Canonical's CVE page listed that vendor priority when reviewed on October 30, 2026.
Severity systems
CVSS 3.1: 9.8 Critical. CVSS 4.0: 8.3 High. These are separate scoring systems.
Ubuntu package state
Fixes in progress for several generic linux rows. A work target is not a released fix.
The Linux CNA record was published on October 15, 2026, and Ubuntu's page showed a last-updated date of October 28 when this article was technically reviewed. This article is a dated package-status and triage guide, not a claim that the vulnerability was first disclosed on the publication date.
Ubuntu Package Rows Must Be Read by Release and Flavor
At the October 30 review, the live Ubuntu tracker showed the following generic source-package rows. The versions beside vulnerable rows are work-in-progress targets, not proof that a corrected package is available on a host.
| Ubuntu release | Source package | Vendor status | Work-in-progress target |
|---|---|---|---|
| 26.10 | linux | Vulnerable | 7.3.0-10.10 |
| 26.04 LTS | linux | Vulnerable | 7.0.0-43.43 |
| 24.04 LTS | linux | Vulnerable | 6.8.0-149.149 |
| 22.04 LTS | linux | Vulnerable | 5.15.0-203.213 |
| 20.04 LTS | linux | Vulnerable | Not shown |
| 18.04 LTS | linux | Vulnerable | Not shown |
| 16.04 LTS | linux | Vulnerable | Not shown |
Ubuntu tracks many kernel flavors separately, including cloud, hardware-enablement, OEM, Raspberry Pi, real-time, vendor, and appliance-oriented packages. A result for the generic linux row does not certify a host running linux-azure, linux-aws, linux-gcp, linux-hwe-*, linux-oem-*, or another flavor.
Upstream Linux Fixes Do Not Identify an Ubuntu Package
The Linux record lists fixed versions for several upstream branches, including 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, and 7.3. These are branch-specific upstream versions, not one universal minimum for every Ubuntu kernel.
Upstream Linux
Shows where fixes landed in kernel branches. This helps scanners and maintainers understand source history.
Distribution package
May backport the fix while retaining an older-looking kernel version. Package revision and vendor status carry the decision.
Host evidence
Must show the installed package and the kernel actually running after the approved update and activation step.
The Debian security tracker illustrates the distribution distinction: it lists linux 6.1.190-1 as fixed for Bookworm security and linux 6.12.113-1 as fixed for Trixie security. Those Debian results do not establish the status of an Ubuntu package with a different name and revision.
How the TCP Race Works
- A network peer sends a SYN with IPv4 optionsThe relevant path involves TCP connection setup and options such as Record Route or Timestamp.
- The kernel retains request optionsThe options are associated with a connection request while the kernel prepares the child socket and SYNACK.
- Concurrent processing creates a raceA retransmitted SYN can cause one CPU to read the options while another path frees related memory.
- A remaining reader can access freed memoryThe Linux CNA description identifies potential memory disclosure, memory corruption, or a kernel crash.
- The upstream change defers freeingThe fix uses RCU-aware freeing so existing readers can finish before the memory is released.
A related request-socket migration case can occur when net.ipv4.tcp_migrate_req=1 or an applicable BPF reuse-port migration program is used. That setting is not required for the first IPv4 path, so disabling migration is not a complete mitigation.
The CNA description also distinguishes IPv6: the first path duplicates IPv6 options, while a related CALIPSO migration issue is handled separately. That limited distinction must not be converted into a blanket claim that every IPv6 configuration is safe.
Keep Severity, Vendor Priority, and Exploitation Evidence Separate
| Signal | Dated result | What it means |
|---|---|---|
| CVSS 3.1 | 9.8 Critical | Network vector, low complexity, no privileges, no user interaction, and high confidentiality, integrity, and availability impact. |
| CVSS 4.0 | 8.3 High | A different scoring model with attack requirements present and lower confidentiality/integrity impacts. |
| Ubuntu priority | High | Canonical's vendor prioritization, not a claim of observed exploitation. |
| CISA KEV | Not found in the catalog during the October 30 check | Absence from KEV is not proof that exploitation cannot or has not occurred. |
The supplied report also records 22 mentions in a seven-day social-media view. That is an attention signal only. Mention counts, reposts, and discussion volume must not be relabeled as attacks or compromise evidence.
The public primary sources cited here document the flaw, severity, and package status. They did not establish an in-the-wild exploitation incident for this review. Prioritize remediation using package state, network reachability, workload criticality, compensating controls, and outage risk.
Build a Host Record Before Closing the Patch Ticket
- Identify the host: record hostname or asset ID, Ubuntu release, support entitlement, environment, owner, and business criticality.
- Record the running kernel: capture
uname -rbefore and after the change. An installed kernel is not necessarily the running kernel. - Map the package flavor: identify the package that supplied the running kernel and distinguish generic, HWE, cloud, OEM, real-time, and vendor kernels.
- Save the vendor row: record the live Ubuntu status, URL, exact check time, release, package, and revision. A screenshot without a timestamp is weak evidence.
- Review reachability: identify TCP services and network paths that must remain reachable. Reduce unnecessary exposure through normal approved controls while a fix is pending.
- Apply supported updates: use configured Ubuntu repositories and the organization's change process. Do not install an unrelated upstream kernel solely to satisfy a version comparison.
- Activate and verify: complete any required reboot or vendor-approved activation step, then prove the intended kernel is running and the matching package is marked fixed.
Safe Ubuntu Inventory, Update, and Verification Commands
These commands support authorized inventory and package management. They do not test exploitability and their output must be interpreted against the live vendor package row.
cat /etc/os-release — identify the Ubuntu release
Use: capture the release name and version that determine which Ubuntu tracker row applies.
$ cat /etc/os-releaseRecord: save the full output with the host ID and collection time. Do not infer the release from the kernel version alone.
uname -r — record the running kernel
Use: identify the kernel currently active in memory before and after the maintenance window.
$ uname -rRecord: a newly installed package does not protect the host if an older vulnerable kernel is still running.
dpkg -l 'linux-image*' — list installed kernel-image packages
Use: expose installed package names, versions, and flavors that can be compared with Ubuntu's package rows.
$ dpkg -l 'linux-image*'Record: distinguish installed packages from the running kernel, and do not assume the generic linux source-package row covers every flavor.
ss -ltnp — review listening TCP services
Use: inspect authorized local service exposure and identify which TCP listeners require network reachability review.
$ sudo ss -ltnpPrecaution: this is local inventory, not proof that a service is reachable from another network. Confirm paths with approved firewall and load-balancer records.
sudo apt update — refresh signed repository metadata
Use: refresh package information from the host's configured repositories before reviewing available updates.
$ sudo apt updatePrecaution: confirm approved repositories and investigate signature or mirror errors. Refreshing metadata does not install a fix.
sudo apt upgrade — apply approved available updates
Use: install updates through Ubuntu's package manager within the organization's tested change process.
$ sudo apt upgradePrecaution: review the transaction, maintenance impact, rollback plan, and reboot requirement. A successful command is not CVE-specific closure proof.
uname -r after reboot — verify activation
Use: after the approved rollout and any required reboot, prove that the intended kernel is now running.
$ uname -r
$ dpkg -l 'linux-image*'Closure check: match the post-change running kernel and installed package to a live Ubuntu row that actually reports a fixed state.
Authoritative Sources and Defensive-Use Scope
- Ubuntu CVE-2026-98432 tracker — live package rows, Ubuntu priority, CVSS values, and patch references.
- Linux CNA CVE record — technical description and upstream branch information.
- Upstream Linux fix — source change referenced by Ubuntu and Debian.
- Debian security tracker — distribution-specific fixed-package examples.
- Ubuntu CVE status and update guidance — status meanings and supported update workflow.
- CISA Known Exploited Vulnerabilities catalog — live government catalog to recheck during triage.
CVE-2026-98432 Ubuntu Triage Frequently Asked Questions
Is CVE-2026-98432 fixed in Ubuntu?
At the October 30, 2026 review, Ubuntu still marked the generic linux package rows for Ubuntu 26.10, 26.04 LTS, 24.04 LTS, and 22.04 LTS as vulnerable with fixes in progress. Check the exact live package and release row before making a closure decision.
Can an upstream fixed kernel version be used as the Ubuntu patch target?
No. Ubuntu commonly backports security fixes, so an upstream version is not a universal minimum for Ubuntu. Use the exact Ubuntu package flavor, release, revision, and vendor status.
Does disabling TCP request migration fully mitigate CVE-2026-98432?
No. The Linux CNA description identifies a first IPv4 options race that does not depend on request-socket migration. Disabling migration does not remove that path and is not a substitute for an approved fixed package.
What evidence should close a CVE-2026-98432 patch ticket?
Record the Ubuntu release, running kernel, installed kernel package and flavor, matching live vendor status, update source, reboot or activation evidence, and a post-change running-kernel verification.