CVE-2026-98432: Linux TCP Use-After-Free. Find It, Mitigate It, Auto-Remove It with Fleet

What it is

#

tcp_v4_syn_recv_sock() gives the new child socket the request socket’s IP options (ireq_opt) without copying them. A retransmitted SYN for the same request can then be processed on another CPU while the child is freed. The child’s inet_opt is freed with a plain kfree(), so the SYNACK builder reads freed memory in ip_options_build(). The fix switches both frees to kfree_rcu() (kernel commit e3f33b0a1d89).

Two conditions matter:

• IP options. In practice ireq_opt is non-NULL only when the SYN header has options (IHL > 5), or when SELinux/Smack NetLabel uses CIPSO, per the community mitigation write-up. Ordinary traffic does not carry options.
• IPv4 only. IPv6 copies the options and is not affected by the main race. A related race exists with net.ipv4.tcp_migrate_req=1 or a BPF SK_REUSEPORT migrate program (Ubuntu CVE page).

The intel

#

Sources: The Hacker News, Anthropic.

Anthropic says Claude wrote an exploit that gives a remote attacker with no credentials root on a Linux server with a multipath TCP (MPTCP) listener: a kernel address leak in 48 minutes, command execution five minutes later. The post does not include the exploit, the kernel version or the configuration tested. The CVE record and the fix never mention MPTCP, so treat MPTCP as the path Anthropic used, not as a precondition.

Scores disagree, and have moved. The kernel CNA says 9.8. On Oct 29 The Hacker News reported Oracle and SUSE at 8.1, Amazon at 7.0, and Red Hat at 5.9 on its CVE page but 8.1 in its advisory file. Red Hat’s page now shows 9.8 with attack complexity Low, still marked preliminary, and describes the impact as a crash or possible memory corruption (Red Hat). No exploitation had been reported as of Oct 29, and the bug was not in the CISA KEV copy CIRCL updated on Oct 28, per The Hacker News.

Who is affected

#

Linux 4.4 and later with an IPv4 TCP listener. Upstream fixes: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3. Distribution state on Oct 29:

Go programs listen with MPTCP by default since Go 1.24, per the Go Security Team as relayed by The Hacker News. A Go service on an unpatched host is the shape of target Anthropic describes.

Rush, or not

#

My assessment, not vendor guidance.

No public exploit, no KEV entry, and a race to win keep this out of “drop everything” for internal-only fleets. The window is the gap between a working exploit existing and your vendor shipping a kernel.

Find it with Fleet

#

Software and Vulnerabilities first. Fleet inventories deb_packages and rpm_packages hourly. Search Vulnerabilities for CVE-2026-98432; hosts running affected linux-image-* packages show up once the CVE is matched. That answers “who runs a vulnerable kernel”.

Then a live query for exposure. Run on Linux hosts. This is cheap: no package scan.

SELECT k.version AS running_kernel,
       o.version AS os_version,
       (SELECT current_value FROM system_controls WHERE name = 'net.mptcp.enabled') AS mptcp_enabled,
       (SELECT current_value FROM system_controls WHERE name = 'net.ipv4.tcp_migrate_req') AS tcp_migrate_req
FROM kernel_info k, os_version o;

mptcp_enabled = 1 is the path Anthropic exploited; tcp_migrate_req = 1 adds the migration race. Pair it with Fleet’s listening-ports data to see which IPv4 TCP services are reachable.

Mitigate until the kernel ships

#

cve-2026-98432-mitigate.sh applies two controls on Ubuntu and keeps them across reboots with one systemd unit:

1. nftables ip protocol tcp ip hdrlength gt 5 counter drop in a prerouting chain at priority -310. This stops the SYNs that carry options.
2. sysctl net.mptcp.enabled = 0. Listeners that are already open keep MPTCP until their service restarts.

Based on a community mitigation (typhoon1217/cve-2026-98432-mitigation). Limits:

• It is unvendored and untested against a real exploit; no public exploit is known (Anthropic did not publish its own). Red Hat says no mitigation meets its criteria.
• It covers the host network namespace. Docker NAT traffic to published ports is dropped before it reaches a container, but containers with their own NIC (macvlan, ipvlan), traffic between containers on one bridge, and the SELinux/Smack CIPSO path are not covered.
• The unit is PartOf=nftables.service, so restarting nftables re-applies the rule. A reload that flushes the whole ruleset does not; restart cve-2026-98432-mitigation afterwards. osquery cannot see the live ruleset, so the policy trusts the unit state.
• It drops any IPv4 TCP that legitimately carries IP options. That is rare; watch the counter in nft list table inet cve_2026_98432.

Run it by hand to canary it: upload under Controls > Scripts, then Hosts > host > Actions > Run script, or fleetctl run-script --host <name> --script-path cve-2026-98432-mitigate.sh. Verify with osquery, which cannot read nftables but can see the unit, the files and the sysctl:

SELECT (SELECT current_value FROM system_controls WHERE name = 'net.mptcp.enabled') AS mptcp_enabled,
       (SELECT active_state || '/' || sub_state || '/' || unit_file_state
        FROM systemd_units WHERE id = 'cve-2026-98432-mitigation.service') AS unit_state,
       (SELECT COUNT(*) FROM file WHERE path = '/etc/cve-2026-98432.nft') AS nft_file_present;

Expected: 0, active/exited/enabled, 1. The script’s own check reads the live rule.

Policies: find the gaps, fix them on check-in

#

A policy checks every host on a schedule, and a policy automation can run a script on the hosts that fail it. cve-2026-98432-policies.yml defines two policies that share the one script:

- name: CVE-2026-98432 - Ubuntu kernel patched or mitigated
  platform: linux
  critical: true
  query: |
    SELECT 1 FROM os_version
    WHERE platform != 'ubuntu'
       OR EXISTS (
         SELECT 1 FROM os_version o, kernel_info k
         WHERE (o.major = 24 AND k.version LIKE '6.8.0-%-generic'
                AND CAST(substr(k.version, 7) AS INTEGER) >= 149)
            OR (o.major = 26 AND k.version LIKE '7.0.0-%-generic'
                AND CAST(substr(k.version, 7) AS INTEGER) >= 43))
       OR ((SELECT current_value FROM system_controls WHERE name = 'net.mptcp.enabled') = '0'
           AND EXISTS (SELECT 1 FROM file WHERE path = '/etc/cve-2026-98432.nft')
           AND EXISTS (SELECT 1 FROM systemd_units
                       WHERE id = 'cve-2026-98432-mitigation.service' AND active_state = 'active'));
  run_script:
    path: ../lib/cve-2026-98432-mitigate.sh

The kernel check compares the ABI number in kernel_info.version (6.8.0-149-generic gives 149), which avoids scanning deb_packages on every host. Only -generic kernels on 24.04 and 26.04 are recognised; HWE, cloud and low-latency kernels count as unpatched, so they keep the mitigation. The failing-host list on the policy page is your work queue.

How Fleet runs it, per the policy automation docs:

• The script runs when the policy newly fails on a host. A host that stays failing does not re-trigger it, and a failed run is retried up to 3 times, reset once the host passes.
• Policies run hourly by default, so a new host is contained within about an hour of its first run.
• Script automation on a policy is Fleet Premium, fleet-level policies only, not global ones.
• The script must be defined in the same fleet as the policy, and fleetd needs --enable-scripts (on by default with MDM).
• Editing the script’s content does not re-run it. Reset the policy from its Automation runs tab, or change the query.

Enable through the UI under Policies > Manage automations > Run script, or commit the YAML and let fleetctl gitops apply it.

When the patch lands

#

1. Ubuntu publishes the kernel. Confirm the version against the tracker and, if it differs from 6.8.0-149.149 or 7.0.0-43.43, edit fixed_for() in the script and the two numbers in the policy queries. The shipped values are Ubuntu’s work-in-progress targets, not a released fix. Only 24.04 and 26.04 -generic kernels are recognised: 22.04, 26.10, HWE and cloud kernels keep the mitigation until you add them.
2. Patch and reboot. Until the reboot the running kernel is still the old one, so the mitigation correctly stays.
3. The host boots the fixed kernel. Patched or mitigated still passes. Mitigation removed after patch now fails and runs the same script, which sees a fixed kernel and takes the mitigation out. Both pass on the next run.

To remove it by hand at any time, run cve-2026-98432-mitigate.sh revert on the host. status reports the kernel and mitigation state without changing anything.