Hacker News

CVE-2026-98432: Linux TCP Use-After-Free Risk and Patch Validation(penligent.ai)

17 points by cobychapple 1 hour ago | 12 comments

[–] majorchord 29 minutes ago

Thankfully the vast majority of servers are not creating MPTCP listeners by default (that I'm aware of).

Not sure why the article doesn't mention it, but you can specifically check for MPTCP listeners using `ss -M`.

[–] drum55 16 minutes ago

https://go.dev/doc/go1.24

> ListenConfig now uses MPTCP by default on systems where it is supported (currently on Linux only).

This seems to imply basically any golang server built since February 2025 is going to be at least attempting to use it.

[–] ReDress 17 minutes ago

I fail to understand / find the gist of this article.

Article describes the technical aspects of the bug, how it got handled by different vendors...AI position on it...

But, one would always ask themselves, why did the author write this article? That part hasn't been clear to me even after going through much of the article.

[–] drum55 17 minutes ago

This is a good portion just slop, another 9000 word article that could have been a couple of paragraphs. More text doesn't mean better.

[–] gnabgib 6 minutes ago

There's other coverage, this just has most of the comments now

Ubuntu (34 points, 16 hours ago, 3 comments) https://news.ycombinator.com/item?id=50287647

CVE.org (2 points, 7 hours ago) https://news.ycombinator.com/item?id=50295879

GoogleGroups (slight tangent) Go programs enable MPTCP by default, exposing them to Linux CVE-2026-98432 (9 points, 3 hours ago, 4 comments) https://news.ycombinator.com/item?id=50298526

[–] superkuh 26 minutes ago

Would dropping these specialized ipv4 syn packets with extra header size beyond 20 bytes (as indicated by options value >5) with the firewall be low enough in the order of things to mitigate the attack? Like, iptables -A INPUT -p tcp --syn -m u32 --u32 "0>>24&0xF=6:15" -j DROP ?

[–] rvz 39 minutes ago

This one is quite serious and the type of vulnerability is once again, a C style memory corruption and a race condition combined; leading to an RCE.

At this point, we seriously need to discuss whether if the major projects still written in C such as Linux, Chromium and even git can even handle the stream of now near infinite bugs being discovered with AI.

Attackers are already rapidly finding and building exploits for those vulnerabilities the moment they are discovered with abliterated frontier-level models.

These sort of vulnerabilities are far to common in those projects and in the future, it will be extremely unsafe for even experts to continue using C or C++ in any way.

[–] MithrilTuxedo 20 minutes ago

I bet there's a half-life to bugs though. Bugs might be infinite over the lifespan of a project, but the rate that they are produced goes down with our ability to detect them.

A lot are being found _now_ in projects written in C because the backlog of bugs to find is mostly written in C. We haven't yet gotten to the point when we're detecting most bugs before they're released, but we will.

Things won't get worse for too long. If we haven't already surpassed it, we're approaching the point of being able to do static analysis and ensure the mathematical correctness of the most complex C programs ever written so far.

I don't use C or C++, but look how much safer it is to use C or C++ these days.

[–] spauldo 20 minutes ago

Unless someone vibecodes a new OS and convinces everyone to use it, we're stuck with what we got. Reaching feature parity with Linux and then debugging it to the point where it'd be usable is a gargantuan undertaking.

[–] worthless-trash 22 minutes ago

Leading 'maybe' to an RCE, i imagine you need to groom the heap first, unless there is something i'm missing.

Edit: also thanks for using RCE correctly, it seems to be any kind of code execution these days is considered "RCE".. boo.

[–] perching_aix 10 minutes ago

You severely underestimate humanity's goalpost moving capabilities.

The state of cope:

- models are still not intelligent, they're just like, uhh, really good semantic fuzzers! so you can just put them in the loop, they'll fuzz your code, and all is good :)

- the number of bugs is "finite", so - esp with agentic help - we'll just catch up and all will be good :)

Annoyingly, the cope frontier is kinda right about both of these, so the joke shall go on. The only real counter to it would be to bring up that this finiteness claim only really applies to a frozen set of security boundaries and attack surfaces, but they'll probably just raise this being "an academic tier concern" and just tell you to ""fuzz"" more.

So ironically, it looks like these practices are rescued once again, and the bare minimum stays winning.

From the horse's mouth, in case you were suspecting these descriptions to be in bad faith: https://www.youtube.com/watch?v=NnV_cWeoo5Q

[–] the_dev_stack 15 minutes ago

Pattern worth flagging: this is the second kernel UAF in a packet-handling subsystem to hit the news this cycle — the recent PHP2Shell chain used an XFRM ESP-in-TCP UAF to escalate from www-data to root. Both bugs sit on the "mark-then-free" side of the race (SOCK_DEAD-bit-equivalent patterns).

On patch validation specifically: the right smoke test is a reproducer that FAILS without the mark being set, not "no crash in syzkaller for N hours." Those are different quality bars, and the article doesn't address which one this patch cleared.