- What happened: a use-after-free in Linux IPv4 TCP (CVE-2026-98432) now has vendor fixes shipping.
- Who is affected: kernels back to 4.4, per the CSA research note.
- What to do now: install your vendor’s fixed kernel and reboot; mitigations only narrow the path.
- Interview angle: memory safety, race conditions and RCU.
CVE-2026-98432 is a use-after-free race in the Linux kernel’s IPv4 TCP handshake code. A retransmitted SYN can make the kernel read freed connection options. Upstream fixed it with an RCU-delayed free. Patch your kernel and reboot, and verify against your vendor’s advisory.
A use-after-free is a memory-safety bug where a program keeps using a pointer after its memory was released. The memory may be reused for something else, so the program reads or writes data it does not own. In the kernel, that can break the boundary between a network packet and full system control.
What changed and who is affected?
The Linux kernel CNA published the CVE on October 15, 2026, according to the ThreatDefence advisory, which was updated on November 5. Red Hat’s tracking bug was last modified on November 4, and lists errata for RHEL 8, 9 and 10. The bug dates to kernel 4.4, per the CSA note.
Severity ratings differ by vendor. The CSA note records a 9.8 from the kernel CNA, 8.1 from Oracle, SUSE and Amazon, and a Red Hat rating that moved to Critical. That spread is a useful reminder that a CVSS number is a vendor judgement, not a measurement.
| Distribution | Fixed version | Source |
|---|---|---|
| Debian bookworm | 6.1.190-1 | Debian tracker |
| Debian bookworm (linux-6.12) | 6.12.113-1~deb12u1 | Debian tracker |
| Upstream stable | 6.1.190, 6.6.159, 6.12.113, 6.18.56 | ThreatDefence |
| RHEL 9.8 | 5.14.0-687.64.1.el9_8 | ThreatDefence |
| Ubuntu | Fixed kernels in -proposed; no release yet | ThreatDefence |
Exploitation status needs care. The CSA note says Anthropic reported an AI-built exploit chain, but that the specific claims were not independently verified. It reports no in-the-wild exploitation. ThreatDefence adds that the CVE is not in CISA KEV as of November 5, though scanning for MPTCP listeners has been reported since November 2.
How does it work?
This is explained at advisory level only. The Debian tracker describes freed socket options (inet_opt and ireq_opt) that another CPU can still read while building a SYN-ACK. The flow looks like this:
- A SYN arrives carrying IP options, and the listener stores them.
- The handshake completes and the child socket takes ownership of the buffer without copying it.
- The buffer is freed with a plain
kfree(). - A retransmitted SYN on another CPU builds a SYN-ACK and reads the freed options.
The Red Hat bug says the fix uses kfree_rcu() in inet_sock_destruct() and tcp_v4_reqsk_destructor(). The free now waits for a grace period, so a concurrent reader never sees released memory. IPv6 is not affected by the first issue, per the same page.
# Check the running kernel, then your vendor's fixed package
uname -r
# Debian/Ubuntu
apt list --installed 2>/dev/null | grep linux-image
# RHEL family
rpm -q kernel
# Inventory listeners (look for MPTCP use)
ss -tan state listeningWhat should developers do right now?
- Detect: inventory hosts and container nodes by kernel package, and compare against your vendor advisory rather than the version string.
- Patch: install the fixed kernel and reboot, or apply a vendor live patch, as the CSA note recommends.
- Verify: confirm the running kernel after reboot with
uname -r, and check the package changelog for the CVE ID. - Mitigate in the meantime: the CSA note describes dropping inbound IPv4 TCP packets with IP options and disabling MPTCP where unused. It says neither is sufficient alone, and the first can break some legitimate networks.
- Check Go services: the CSA note says Go 1.24 and later enable MPTCP on Linux listeners by default, so audit them.
If you run Node services behind containers, read our notes on the Node.js permission model gotchas and npm supply-chain defence layers for the wider hardening picture.
Interview questions this update prepares you for
These are questions you should be ready for, based on the concepts behind this CVE.
What is a use-after-free and why is it dangerous?
A use-after-free happens when code keeps using a pointer after the memory it points to was released. The allocator can hand that memory to something else, so reads return unrelated data and writes corrupt it. In kernel code this can leak addresses or redirect execution, which is why memory-safety bugs in C are treated as critical.
Follow-up they may ask: How does a language like Rust prevent this class of bug?
What is a race condition, and how is it different from a data race?
A race condition is any bug where the outcome depends on timing between concurrent operations. A data race is the narrower case of unsynchronised access to shared memory where at least one access is a write. This CVE is a lifetime race: one CPU frees an object while another still reads it, so correct ordering of free and read was never guaranteed.
Follow-up they may ask: Can you have a race condition without a data race?
What does RCU do, and why does a grace period fix this?
Read-Copy-Update lets readers access shared data without locks while writers defer freeing old versions. A grace period is the time until every CPU that might still hold a reference has moved past it. Freeing after that period, as the fix does with kfree_rcu(), removes the window where a reader sees freed memory.
Follow-up they may ask: What is the trade-off of RCU compared with a reader-writer lock?
Why can a patched package still show a vulnerable-looking kernel version?
Enterprise distributions backport security fixes into their existing kernel branch, so the upstream version number does not change. Scanners that compare only version strings give false positives or false negatives. The reliable source is the vendor advisory, or the changelog of the installed package.
Follow-up they may ask: How would you verify a backported fix without trusting the version string?
How would you reduce exposure while waiting for a vendor patch?
Layer controls without treating them as a fix. Filter or drop packets that carry unusual protocol options at the network edge, disable optional features you do not use, and reduce the attack surface of listeners. Then schedule the patch and reboot, because mitigations only narrow the demonstrated path.
Follow-up they may ask: What is the risk of a mitigation that breaks legitimate traffic?
The NexGismo verdict: this is a patch-and-reboot item, not a wait-and-see item. My view is that the useful lesson is the lifetime bug itself: shared objects need a clear owner, and a deferred free is cheaper than a hard-to-reproduce race. Treat every vendor severity score as one input, and read the advisory.
- CVE-2026-98432 is a use-after-free in Linux IPv4 TCP handshake code, dating to kernel 4.4.
- The upstream fix delays the free until after an RCU grace period using
kfree_rcu(). - No in-the-wild exploitation or CISA KEV listing was reported as of November 5, 2026.
- Disabling MPTCP is not sufficient alone, because the bug is in core IPv4 TCP code.
- Distributions backport fixes, so verify against the vendor advisory and not the version string.
Frequently Asked Questions
What is CVE-2026-98432?
CVE-2026-98432 is a use-after-free race in the Linux kernel’s IPv4 TCP handshake code. A retransmitted SYN can make the kernel read connection options that were already freed. It dates back to kernel 4.4, and Debian lists the upstream fix as using kfree_rcu().
Is CVE-2026-98432 exploited in the wild?
The ThreatDefence advisory reports no in-the-wild exploitation and no CISA KEV listing as of November 5, 2026. It does report scanning for MPTCP listeners since November 2, so treat patching as urgent.
Does disabling MPTCP fix CVE-2026-98432?
No. The Cloud Security Alliance note says disabling MPTCP reduces the demonstrated path but is not sufficient, because the bug is in core IPv4 TCP code. Install a fixed kernel and reboot, or apply a vendor live patch.
How do I check if my kernel is fixed?
Check your distribution’s security tracker, not the version string, because vendors backport fixes. The CSA note warns that version numbers alone mislead. Compare your installed kernel package against the vendor advisory, then reboot into it.
Kernel bugs like this are a good excuse to review how your fleet gets patched and rebooted. Pick one host, confirm its running kernel today, and write down how long the whole loop took. Follow NexGismo for more interview-ready security breakdowns.