Linux Kernel IPv4 TCP Use-After-Free (CVE-2026-98432)
Status: Advisory
Affected products: TrueNAS CE/Enterprise (SCALE) — 25.10 train (Linux 6.12) and 26.0 pre-release (Linux 6.18). TrueNAS CORE (FreeBSD) is not affected.
Severity (TrueNAS-adjusted): Medium — Critical class bug, but practical reach on a default TrueNAS deployment is gated (see threat model).
Upstream severity: Linux kernel CVE team: CVSS 3.1 9.8 (Critical, attack complexity Low). Red Hat / Oracle / SUSE: 8.1 (attack complexity High).
External references: Linux kernel CVE announcement; mainline fix commit e3f33b0a1d89; Debian DSA-6568-1; Anthropic, “Discovering and exploiting vulnerabilities… with Claude” (2026-10-27, claims not independently verified).
CVE-2026-98432 is a use-after-free in the Linux kernel’s IPv4 TCP connection-setup path. When a TCP connection completes, tcp_v4_syn_recv_sock() transfers the pending request socket’s IP options (ireq_opt) to the new child socket without copying them. A second CPU answering a retransmitted SYN for the same request can still read those options while building a SYNACK (ip_options_build()), but the socket destructors free them with a plain kfree() instead of deferring the free past an RCU grace period. The result is a use-after-free of socket-option memory. A related variant exists on the request-socket migration path.
The flaw was introduced in Linux 4.4 and affects all later kernels until patched. IPv6 is not affected by the primary issue. The fix changes the two frees (inet_sock_destruct() and tcp_v4_reqsk_destructor()) to kfree_rcu().
The defect originates upstream, but the kernel is an integral, non-replaceable component of the appliance: customers run the kernel TrueNAS ships and cannot substitute their own. We therefore treat this as a TrueNAS vulnerability for all practical purposes, and it is remediated only by a TrueNAS release carrying a fixed kernel.
TrueNAS SCALE ships and maintains the Linux kernel as part of the appliance, so any unpatched SCALE build carries this bug and only a TrueNAS release fixes it. TrueNAS CORE is FreeBSD-based and does not contain this code; it is not affected.
We verified each SCALE kernel train at the source level (whether the two frees use kfree() or kfree_rcu()):
| Train | Kernel | Status |
|---|---|---|
| 25.10.7 and earlier | 6.12.105 | Affected |
| 25.10.8 | 6.12.113 | Fixed |
| 26.0.0-RC.1 | 6.18.52 | Affected |
| 26.0 (forthcoming GA) | ≥ 6.18.56 required | Fixed once rebased |
In-field 25.10.7 and earlier are affected; the fix is already present in 25.10.8. The 26.0.0 release candidate ships a pre-fix 6.18.52 kernel; 26.0.0 GA must be built on kernel 6.18.56 or later, which contains the fix.
Only the IPv4 path is affected. The bug is in the kernel’s handling of inbound TCP connections, so it concerns TrueNAS as a server: the appliance listens on many TCP ports (management UI, SSH, SMB, NFS, iSCSI, and others), any of which exercises the vulnerable code when a connection is set up.
The bug is remotely reachable and requires no authentication, which is why the kernel CVE team scores it 9.8. On a default TrueNAS deployment, however, reaching it depends on conditions that materially narrow the practical risk. There are three trigger paths:
- IPv4 IP options in the SYN (Record Route or Timestamp). This is the applicable path for TrueNAS, but packets carrying IPv4 options are frequently dropped by routers and firewalls, so in practice an attacker generally needs an on-path or network-adjacent position (same segment, a controlled gateway, or an L3 path that preserves IP options) rather than an arbitrary Internet location.
- Request-socket migration (
net.ipv4.tcp_migrate_req=1, or aBPF_SK_REUSEPORT_SELECT_OR_MIGRATEprogram). This is not a vector on TrueNAS:tcp_migrate_reqis left at its default of 0 and no such program is loaded. - MPTCP listeners. Also not a vector by default: although the kernel is built with MPTCP support, a socket only uses MPTCP if the application opens it with
IPPROTO_MPTCP, and TrueNAS services use plain TCP. (Note: software built with Go 1.24+ may enable MPTCP on listeners by default; this does not apply to TrueNAS’s core services, which are C and Python.)
Because it is a race, exploitation is probabilistic; failed attempts terminate only the connection involved, so an attacker can retry.
Public reporting of “remote root” originates from an unpublished, AI-assisted proof-of-concept (Anthropic, 2026-10-27) that targeted a server configured with an MPTCP listener and chained a kernel-memory disclosure with a control-flow takeover. That result has not been independently verified, and its MPTCP precondition does not hold for a default TrueNAS system. As of this writing the CVE is not in the CISA KEV catalog, no public exploit code is available, and no in-the-wild exploitation has been reported.
Realistic impact on TrueNAS ranges from a remote kernel crash (denial of service) to potential kernel-memory disclosure or corruption, with the strongest outcomes requiring both an on-path position and the ability to deliver IP-options packets to the appliance. The risk is low on an isolated, trusted management or storage network and higher where TrueNAS TCP services are reachable across untrusted or adjacent segments.
Primary (recommended): Run a fixed kernel.
- 25.10: upgrade to 25.10.8 (kernel 6.12.113) and reboot into the new kernel. 25.10.7 and earlier remain affected until upgraded.
- 26.0: the forthcoming GA must be built on kernel 6.18.56 or later; the 26.0.0 release candidate is affected.
Defense-in-depth (not a substitute for patching):
- Keep TrueNAS management and storage (iSCSI/NVMe-oF) interfaces on trusted, segmented networks, away from untrusted clients.
- Confirm
net.ipv4.tcp_migrate_reqis0(default) and that no reuseport-migrate eBPF program is loaded. - Do not run MPTCP listeners on the appliance.
- Where supported by edge equipment, drop inbound IPv4 packets carrying Record Route or Timestamp options. This narrows the exposure but is untested as a complete block and is not vendor-confirmed.
Detection: Kernel crash traces referencing ip_options_build, ip_build_and_send_pkt, or skb_under_panic may indicate attempted exploitation. The absence of such crashes does not prove a system is unaffected.
The fix is incorporated in TrueNAS SCALE 25.10.8 (Linux 6.12.113). TrueNAS 26.0 will carry the fix once its kernel is rebased to 6.18.56 or later; the 26.0.0 release candidate is affected. TrueNAS CORE is not affected. This statement will be updated as fixed releases ship.