TCP Use-After-Free: CVE-2026-98432 / CVSS 9.8
https://atlasum.net/blog/cve-2026-98432-linux-ipv4-tcp-uafI know it's customary for HN to edit titles to remove extraneous information, but removing "Linux" here really takes away something useful and relevant. This is a Linux vulnerability. If you're running *BSD or Mac or Windows, not affected.
"Why it's urgent: the bug sits in code every Linux server runs when it accepts an IPv4 TCP connection, before any application sees the connection. Anthropic, whose researcher reported it, says its Claude model wrote a working proof-of-concept exploit that runs commands as root on "Linux servers with a multipath TCP listener," with no credentials. Go programs open those listeners by default, per the Go Security Team. See the timeline."
I don't know of any Linux boxes running a multipath TCP listener in my care and I have quite a few. MP generally implies a router of some sort and the intersections in a Venn diagram continue to get smaller ...
This is still an issue and must be patched but I think it will be rare, very rare.
1: https://groups.google.com/g/golang-announce/c/PCoQcdxoScw
- MPTCP is not a requirement, it is a generic use-after-free.
- Exploitability over the internet is unlikely, most ISP routers drop packets with IP options fields.
- At least according to Red Hat, dropping packets with IP options yourself helps, but is not a full mitigation.
- Successful exploit requires multiple CPU cores to process packets, so systems with just a single core or packet processing pinned to a single core are not affected.
For years, Red Hat employed more kernel developers than anyone and contributed more. These days they're "only" the fourth largest contributor, after Intel, Google, and Meta, but they are still among the largest corporate contributors.
If that's a lean kernel org, I don't know what a fat one would look like.
> AWS Web Application Firewall, Application Load Balancer, Classic Load Balancer, TLS Listeners on Network Load Balancer, Cloud Front, API Gateway
> Customers using the above services do not receive TCP connections from untrusted sources directly when following best practices. AWS is applying updates to the underlying infrastructure of these services and no immediate customer action is required if you are using these services. We still recommend customers update their self-managed instances behind these services within the next 30 days.
[0]: https://aws.amazon.com/security/security-bulletins/2026-160-...
My list (of feeds) is still small, but this CVE did not show up, do any of you have any tips for RSS feeds to use for this purpose?
I ask because I’ve been dabbling in rooting various closed devices at home. I’m finding AI fantastic at finding vulnerabilities statically (from firmware upgrade binaries), but when you then ask it to use it to get root or code execution it just goes in circles.
In the end it usually ends up there’s no exploit it can find, because it can’t actually influence the affected memory in a useful way. This is especially so if that memory is in the heap. On the stack it’s a lot more predictable (especially with OOB writes).
This is wild. I'm a firmware nerd, not a backend nerd, what percentage of TCP/IP servers are 'multipath'?
Also, since IPv6 isn't affected, wouldn't it be funny if this is what it took to get everyone to switch.
7.3 (2026-10-18)
7.2.10 (2026-10-11)
6.18.56 (2026-10-11)
6.12.113 (2026-10-15)
6.6.159 (2026-10-15)
6.1.190 (2026-10-15)
5.15.225 (2026-10-15)
[1] https://lore.kernel.org/all/?q=tcp_v4_reqsk_destructor -- check for "kfree_rcu" being used instead of "kfree" within "tcp_v4_reqsk_destructor" (net/ipv4/tcp_ipv4.c)
actual link: https://nvd.nist.gov/vuln/detail/cve-2026-98432
If this requires a multi-core system to exploit, it's good news for most of the consumer routers that will never get updates. Saved by cheap single-core hardware.
The discourse on this is weird, sounds at times as if these are “because of AI.” These are mostly pre-existing bugs, some very old, and they’ve been lurking. If they all get found we exit the other side more secure and reliable.
# CONFIG_MPTCP is not set
Watch your Linux systems for kernel updates. Reboot!
As part of the Software Building Code (that we don't have, and desperately need), one of the things we should have is mitigation for these abandoned internet safety risks. Here's how I would define that section:
Section 4 Connections to Public Internet
Section 4.1 Device Support
Devices connected to the public internet WILL require one of the following:
a) Guaranteed LTS support for a minimum of 10 years
b) Guaranteed rolling release support for a minimum of 10 years
Devices without this support are not permitted to be connected to the public internet.
Section 4.2 Vendor Responsibility
When releasing devices, vendors must determine whether this device is certified for
public internet use. Support must be maintained according to S4.1. Failure to comply will
result in fines of up to $5,000 per affected device.
Section 4.3 Installer Responsibility
Any device connected to the public internet which is not certified for public internet
use is in violation, and will be subject to fines of up to $500 per affected device.
Section 4.4 Device Owner Responsibility
Any installed devices will be replaced once they reach their End Of Life period,
or after 10 years, whichever comes first. Installed devices in use that exceed this
period are in violation, and subject to fines of up to $250 per affected device.
% uname -a
Linux XXXX 5.15.223 #1 SMP PREEMPT Thu Oct 22 00:03:07 CDT 2026
x86_64 Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz GenuineIntel GNU/Linux(reading TFA)
net/ipv4/af_inet.c
net/ipv4/tcp_ipv4.c
And moreover it's a security issue found by LLMs.
It's kinda a really bad time to be a C-loving, AI-hating, fanboi.
Do we at least entertain the idea that some rewrites of some things in safer languages could be a desirable goal? (not saying it's practical or not: just asking if C lovers are willing to reflect a bit on what's going on atm).
I see. https://nvd.nist.gov/vuln/detail/cve-2026-98432 affected versions format is the culprit. Entirely unusable. We do have versions, branch names and tags for a reason.