CVE-2026-98432: close the Linux kernel TCP flaw on Debian, Ubuntu and Proxmox

In mid-October 2026 a flaw in the TCP connection set-up of the Linux kernel became public that can be attacked through any port reachable over IPv4, without any login. Debian and Proxmox have shipped fixed kernels, Ubuntu has not yet. This article explains who is affected, which versions are safe, what helps until you can patch and how to rate your servers with our free check script.

What happened?

The flaw was reported by Xinyang Ge of Anthropic; Eric Dumazet wrote the fix and submitted it on 1 October. It is part of Linux 7.3-rc7 and of every maintained stable branch. The distributions followed at very different speeds:

• 1 Oct: the patch “ipv4: free inet_opt and ireq_opt after an RCU grace period” goes to the networking maintainers.
• 15 Oct: the kernel CVE team publishes CVE-2026-98432 together with the fixed stable versions.
• 16 Oct: Debian ships linux 6.12.113-1 for Debian 13 (DSA-6568-1).
• 17 Oct: Debian LTS follows for Debian 12 with linux 6.1.190-1 (DLA-4841-1). In the evening Proxmox builds kernel 7.0.14-25 on the Ubuntu-7.0.0-43.43 sources.
• 22 Oct: Debian LTS ships the optional linux-6.12 kernel for Debian 12 (DLA-4850-1); Proxmox builds 7.0.14-26.
• 26 Oct: Ubuntu places the fixed kernels 6.8.0-149.149 (24.04) and 5.15.0-203.213 (22.04) in the pre-release pocket -proposed.
• 27 Oct: Anthropic describes an exploit written by a Claude model: root without any action by the victim on servers with an MPTCP listener.
• 28 Oct: 7.0.0-43.43 for 26.04 follows in -proposed. On the same day the regular 7.0.0-42 appears, still without the fix.
• 29 Oct: Ubuntu lists the fixed versions for 22.04 to 26.10 as “work in progress” in its CVE tracker; none has been released. More kernel variants follow on the evening of 30 October.
• 30 Oct: according to Proxmox, 7.0.14-25 and -26 are now also in the enterprise repository.

The flaw in plain words

During TCP connection set-up the kernel creates a connection request for every incoming SYN and keeps the packet's IPv4 options there, such as Record Route or Timestamp. When the final ACK arrives, the actual socket is created from it. The function tcp_v4_syn_recv_sock() hands the options over to that socket without copying them.

If the client retransmits its SYN at exactly that moment, another CPU still builds a SYN-ACK from the same options while the new socket is torn down again and the memory is freed: a use-after-free in ip_options_build(). The same race exists when connection requests migrate between sockets (net.ipv4.tcp_migrate_req=1 or a BPF program for SO_REUSEPORT). The fix frees the options only after an RCU grace period, with kfree_rcu() instead of kfree().

• Prerequisite: a TCP port in the LISTEN state reachable over IPv4 plus packets with IP options that make it all the way to the server. The attacker needs no login.
• Repeatable: according to Anthropic, a lost race only aborts the handshake and the server does not crash. The attacker can therefore try again and again.
• MPTCP: Anthropic's exploit targets servers with a Multipath TCP listener; Anthropic does not say why. The flaw itself sits in plain TCP; the CVE announcement does not mention MPTCP.
• IPv6: tcp_v6_syn_recv_sock() copies the options, so native IPv6 connections are not affected by the main flaw. A separate patch is to address the IPv6 side of the migration. IPv4 connections to dual-stack sockets ([::]), however, go through the IPv4 path in the kernel.

Who is affected?

Every kernel from Linux 4.4 onwards that accepts connections over IPv4 is affected: SSH, web servers, mail servers, databases, the management interface of a hypervisor. What matters is which kernel accepts the connection:

Safe versions

The fixed versions as of 31 October 2026. What counts is the running kernel, not the installed one. Upstream, these stable versions are fixed: 5.10.272 · 5.15.223 · 6.1.190 · 6.6.159 · 6.12.113 · 6.18.56 · 7.2.10 · 7.3.

Ubuntu's cloud kernels (linux-aws, -azure, -gcp, -oracle, -ibm) carry their own version numbers; the check script knows the announced versions of every variant. We have not checked whether Canonical Livepatch covers the flaw; canonical-livepatch status is authoritative.

1.Patch and reboot

On Debian and Proxmox the normal package sources are enough. The second step is the important one: a new kernel only takes effect after a reboot.

sudo apt update
sudo apt full-upgrade            # pulls the fixed linux-image package
sudo reboot

# afterwards: Debian package version of the running kernel
uname -v | grep -oP 'Debian \K\S+'

apt update && apt full-upgrade
apt install proxmox-kernel-7.0          # only if the node still runs 6.17
proxmox-boot-tool kernel list           # no old kernel pinned?
reboot
uname -r                                # 7.0.14-25-pve or newer

In a cluster, reboot the nodes one at a time: migrate the VMs first and, with Ceph, set ceph osd set noout beforehand and unset it after the reboot. These one-liners show whether the running kernel has the fix and print a ready verdict:

# Proxmox VE
k=$(uname -r); dpkg --compare-versions "${k%-pve}" ge 7.0.14-25 && echo "OK: $k" || echo "VULNERABLE: $k"

# Debian
v=$(uname -v | grep -oP 'Debian \K\S+'); case "$v" in 6.1.*) t=6.1.190-1;; 6.12.*) t=6.12.113-1~deb12u1;; *) t=;; esac; [ -z "$t" ] && echo "CHECK: $v" || { dpkg --compare-versions "$v" ge "$t" && echo "OK: $v" || echo "VULNERABLE: $v"; }

Ubuntu: take the fix early from -proposed

Until the release, the rule for Ubuntu is: put the stopgap in place, then run apt update && apt full-upgrade and reboot as soon as the update appears. If you do not want to leave exposed servers open that long, you can take just the kernel from the pre-release pocket -proposed. 7.0.0-43.43 for 26.04 has been there since 28 October, 6.8.0-149.149 for 24.04 and 5.15.0-203.213 for 22.04 since 26 October; the changelog of 7.0.0-43.43 lists the fix “ipv4: free inet_opt and ireq_opt after an RCU grace period”. We reproduced the steps in an Ubuntu 26.04 container: without -t apt stays on 7.0.0-42, with -t it installs 7.0.0-43.43.

# make -proposed known; priority 100 means apt takes nothing from it unasked
sudo tee /etc/apt/sources.list.d/proposed.sources >/dev/null <<'EOF'
Types: deb
URIs: http://archive.ubuntu.com/ubuntu
Suites: resolute-proposed
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg
EOF
printf 'Package: *\nPin: release a=resolute-proposed\nPin-Priority: 100\n' | sudo tee /etc/apt/preferences.d/proposed-updates
sudo apt update

# dry run first: which packages would come from -proposed?
sudo apt install -s -t resolute-proposed linux-generic | grep '^Inst'
sudo apt install -t resolute-proposed linux-generic
sudo reboot
uname -r                                  # 7.0.0-43-generic

• Only the kernel: priority 100 keeps apt full-upgrade from taking anything from -proposed; on 22.04 the file in preferences.d is mandatory, from 24.04 onwards Ubuntu sets this priority itself. Other kernel variants come through their metapackage, such as linux-aws or linux-generic-hwe-22.04, provided Ubuntu has already placed them in -proposed; the dry run with -s shows it. On ARM servers the source is http://ports.ubuntu.com/ubuntu-ports.
• Pre-release means testing: not every kernel in -proposed gets released; on 26.04, for example, 7.0.0-17, -26 and -39 never reached the regular pockets. Install on a test system first, then on the exposed servers.
• Clean up afterwards: once the kernel is released regularly, delete both files and run apt update. From then on kernels come only from the normal sources again.

The check script knows the announced fixed versions and therefore already rates a kernel from -proposed as fixed.

2.The special case of Proxmox VE 8

Proxmox VE 8 has been out of support since August 2026. The last kernel of the 8 branch, 6.8.12-43, dates from 18 August, the optional 6.14.11-9 from 15 May. Both predate the patch. According to Proxmox, the 7.0 kernel will not be made available for Proxmox VE 8. The only way out is the upgrade to Proxmox VE 9, with these prerequisites from the upgrade guide:

• every node on 8.4 with pve-manager 8.4.1 or later and at least one clean run of pve8to9 --full;
• hyper-converged Ceph upgraded to Squid 19.2 beforehand;
• tested backups of every VM and container, console access via IPMI or on site, at least 5 GB free on /;
• no containers with systemd 230 or older (cgroup v1), such as CentOS 7 or Ubuntu 16.04.

Until the upgrade is done, the firewall in front of the cluster needs a rule against IPv4 options; the management services must only be reachable from the management network.

3.Stopgap until you can patch

The attack needs IPv4 packets carrying options. Dropping them before they reach the kernel takes away its basis. This works best at the firewall in front of the servers, because it protects every system at once.

At the firewall: Palo Alto Networks

Port and application rules do not help: the first SYN to a permitted port passes before App-ID knows the application. PAN-OS drops IP options through a Zone Protection profile:

1. Network › Network Profiles › Zone Protection: create a profile and, on the Packet Based Attack Protection › IP Drop tab, tick Timestamp and Record Route. Palo Alto's best practice adds Strict and Loose Source Routing, Unknown and Malformed.
2. Network › Zones: assign the profile to the internet zone and commit.

On the host: nftables

These rules drop TCP packets whose IPv4 header is longer than 20 bytes, in other words carries options. The inet table sees everything that reaches the host itself or that the host routes, the bridge table everything that crosses a bridge. Which one you need depends on how the guests are attached:

Together, the two tables cover every one of these setups except the last. The file can be loaded repeatedly and only ever replaces its own tables:

#!/usr/sbin/nft -f
# Stopgap CVE-2026-98432: drop IPv4 TCP packets that carry IP options.
# Re-running replaces only these two tables; other tables stay untouched.
table inet cve98432
delete table inet cve98432
table bridge cve98432
delete table bridge cve98432

table inet cve98432 {
  chain pre {
    type filter hook prerouting priority -310;
    ip protocol tcp ip hdrlength gt 5 counter drop
  }
}
table bridge cve98432 {
  chain pre {
    type filter hook prerouting priority -310;
    ip protocol tcp ip hdrlength gt 5 counter drop
  }
}

Loading the rules permanently

Loaded with nft -f, the rules only last until the next reboot. For permanent use there are two ways:

• A dedicated systemd unit: it loads the rules before the network comes up and is modelled on Debian's nftables.service, just without flush ruleset.
• An entry in /etc/rc.local: a good fit if your firewall rules already live there. According to systemd, though, rc.local only runs after network.target, which leaves a short unprotected window at boot.

[Unit]
Description=Stopgap CVE-2026-98432: drop IPv4 TCP packets with IP options
Wants=network-pre.target
Before=network-pre.target shutdown.target
Conflicts=shutdown.target
DefaultDependencies=no

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/nft -f /etc/nftables.d/cve-2026-98432.nft
ExecReload=/usr/sbin/nft -f /etc/nftables.d/cve-2026-98432.nft
ExecStop=-/usr/sbin/nft delete table inet cve98432
ExecStop=-/usr/sbin/nft delete table bridge cve98432

[Install]
WantedBy=sysinit.target

systemctl daemon-reload && systemctl enable --now cve-2026-98432-stopgap.service

For /etc/rc.local, put this block before exit 0 instead. If it fails, it writes a message to the journal and rc.local carries on. Even under #!/bin/sh -e your remaining rules are therefore not skipped:

# CVE-2026-98432 stopgap: drop IPv4 TCP packets with IP options (host, routed and bridged guests)
nft -f - <<'EOF' || logger -t rc.local "CVE-2026-98432 stopgap: nft load failed"
table inet cve98432
delete table inet cve98432
table bridge cve98432
delete table bridge cve98432
table inet cve98432 {
  chain pre {
    type filter hook prerouting priority -310;
    ip protocol tcp ip hdrlength gt 5 counter drop
  }
}
table bridge cve98432 {
  chain pre {
    type filter hook prerouting priority -310;
    ip protocol tcp ip hdrlength gt 5 counter drop
  }
}
EOF

With iptables only

If you manage your rules with iptables, the u32 extension does the same job. It reads the length field of the IPv4 header; the leading -C prevents duplicate entries:

# CVE-2026-98432 stopgap: drop IPv4 TCP packets with IP options (host and routed guests)
iptables -t raw -C PREROUTING -p tcp -m u32 --u32 "0>>24&0xF=6:15" -j DROP 2>/dev/null || iptables -t raw -I PREROUTING -p tcp -m u32 --u32 "0>>24&0xF=6:15" -j DROP

• Enough for: the host's services and guests on a bridge that the host only routes to.
• Not enough for: guests on a bridge with a layer-2 uplink. iptables only sees that traffic with br_netfilter and net.bridge.bridge-nf-call-iptables=1. Then, however, every bridged packet also passes through the FORWARD chain; in our test a FORWARD policy of DROP cut the guests off completely.
• Check script: cve-2026-98432-check.sh only recognises the nftables rule as a stopgap.

Practical test: do the rules work?

A test against an open TCP port shows whether your firewall and hosts really drop these packets. It opens three connections: one without options as a control, one with Record Route and one with Timestamp. All it needs is Python 3 on a Linux machine without root rights. It sends just one ordinary connection attempt per variant.

python3 - TARGET-IP 22 <<'EOF'
# Practical test for the CVE-2026-98432 stopgap: does a SYN with IPv4 options reach the service?
import socket, sys
host, port = sys.argv[1], int(sys.argv[2])
OPTIONS = {"none": b"",
           "record-route": bytes([7, 7, 4, 0, 0, 0, 0]),
           "timestamp": bytes([68, 8, 5, 0, 0, 0, 0, 0])}

def probe(opt):
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.settimeout(3)
    if opt:
        s.setsockopt(socket.IPPROTO_IP, socket.IP_OPTIONS, opt)
    try:
        s.connect((host, port))
        return "OPEN"
    except socket.timeout:
        return "DROPPED"
    except ConnectionRefusedError:
        return "REFUSED"
    except OSError as e:
        return "ERROR " + (e.strerror or str(e))
    finally:
        s.close()

res = {name: probe(opt) for name, opt in OPTIONS.items()}
for name, r in res.items():
    print(f"{name:13s} {r}")
with_opts = [r for n, r in res.items() if n != "none"]
if res["none"] != "OPEN":
    print(f"RESULT: INCONCLUSIVE, {host}:{port} accepts no connection even without options")
elif all(r == "DROPPED" for r in with_opts):
    print("RESULT: PROTECTED, SYNs with IP options are dropped on the way")
elif any(r in ("OPEN", "REFUSED") for r in with_opts):
    print("RESULT: NOT PROTECTED, SYNs with IP options reach the target")
else:
    print("RESULT: INCONCLUSIVE, check the lines above")
EOF

What the test checks depends on where the probe machine sits. For a complete picture of your own infrastructure, it is worth testing from all three positions:

A PROTECTED only tells you that the packet was dropped somewhere. The counters show where: on the host the line containing hdrlength, on Palo Alto Networks show zone-protection zone <zone>. If no counter rises, some other network in between dropped the packet. The probe machine itself must therefore not sit behind a firewall that drops IP options.

echo "rules: $(nft list ruleset | grep -c 'hdrlength > 5') (expected 2)"
nft list ruleset | grep 'hdrlength > 5'
iptables -t raw -L PREROUTING -v -n | grep '0xf=0x6:0xf'   # iptables variant

Further steps

• Limits: anyone who uses IPv4 options themselves, such as Record Route for troubleshooting, loses those packets. The rule on the host protects VMs from outside but does not replace the kernel update inside the guest.
• Disable MPTCP: sysctl -w net.mptcp.enabled=0, made permanent under /etc/sysctl.d/. This closes the path of the published exploit, not the flaw; existing MPTCP listeners stay until the service restarts.
• Leave migration off: net.ipv4.tcp_migrate_req defaults to 0.
• Shrink the attack surface: expose SSH and management interfaces only to the management network or over VPN.

4.The check script cve-2026-98432-check.sh

We have turned the checks from this article into a script. It runs as root, changes nothing on the system and writes only a report. The console shows nothing but fixed texts, kernel versions and counts; ports, addresses and processes go only into the report, which only root can read. That makes the output safe to pass on.

curl -fsSLO https://nokkela.blog/downloads/cve-2026-98432-check.sh
curl -fsSLO https://nokkela.blog/downloads/cve-2026-98432-check.sh.sha256
sha256sum -c cve-2026-98432-check.sh.sha256     # must print: cve-2026-98432-check.sh: OK

sudo bash cve-2026-98432-check.sh

Read the script before the first run: it is just over 500 lines of Bash with no dependencies beyond what Debian, Ubuntu and Proxmox ship. This is the output in our test bed, a Debian 13 container with deliberately planted findings; the kernel there is the WSL2 kernel and therefore of unknown origin:

### cve-2026-98432-check 1.0.1 (Linux TCP use-after-free), fixed versions as of 2026-10-31
[ INFO ] Platform Debian GNU/Linux 13 (trixie)
[ INFO ] Running kernel 6.6.114.1-microsoft-standard-WSL2 (other)
[ INFO ] Inside a container (docker): this kernel belongs to the host, fix it there

### Kernel
[FAILED] 'Kernel of unknown origin 6.6.114.1-microsoft-standard-WSL2: below the fixed version 6.6.159 upstream, ask its vendor'

### Exposure until the fixed kernel runs
[ INFO ] TCP listeners beyond loopback (IPv4 reaches dual-stack sockets too): 1 (report line 9)
[  OK  ] 'MPTCP disabled or not available'
[FAILED] 'Request socket migration on, second path of the race: 1 (report line 12)'
[ INFO ] nftables rules dropping IPv4 packets with options (stopgap): 1 (report line 15)

### Result
[FAILED] 'Yellow: 2, review and assess'
[ INFO ] Report: /opt/cve-2026-98432-check/reports/report-20261031-073818.txt
[ INFO ] View all details: tail -n +8 /opt/cve-2026-98432-check/reports/report-20261031-073818.txt

Red lines mean the running kernel lacks the fix. Yellow lines are settings that widen the attack surface, or a kernel whose origin the script does not know. The exit code is 2 for red, 1 for yellow and 0 without findings, so the script also fits into Ansible or a monitoring system.

No indicators of an attack have been published at the time of writing. In our view, kernel crashes (Oops, panic) since mid-October on a server with an open port are a reason to take a closer look.

Frequently asked questions

Sources

External sources, as of 31 October 2026 (open in a new tab):

• Linux kernel CVE team, announcement of CVE-2026-98432 with the fixed stable versions
• Linux, commit e3f33b0a1d89 “ipv4: free inet_opt and ireq_opt after an RCU grace period”
• CVE.org, CVE-2026-98432
• Debian Security Tracker, CVE-2026-98432
• Debian, DSA-6568-1 (trixie)
• Debian LTS, DLA-4841-1 (bookworm, linux)
• Debian LTS, DLA-4850-1 (bookworm, linux-6.12)
• Ubuntu, CVE tracker for CVE-2026-98432
• Launchpad, publishing history of the Ubuntu kernel (security, updates and proposed pockets)
• Launchpad, changelog of linux 7.0.0-43.43
• Ubuntu kernel team, How to test kernels in -proposed
• Red Hat, CVE-2026-98432
• Proxmox forum, CVE-2026-98432 in Proxmox VE (statements by the Proxmox team)
• Proxmox, pve-kernel 7.0.14-25
• Proxmox VE, FAQ with support periods
• Proxmox VE, Upgrade from 8 to 9
• Anthropic, Discovering and exploiting vulnerabilities with Claude
• Palo Alto Networks, Packet-Based Attack Protection
• Proxmox VE, Firewall (nftables firewall and custom tables)
• Debian, systemd-rc-local-generator(8): rc.local runs after network.target
• Debian, iptables-extensions(8) including the u32 extension

This article is for general information and does not replace a case-by-case assessment. Versions and commands reflect the stated date and must be adapted to your environment. The check script is provided under the BSD-2-Clause licence without warranty. As of October 2026.