Linux Kernel TCP Vulnerability CVE-2026-98432: Proxmox Kernel Update, Debian and Ubuntu Patching

Not planning kernel updates for Proxmox and Linux servers yourself? WZ-IT checks kernel versions, installs updates and coordinates restarts, see managed Linux server operations, Managed Proxmox and CVE monitoring. Book a consultation

On 15 October 2026 the Linux kernel CNA published the vulnerability CVE-2026-98432: a use-after-free in the IPv4 TCP connection setup, rated CVSS 3.1 9.8. Kernels from version 4.4 onward without the fix are affected. A research report of 27 October describes an exploit that runs commands as root without credentials on servers with an MPTCP listener. The report names no exploit code, kernel version or test configuration.

For admins the patch status comes first. Proxmox VE contains the fix since kernel 7.0.14-25, Debian since 16 October, RHEL since 1 November, AlmaLinux (production) since 2 November and Rocky Linux since 3 November. For Ubuntu 22.04, 24.04 and 26.04, the fix has been in the -updates pocket since 5 and 6 November, but not yet in -security. This article summarizes the vulnerability, the patch status, check commands, the procedure for a Proxmox cluster and interim measures. All information is as of 9 November 2026. The strategic context for kernel updates is covered in Linux kernel vulnerabilities 2026: patch management at board level; this article deals with this one case.

Table of contents

1. The vulnerability at a glance
2. How the vulnerability works
3. Is MPTCP required for the attack?
4. Patch status by distribution (as of 9 November 2026)
5. Check exposure: commands for Debian, Ubuntu, Proxmox and RHEL
6. Updating a Proxmox cluster: one node at a time
7. What helps until the reboot and what does not
8. Is the vulnerability being exploited?
9. Our approach at WZ-IT
10. Further reading

The vulnerability at a glance

Sources: CVE record, NVD, Red Hat, AlmaLinux, Akamai.

Vendor ratings differed at first. According to an analysis by Phoenix Security, Red Hat first published 5.9, then 8.1; today Red Hat itself lists the flaw at 9.8 with severity Critical. In our assessment, a scanner that sets patch deadlines from a single vendor's score can therefore rate this flaw too low.

How the vulnerability works

The error sits in how IP options are handed between two kernel objects (CVE description):

1. A client sends a SYN packet with IP options to an open IPv4 TCP port. According to the CNA's scenario these are Record Route or Timestamp. The kernel stores the options on the request socket (ireq_opt).
2. When the handshake completes, tcp_v4_syn_recv_sock() hands these options to the child socket (inet_opt) without copying them.
3. A second CPU concurrently processes a retransmitted SYN and builds a SYN-ACK from them, reading the same options.
4. If the child socket is freed at that moment, inet_sock_destruct() frees the options with a plain kfree(). ip_options_build() then reads freed memory.

A second path arises with request socket migration, that is with net.ipv4.tcp_migrate_req=1 or a BPF program of type BPF_SK_REUSEPORT_SELECT_OR_MIGRATE. The default of tcp_migrate_req is 0 (kernel documentation); a loaded BPF migration program cannot be recognized from the sysctl. The fix frees the options only after an RCU grace period (kfree_rcu() in inet_sock_destruct() and tcp_v4_reqsk_destructor()).

As consequences the CNA lists an information leak (extra heap bytes in the SYN-ACK), out-of-bounds writes and a crash via skb_under_panic(). The exploit described in the research report uses this in two stages: first, kernel address space layout randomization (KASLR) is defeated using a leaked kernel pointer; then a callback pointer is overwritten so that the kernel runs a shell command as root. According to the report, a lost race only fails the single handshake in this exploit, so the attacker can retry. In the one proof of concept described, the leak took 48 minutes and command execution another five minutes; these are not general attack times. The report names no exploit code, kernel version or test configuration.

Is MPTCP required for the attack?

For the exploit described so far, yes; for the vulnerability, no. Red Hat states that MPTCP is not a precondition: the required input is IPv4 options on an incoming connection request, combined with one of the two races. Canonical, the Go Security Team and a Proxmox staff member say the same. As routes to the affected code, PSA-2026-00080-1 names CIPSO/NetLabel configurations in addition to SYN packets with IPv4 options.

Whether MPTCP sockets are possible on a system depends on the kernel:

The default of 1 comes from the kernel documentation on MPTCP; on site, sysctl net.mptcp.enabled decides. An MPTCP listener only appears if a program requests it when creating the socket (MPTCP project). Go programs do so for listeners by default since Go 1.24 unless configured otherwise (for example GODEBUG=multipathtcp=0). ss -Mlnp lists existing MPTCP listeners with their process; it does not list all Go services and says nothing about their Go version (see below).

An empty result is not an all-clear and only a snapshot of the network namespace checked: Red Hat writes that the absence of MPTCP listeners should be treated as information, not as reassurance. The patch is needed even without MPTCP.

Patch status by distribution (as of 9 November 2026)

Proxmox VE, Proxmox Backup Server and Mail Gateway

The sources for 7.0.14-25 were moved to the Ubuntu state 7.0.0-43.43 on 17 October 2026 (changelog entry Ubuntu-7.0.0-43.43i1, commit). A Proxmox staff member confirmed on 30 October that the fix commit from the CVE announcement is contained in 7.0.14-25 and -26 and that both versions are in the enterprise repository. The package index of the Proxmox VE no-subscription repository (Trixie) carries the modification date 6 November and contains builds up to 7.0.14-28. The no-subscription package indexes of Proxmox Backup Server and Mail Gateway list 7.0.14-25 and -26 on 9 November (our own check of the indexes). According to the Proxmox FAQ, Proxmox VE 8 reached end of life in August 2026 and has no fixed kernel; there, the upgrade to Proxmox VE 9 with kernel 7.0 is required. On an existing Proxmox VE 9 with an older kernel (6.17, 6.14), switching to a fixed kernel of the 7.0 series is in principle enough, no further major upgrade is needed.

Debian

The tracker currently lists 6.12.116-1 for trixie-security; within the 6.12 series of the official Debian packages, every version from 6.12.113-1 onward contains the fix.

Ubuntu

Sources: Ubuntu CVE page (last updated 9 November 2026), Canonical blog of 2 November and the archive (published source packages for 22.04, 24.04 and 26.04). The changelogs of these packages contain the fix "ipv4: free inet_opt and ireq_opt after an RCU grace period" (our own check on 9 November 2026). According to the Launchpad publishing history (UTC), 22.04 reached -updates on 5 November at 23:22 and 24.04 and 26.04 on 6 November at 01:14. On 9 November, -security still held 5.15.0-202.212, 6.8.0-147.147 and 7.0.0-42.42.

Three points about Ubuntu:

• The CVE page lags behind. On 9 November it still lists the LTS releases as "pending" although the kernels are already in -updates. The tracker lists no Ubuntu Security Notice for this CVE yet.
• Hosts that update only from -security do not get the kernel automatically. The default template of unattended-upgrades pulls from <codename>, <codename>-security and the ESM origins (where present); -updates is commented out. Such a configuration installs the kernel only after it is released to -security. Until then, a manual apt full-upgrade is possible (it requires -updates in the APT sources), as is adding -updates to Allowed-Origins; local configuration, pins and holds can differ.
• HWE, cloud and older LTS kernels have their own status. According to the tracker, nothing is planned yet for linux-hwe-6.17 (24.04), while linux-hwe-7.0 (24.04) and linux-hwe-6.8 (22.04) are "pending". Kernels such as linux-aws, linux-azure or linux-gcp are separate packages and need to be checked in the tracker per release. For Ubuntu 14.04, "not affected" applies only to the package linux; the tracker lists linux-lts-xenial, linux-aws and linux-azure there as vulnerable.

RHEL, AlmaLinux and Rocky Linux

The Red Hat security data for the CVE list RHEL 6 and 7 as not affected. For further product streams with their own kernel versions, Red Hat has published additional errata (2 to 4 November), for example for Extended Update Support (EUS), Advanced Mission Critical Update Support (AUS), Telecommunications Update Service (TUS) and Update Services for SAP Solutions (E4S); the full list is in the same security data.

Check exposure: commands for Debian, Ubuntu, Proxmox and RHEL

Debian and Ubuntu

# running kernel
uname -r
# Debian kernels: the version string contains the package version (e.g. "Debian 6.1.190-1"); the dpkg package list is authoritative
uname -v
# installed kernel packages
dpkg -l 'linux-image*' | grep ^ii
# install the update, pulls in new kernel packages
sudo apt update && sudo apt full-upgrade
# shows whether the running kernel is older than the installed one (package needrestart)
sudo needrestart -k

Ubuntu shows the kernel version as an ABI number: 6.8.0-149-generic corresponds to 6.8.0-149.149. Fixed are 22.04 from 5.15.0-203, 24.04 from 6.8.0-149 and 26.04 from 7.0.0-43. Ubuntu names uname -r and dpkg -l 'linux-image*' | grep ^ii as the check in its blog. For Debian, the versions in the table above apply.

Proxmox VE and Proxmox Backup Server

# shows, among other things, "running kernel: 7.0.14-25-pve"
pveversion
uname -r
# pins and installed kernels
proxmox-boot-tool kernel list
# package state on Backup Server
proxmox-backup-manager versions --verbose
sudo apt update && sudo apt full-upgrade

Fixed is 7.0.14-25-pve or newer. A set pin (proxmox-boot-tool kernel pin) keeps the host on the old kernel after the update; proxmox-boot-tool kernel unpin removes it. On systems that synchronize their boot partitions (ESP) with proxmox-boot-tool, proxmox-boot-tool refresh follows (Proxmox documentation). Without a configured repository that carries the current Proxmox kernel packages (enterprise or no-subscription; a forum user also names the test repository), apt does not deliver the fixed kernel; a forum thread describes this case on a freshly installed version 9.2, solved by the no-subscription repository.

RHEL, AlmaLinux, Rocky Linux

uname -r
rpm -q kernel
sudo dnf clean metadata && sudo dnf upgrade
# exit code 1 = restart needed; requires the package dnf-plugins-core
sudo dnf needs-restarting -r

MPTCP, migration and reachability (all systems)

sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req
# MPTCP listeners with their process
ss -Mlnp
# all IPv4 listeners that might be reachable from networks
ss -4 -ltnp

Older iproute2 versions reject the -M option (TuxCare). ss -Mlnp lists MPTCP listeners with their process and only answers whether the exploit path described so far is open, not whether the kernel is vulnerable; it shows neither all Go services nor their Go version. The output applies to the network namespace in which the command runs (net.mptcp.enabled applies per namespace); containers with their own namespace need to be checked separately. sysctl net.ipv4.tcp_migrate_req shows only the sysctl, not a loaded BPF program of type BPF_SK_REUSEPORT_SELECT_OR_MIGRATE. Akamai also provides a check script under the MIT license whose default mode only reads; as with any third-party script: read the code before running it.

Updating a Proxmox cluster: one node at a time

One restart per node is enough as long as the fixed kernel is installed and boots and quorum is maintained. The procedure per node:

1. Check beforehand. Current backup, quorum (pvecm status), Ceph health (ceph -s) if used, repositories and pins (proxmox-boot-tool kernel list).
2. Move the guests. For HA services, set maintenance mode: ha-manager crm-command node-maintenance enable pve1. The node is marked unavailable for HA and the services move to other nodes, depending on HA rules and available target nodes (Proxmox HA documentation). The status maintenance appears as soon as the command has been picked up, that is before all moves are complete; before the restart, wait until no HA services remain on the node (ha-manager status) and the log shows watchdog closed (disabled). Running VMs without HA move with qm migrate <vmid> pve2 --online, provided no locally bound devices such as passthrough are configured, the target node is in the same cluster, is reliably reachable over the network, has the same or newer Proxmox packages and a compatible CPU (Proxmox VM documentation). Running LXC containers cannot be live-migrated; pct migrate <ctid> pve2 --restart stops the container, moves it and starts it on the target node (Proxmox container documentation).
3. Update and restart. Once no HA services and guests remain on the node: sudo apt update && sudo apt full-upgrade, then reboot.
4. Verify the kernel. uname -r shows 7.0.14-25-pve or newer, and pveversion names the running kernel.
5. End maintenance mode. ha-manager crm-command node-maintenance disable pve1. The documentation notes that the mode does not end automatically on restart; only then do the services move back.
6. Only then the next node. Confirm quorum and, with Ceph, wait for a healthy state.

Then the guests remain:

• VMs have their own kernel. Linux guests with an affected kernel are updated like the Debian, Ubuntu or RHEL systems above, independent of the host. When asked in the forum whether patched guests are enough, a Proxmox staff member writes that the fix on the host is very much advised.
• LXC containers use the host's kernel. They are protected once the host runs a fixed kernel; the Proxmox documentation states that containers use the host kernel directly.
• Proxmox Backup Server runs on the same kernel packages and belongs in the plan. Restart only when no backup or restore is running.

What helps until the reboot and what does not

Red Hat names applying the kernel security updates as the only complete solution, and AWS names a kernel update and reboot for EC2. Until the restart:

The rule from the Red Hat bulletin, which the Ubuntu CVE page also lists, is:

sudo tee /etc/cve-2026-98432.nft >/dev/null <<'EOF'
table inet cve_2026_98432 {
  chain input {
    type filter hook input priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}
EOF
sudo nft -c -f /etc/cve-2026-98432.nft && sudo nft -f /etc/cve-2026-98432.nft
sudo nft list table inet cve_2026_98432
# remove it once the fixed kernel is running
sudo nft delete table inet cve_2026_98432

ip hdrlength > 5 matches every IPv4 header longer than 20 bytes, that is every packet with IP options. Try the rule in a test environment first, as Red Hat also requires. The host's rule does not apply to containers with their own network namespace; the Ubuntu CVE page points out that it must be set there separately. VMs need the kernel fix in the guest anyway. The full instructions including persistence are in the mitigation section of the Ubuntu CVE page.

Live patching: a suitable live patch from the vendor that is installed and active can replace the restart; AWS mentions this for Ubuntu WorkSpaces. The Canonical, Debian and Proxmox sources we checked make no statement about a live patch for this CVE. In its post, TuxCare names a KernelCare patch for Debian 13; that is a vendor statement to verify against your own kernel before relying on it.

Is the vulnerability being exploited?

As of 9 November 2026, no exploitation is confirmed in the sources checked:

• The CVE is not in CISA's KEV catalog (catalog version 2026.11.06, checked on 9 November 2026).
• AWS writes in bulletin 2026-160-AWS (updated 6 November) that it has no evidence of exploitation.
• As of 2 November, Akamai knows of no public working exploit.
• The exploit described in the research report is not published. The kernel team at CloudLinux could not reproduce the remote root claim (as of 3 November).
• A third-party proof-of-concept program is on GitHub that, by its own description, triggers the race and shows memory contents in the SYN-ACK but does not run commands (the author's description, not checked by us). Code from third-party exploit repositories should be read before any execution and run only in an isolated test environment.
• Reports of scans for MPTCP listeners exist (ThreatDefence), but they come from third parties and are not independently confirmed.

In GKE bulletin GCP-2026-078 of 4 November, Google also names a local trigger path: an unprivileged process in a container can trigger the flaw without special capabilities, up to root on the node. The vendor sources we checked contain no confirmation of this so far. In our assessment, for hosts that run containers with third-party code this is a reason to patch them before pure management hosts.

Our assessment of the order by exposure (not a vendor requirement): first hosts with IPv4 TCP services reachable from the internet, then hosts with MPTCP listeners (including Go services from Go 1.24) and hosts with containers from other tenants, then internal systems.

Our approach at WZ-IT

WZ-IT looks after Linux servers with managed Linux server operations (from €149.90 net per month for the first server) and Proxmox environments with Managed Proxmox. For a kernel vulnerability like CVE-2026-98432 the approach consists of five steps:

1. Establish exposure. Record the running kernel, repositories, pins and MPTCP listeners of all hosts, guests and containers individually.
2. Order by exposure. Hosts reachable from the internet or foreign networks first, multi-tenant container hosts before management systems.
3. Secure the interim if needed. Limit reachability and apply the vendors' filter rule in a documented way, removed again after the update.
4. Patch. Proxmox nodes one after another with migration and restart, then verify the running kernel; guests in the agreed maintenance window.
5. Monitor continuously. CVE monitoring cross-checks the NVD, vendor advisories, the Debian and Ubuntu security trackers and CERT-Bund, checks exposure, prioritizes by risk and manages patches with documentation. A server audit records the inventory and open kernel versions up front.

On the maintenance itself: Proxmox maintenance and Proxmox security describe what belongs to the ongoing operation of a Proxmox environment.

Further reading

• Linux kernel vulnerabilities 2026: patch management at board level, the strategic context for kernel updates and responsibility.
• pedit COW and DirtyClone: two Linux kernel flaws 2026, local privilege escalation and container escalation.
• CVE monitoring for self-hosted software, how vulnerabilities are tracked in a structured way.
• Proxmox expertise at WZ-IT, the overview of consulting, operations and maintenance.
• Proxmox maintenance, updates, kernels and operation of Proxmox environments.
• Proxmox security, hardening, patching and access protection for Proxmox.
• Managed Linux server operations, ongoing server operations with patching and monitoring.
• CVE monitoring, track and assess vulnerabilities and manage patches.
• Server audit, inventory, attack surface and prioritized measures.
• SSHole (CVE-2026-123158): check OpenSSH on Alpine - another current security case (as of November 2026)
• APT vulnerability CVE-2026-109518 in Debian and Ubuntu - another current security case (as of November 2026)
• CWPdoor: check for the Control Web Panel backdoor - another current security case (as of November 2026)
• Node-RED editor without adminAuth: CVE-2026-58115 (Siemens IoT2050) - another current security case (as of November 2026)

Have the kernel state of your servers and Proxmox nodes checked? We record kernel versions, repositories and reboot requirements and plan the updates for hosts, guests and containers, see managed Linux server operations. Book a consultation

Sources

• CVE record CVE-2026-98432, cve.org
• NVD: CVE-2026-98432
• Linux kernel: fix commit e3f33b0a1d89 (ipv4: free inet_opt and ireq_opt after an RCU grace period)
• Linux kernel CNA: CVE announcement CVE-2026-98432
• Kernel documentation: MPTCP sysctls
• Kernel documentation: IP sysctls (tcp_migrate_req)
• MPTCP project: setup
• Anthropic: Discovering and exploiting vulnerabilities in critical, real-world software with Claude (27 October 2026)
• Akamai: CVE-2026-98432, A Remote Use-After-Free in the Linux Kernel's TCP Stack (2 November 2026)
• Akamai: check and mitigation script on GitHub
• Go Security Team: Protecting against CVE-2026-98432 when using Go programs (oss-security)
• Go 1.24 release notes
• oss-security: reply from CIQ on init_on_free=1
• Red Hat: CVE-2026-98432
• Red Hat: Security Bulletin RHSB-2026-016
• Red Hat: security data for CVE-2026-98432 (errata per product)
• Red Hat: RHSA-2026:93414 (RHEL 8)
• Red Hat: RHSA-2026:93412 (RHEL 9)
• Red Hat: RHSA-2026:93413 (RHEL 10)
• AlmaLinux: CVE-2026-98432, Patched kernels released
• Rocky Linux: RLSA-2026:93414
• Debian Security Tracker: CVE-2026-98432
• Debian: DSA-6568-1
• Debian: DLA-4841-1
• Debian: DLA-4850-1
• Ubuntu: CVE-2026-98432
• Canonical: Fixes available in -proposed pocket for CVE-2026-98432
• Ubuntu archive: linux 6.8.0-149.149 (24.04)
• Canonical: kernel configuration (annotations), branch jammy
• Canonical: kernel configuration (annotations), branch noble
• Canonical: kernel configuration (annotations), branch resolute
• unattended-upgrades: default configuration for Ubuntu
• Proxmox: PSA-2026-00080-1
• Proxmox forum: CVE-2026-98432 in Proxmox VE
• pve-kernel: commit 7.0.14-25
• pve-kernel: branches
• Proxmox forum: Kernel is not updated
• Proxmox VE: FAQ with support periods
• Proxmox VE: high availability and maintenance mode
• Proxmox VE: Linux containers
• Proxmox VE: virtual machines and live migration
• Proxmox: package index pve-no-subscription (Trixie)
• Proxmox: package index pbs-no-subscription (Trixie)
• Proxmox: package index pmg-no-subscription (Trixie)
• Proxmox VE: host administration, bootloader and kernel pinning
• AWS: bulletin 2026-160-AWS
• Google Cloud: security bulletin GCP-2026-078
• CISA: Known Exploited Vulnerabilities Catalog
• CloudLinux: CVE-2026-98432, status for CloudLinux
• MikroTik: CVE-2026-98432
• TuxCare: CVE-2026-98432 and KernelCare
• ThreatDefence: mitigation, hunting, patching
• Phoenix Security: scores from 5.9 to 9.8