I 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.
- 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.
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.
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.
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?
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).
> 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.
>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.
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?
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.
There are microkernel operating systems out there that run the network stack in isolated, unprivileged contexts. Some of them are even not written in C.
The most terrifying part of this is all the devices that might be affected. Ignore servers and desktops. Linux 4.4 came out nearly 11 years ago. While most Linux devices' firmware is actually more ancient than that (Linux 2.x and 3.x isn't uncommon), any device that did ship with Linux 4.4+ is going to get hacked, because nobody patches those devices. Any smart device in the world that isn't a server, desktop, or microcontroller, is probably running Linux.
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.
(These fines are tiny compared to the fines for things like fire code violations, but enough money that a company, contractor, or individual would rather fix their device than pay the fines)
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.
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).
Finally a usecase for mptcp on linux. Been waiting and trying off and on for years to get it to do something, but now it can give a nice remote root shell. Well, not to me, I just get to patch devices.
> TCP Use-After-Free: CVE-2026-98432 / CVSS 9.8
I 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.
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.
How are Ubuntu and RHEL not fixed? Few operating systems market themselves more as suitable for servers. What are they doing over there?
No patches for Ubuntu or red hat yet.
https://ubuntu.com/security/CVE-2026-98432
https://access.redhat.com/security/cve/cve-2026-98432
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.
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-...
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?
Everything talks about this in terms of servers, but what about desktop Linux in typical setups? Consumer modems and routers? IoT junk?
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).
> 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.
I suppose I'm not the only one feeling worn out by this tidal wave of vulnerabilities that I somehow have to keep up to?
Fixed upstream in:[1]
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)
god this page could hardly be more ai generated if it tried
actual link: https://nvd.nist.gov/vuln/detail/cve-2026-98432
I am surprised formal verification efforts of the Linux kernel didn’t find this. Any experts care to chime in?
>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.
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?
Is OpenWRT affected? Because that would be a real fawkin problem.
What is a "multipath TCP listener"?
If you’re on Ubuntu you can upgrade by pulling the -43 version from the -proposed repo. Crazy they still havent shipped it to -stable.
Without a test-case, read POC, how do I verify if my server is affected?
Some previous discussion: https://news.ycombinator.com/item?id=50299182
The linked source spun up my fans with 100% GPU utilization. Is there some... unwelcome... script running?
I was sorely tempted to fully bypass the kernel for networking before, and this isn't exactly giving me warm fuzzies for staying.
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.
What does this enable an attacker to do exactly? RCE? DoS? Unknown?
If you run a custom kernel chances are you're not affected:
# CONFIG_MPTCP is not set
MikroTik routers seem affected but mitigations are available.
Watch your Linux systems for kernel updates. Reboot!
Who wrote the bug? Very likely someone at Redhat.
Is Traefik affected?
There are microkernel operating systems out there that run the network stack in isolated, unprivileged contexts. Some of them are even not written in C.
The most terrifying part of this is all the devices that might be affected. Ignore servers and desktops. Linux 4.4 came out nearly 11 years ago. While most Linux devices' firmware is actually more ancient than that (Linux 2.x and 3.x isn't uncommon), any device that did ship with Linux 4.4+ is going to get hacked, because nobody patches those devices. Any smart device in the world that isn't a server, desktop, or microcontroller, is probably running Linux.
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:
(These fines are tiny compared to the fines for things like fire code violations, but enough money that a company, contractor, or individual would rather fix their device than pay the fines)If I am reading this right, Slackware 15.0 is already fixed:
Oh joy.
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.
[06:00]
Let me guess... The bug is in C code?
(reading TFA)
Ah yup.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).
How are people finding Fil-C? It's designed to avoid things like this.
Finally a usecase for mptcp on linux. Been waiting and trying off and on for years to get it to do something, but now it can give a nice remote root shell. Well, not to me, I just get to patch devices.
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.