alt Hacker NewsTCP Use-After-Free: CVE-2026-98432 / CVSS 9.8
Comments
I've been compiling a list of cybersecurity RSS feeds to build a small automation (with oversight from Hermes agent) to ping me (ntfy.sh or just Telegram) when a CVE requires my intervention (matching them to a list of services I run for clients and myself.)
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?
How are Ubuntu and RHEL not fixed? Few operating systems market themselves more as suitable for servers. What are they doing over there?
It's okay guys, the authors simply don't know how to write good C. A real C programmer would not have shipped such a basic use-after-free bug. Rust is just a crutch.
No patches for Ubuntu or red hat yet.
Everything talks about this in terms of servers, but what about desktop Linux in typical setups? Consumer modems and routers? IoT junk?
I tried to find a mitigation using a ufw filter that rejects IPv4 packets with too large headers but it didn't work. It broke something essential and I had to switch it off again. I'd be interested in hearing about a temporary mitigation using firewall rules.
At least if you’re on Amazon Web Services behind a load balancer you probably aren’t really that impacted enough to spend Halloween patching.
> 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-...
>the kernel handed those saved options from the request socket to the new connection without copying them, then freed them immediately when the connection went away, while another CPU could still be reading them to build a handshake reply.
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.
Can anyone explain how use after free results in a practical exploit?
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).
My home firewall runs Ubuntu. It doesn't accept (new) incoming packets from the internet. I don't have any IoT devices except printers, whose packets the firewall rejects, and has done since I bought them. Do I need to do anything apart from wait for the patch to become available?
> Anthropic says Claude wrote the exploit "after initial prompting," that it runs "arbitrary commands as root, without any credentials or user interaction" on servers with a multipath TCP listener, and that in its proof of concept "it takes 48 minutes to leak a kernel pointer and another five minutes to reach the shell command execution."
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.
Is OpenWRT affected? Because that would be a real fawkin problem.
Without a test-case, read POC, how do I verify if my server is affected?
In an earlier report, it said only affected is kernel 4.4, not all since. This quite dramatic now.
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.
Some previous discussion: https://news.ycombinator.com/item?id=50299182
[06:00]
The linked source spun up my fans with 100% GPU utilization. Is there some... unwelcome... script running?
2027 is going to be the year of two to three major CVEs per day.
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.
If I am reading this right, Slackware 15.0 is already fixed:
% 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/LinuxOh joy.
MikroTik routers seem affected but mitigations are available.
Watch your Linux systems for kernel updates. Reboot!
How are people finding Fil-C? It's designed to avoid things like this.
Some notes I've got about this:
- 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.