TCP Use-After-Free: CVE-2026-98432 / CVSS 9.8

> 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

>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.

I am surprised formal verification efforts of the Linux kernel didn’t find this. Any experts care to chime in?

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"?

Without a test-case, read POC, how do I verify if my server is affected?

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.

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!

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.

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:

  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)

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/Linux

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]

[dead]

[dead]

Let me guess... The bug is in C code?

(reading TFA)

    net/ipv4/af_inet.c
    net/ipv4/tcp_ipv4.c

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.

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.