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.
"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.
This is not rare. Every TCP connection in Go by default enables MPTCP [1]. Simply running a Go program that uses TCP without explicitly disabling this behavior will cause the running kernel to be vulnerable.
MPTCP doesn’t use any specific ports. It’s an OSI layer higher than that. It’s part of the TCP protocol itself. So if your firewall routes TCP traffic of a specific port (eg HTTP) already then it’ll route MPTCP along with it too.
MPTCP is a protocol extension that requires cooperation by both peers and all middleboxes. So, if there is a Layer 7 firewall, or DPI/SPI, or TLS termination on the path, and it's not inclined to preserve the MPTCP options, then MPTCP will be disabled.
Firewalls do not operate at layer 7 nor do TLS termination.
What you’re thinking of is load balancers. Most of them will do TLS termination. But there’s also plenty of load balancing solutions out there that will forward the raw TCP traffic (AWS NLB, DNS based solutions, and so forth).
But it’s also worth noting that this vulnerability doesn’t explicitly need MPTCP. Just the POC exploit uses that.
Wait. So; just because you've studied with someone makes your opinion correct? Damn. I wish I would have known that long ago! In both my education tracts of medicine and CS, I've studied with some pretty great minds and I could have been passing off my opinion as fact for decades now.
I wish I would have received that memo. </sarcasm>
It seems like the anthropic PoC involves MPTCP, but the bug itself is not in the MPTCP code, it's in a generic TCP codepath relating to options, MPTCP was probably just a convenient codepath for memory manipulation.
> The Go team adds that "the underlying bug is not specific to MPTCP. It is possible that systems with no MPTCP listeners are vulnerable to similar attacks"
MPTCP is only required for the known exploit, it isn't necessarily needed.
- 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.
There are two types of multipath TCP and they are not at all the same.
What Apple does is, for example, being able to have a connection over WiFi and 5G simultaneously, with different IPs and routes.
The more traditional server side multipath is that you have a network card with 4 ports (eg 4x 25gbit) and connect them to a router, and make those 4 physical ports (paths) behave like a single interface. This helps either load balancing or redundancy.
And it takes around an hour to do this in lab setting locally:
> An enabling property of this race condition is that a lost race only fails the handshake without crashing the whole system, so a determined attacker can retry indefinitely until they succeed. In our proof of concept, it takes 48 minutes to leak a kernel pointer and another five minutes to reach the shell command execution
Tragically not enough people drop IP options. I did it in the early 2000s for a very large US network and was glad. There's lots of obvious reasons as they're generally an old school ddos path to knock out routers (get punted to the RE/RP exception path, a good way to bypass some loopback/routing engine acls if folks don't filter it right). Every few years some academics pop up with let's use IP options because we can stuff more bullshit in the datagram - it's always a bad idea.
Eh, this is why networks ossify and we can’t have nice things like a maintained connection when switching from home wifi to 5G. MPTCP is important, eg Siri uses it I believe?
One can also monitor for it in nftables. This is from my raw table:
grep CVE /etc/nftables.nft
# Options CVE
iifname "eth0" ip daddr $ADDR4 meta l4proto tcp ip hdrlength gt 5 counter log prefix "CVE-2026-98432: " level debug
Once confident nothing legit would be blocked by dropping the packets one can change "log prefix "CVE-2026-98432: " level debug" to "drop" if on an unpatched kernel.
$ADDR4 in my case in my internet facing interface.
For more on why MPTCP is not relevant--my limited understanding is the issue is with SYN retransmits.
SYN packet #1 is received and added to a request queue for processing.
SYN packet #2 is received and is a retransmit of SYN packet #1. It is matched to SYN packet #1 already in the request queue and now there is shared state between both SYN packets #1 and #2 in the request queue.
CPU #1 takes on the task of processing SYN packet #1.
CPU #2 takes on the task of processing SYN packet #2.
CPU #1 responds back with RST packet #1 (e.g. requested TCP port is not open) and _should_ defer the destruction of the request socket for SYN packet #1, as other CPUs may still be processing the shared state for the request socket as is the case for retransmitted SYN packets.[1] However, this deferred destruction wasn't occurring, and CPU #1 was _immediately_ destroying the request socket/shared state for SYN packet #1.
CPU #2 races with CPU #1 and reads from the request socket/shared state for SYN packet #1 after its _immediate_ destruction by CPU #1.
Linux's IPv6 handling is unaffected because in this IPv6 scenario, there is no shared state between SYN packets #1 and #2 in the request queue. Instead, each request socket has duplicate data.
Someone more knowledgeable can confirm/correct me on the above please.
The use-after-free occurs within ip_options_build (net/ipv4/ip_options.c) which CPU #2 processing the retransmitted SYN packet uses to read/copy options out of the unallocated/reallocated memory that CPU #1 had already freed up. Remember that the options header is variable length too so CPU #2 is seemingly under-reading/over-reading this variable length options header by some fairly random amount between 1-256 bytes depending on what data has been written to the reallocated memory.[1]
The undocumented part (per LKML discussions at least) is what happens next in the attack. Seemingly CPU #2 or CPU #3[2] comes along later to process the random jibberish options header and rarely (in Anthropic's case it took 48min locally) that random jibberish will be returned to the attacker (e.g. copy jibberish options header to a response packet?) and it'll expose a return pointer to a fixed kernel function. The attacker then crafts a SYN packet and retransmits it with an options header that places a return pointer in the right place, and hopes for another race to occur where CPU #3[2] executes a callback to an attacker-controlled pointer stored within the options header data. Anthrophic's case said it took 5min for this stage of the attack to work locally.
Someone will probably write this all up at some point and it'll be quite a long and detailed read of how the 48min and 5min stages of the attack work and perhaps this is where MPTCP code paths are involved due to the way they process the TCP options header data.
Here are my notes so far after digging into this with Claude + defensive access:
1. Not just an MPTCP thing - any received IPv4 packet with options creates the problematic conditions.
2. Also appears that using NetLabel/CIPSO (SELinux or Smack with a CIPSOV4 mapping) creates the same conditions that a packet with IP options would. If you're using these, it might mean that dropping IPv4 packets with IP options might not fully mitigate.
3. At least for our test VMs in Azure (accelerated networking) I wasn't able to get any IPv4 packets with options through, from three different US-based ISPs. Unfortunately Microsoft publishes no docs on whether the fabric drops this or not, so YMMV.
We're using a simple XDP program to mitigate until a patched kernel is available (thanks @tptacek for the idea):
Claude suggested this nftables-ipopt config + systemd unit to survive reboot will also fix the issue. Can anyone comment whether this is early enough in the stack to also solve this?
cat > /etc/nftables-ipopt.nft <<'EOF'
table inet ipopt {
chain pre {
type filter hook prerouting priority raw - 10; policy accept;
ip hdrlength != 5 counter drop
}
}
EOF
Also couldn't get IPv4 packets with options through between Hetzner cloud servers (different networks), but it's no guarantee.
If you read commit logs of, say kernel.org and a distro kernel, and aren't concerned you are blissfully ignorant (and it is worse for the broader userland repos). It's particularly bad when they don't track a kernel.org LTS. Their kernel orgs are pretty lean and this has been the status quo for decades. CVEs of sufficient stature like this will get fixed but majority of other issues slip by unnoticed. LTS is kind of a myth, it trades ABI and API stability for a lot of other issues.
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.
My hearsay, from friends and colleagues that work(ed) there, is that the shipped product is not really where you see these "heavy hitters".. a lot of the maintenance happens offshore.
The Noble 6.8.0 LTS kernel is a mess. Im not sure what we are going to do in our org. We have been discussing it for a few months. I want an in house fork based on an GKH LTS but others are hesitant to take on that level of responsibility.
Regardless of the OS, kernel, or program you select there will inevitably be holes in your stack. A VM will always provide better isolation and more flexibility. In this instance it would mean being able to patch the box running the service without messing with the driver for the backing storage.
Depends on the VM system. Full blown virtualization add complexity and attack surface. Running vmless[0] could be even better if you trust the design of the isolation enough.
Anything important should be virtualised and regularly snapshotted. Nothing is invulnerable but if it can be reconstituted in an hour, that’s close enough. If it isn’t and you care enough then a standby server with failover should take care of it.
I have found that Debian BPO kernel + BPO ZFS works well, and since ZFS gives you complete snapshotting capability a broken upgrade isn't as much of an issue, rolling back with zfsbootmenu is easy.
What usually happens to me is that I run a full package update, forget about it for a while, and then reboot. And then the server doesn't come back online - and I'm not in front of it to fix it.
LTS kernel pretty much solved this issue for me when I switched.
Over the past few months I've started to install newer ubuntu kernels using the mainline PPA. However, it goes long periods of time without getting updates, so it's not really a satisfactory solution. In one case I just built the kernel myself.
LTS doesn't work if you want immediate fixes like the current environment requires.
Given the current and rapidly upcoming environment, would that not imply that those are no longer viable choices? As like a fairly urgent emergency consideration?
If they cannot demonstate being systematically able to adapt towards the required reaction time (minutes? hours?) by almost-comically many orders of magnitude (multiple weeks), and it is only going to get worse, then what other conclusion could there be?
Like they'll only organizationally adapt when it's far too late (everybody using their shit has already been pwned), and then it'll be an unpracticed emergency adaptation.
No, they are providing a service, LTS, that customers still want and pay for. Only once the customers realise its not a workable product and they want a rolling update product, with all the changes that implies, will this change.
They pull from Debian unstable every 6 months and that's it. Afterward, changes made in Debian mean nothing to Ubuntu.
Don't trust Ubuntu's LTS promises, either. Most of the modern packages you care about are in universe, which almost never gets patched after the initial release.
I think they deliberately leave the free LTS version insecure in order to sell Pro licenses. But guess what, even Pro doesn't get timely patches.
I’m pretty confused because apparently Anthropic is the group that followed “responsible disclosure” but apparently even though upstream was patched a couple weeks ago, still nothing on either.
I'd be seriously considering Debian or, hear me out, NixOS. We run all our work servers on Ubuntu, but ~6 months ago I switched my workstation to NixOS and I couldn't be happier. I've been following "latest" or whatever they call it, being able to treat the OS package versions like the rest of our software (update the flake.lock file and then burn it in in dev+stg for ~2 weeks before rolling to prod) is pretty attractive.
to be fair their storage, and I mean their SANs, is still the best (excluding very expensive alternatives that are only really beating IBM in few limited scenarios).
I still like DB2, but only for banking/finance core stuff, and their mainframes are just unique machines, I'm very fond of them.
I don't think I can recall an instance where there was an issue this bad (a box being vulnerable just by virtue of being connected to the internet, or exposing nothing other than ssh) and I didn't have timely patches for it. I had to turn off my server and home automation system because of this. Really not acceptable at all and makes me want to switch everything to debian.
Going by the proxmox forum the fix is already in the sources (proxmox released their kernel based on them a few days ago). But I could not see, if it is already released for the users.
Yes, we (Proxmox) included the fix for this in 7.0.14-25, which was initially packaged two weeks ago.
It went through internal QA and to the test soon after that, then a few days later to the no-subscription repository and as of yesterday morning CET it was cleared for the enterprise one, so it's available on all repos of all Products we got in their current supported releases.
For kernel updates we where even more conservative in the past, but with the current churn on often quite relevant fixes picked up the pace a bit on moving them along, trying still to balance rolling out fixes fast(er) while not doing that so fast that tricky (hardware/setup specific) regressions don't get caught.
edit: As this makes the rounds we also released a PSA for it now [0] to make our status here easier to find.
Interestingly, Ubuntu Priority is set to "High" and not "Critical" which is defined as:
"A significant problem, typically exploitable for nearly all users in a default installation of Ubuntu. Includes serious remote denial of service, local root privilege escalations, local data theft, and data loss."
The listed kernels are in the "proposed" component (and not yet in "security" or "udpates") if you want to pull them down onto canary systems for testing before going to production.
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.
The fallacy is the idea that a Rust implementation would automatically achieve the same performance, and not resort to "unsafe" to be competitive, and then be open to exactly the same issues.
Conceptually, there is not really anything much simpler than a matrix transpose. So how did they manage to create a bug? To make it fast you need simd, which implied using unsafe, and the dimension check to make it safe used unsigned integers that could wrap around. So they same bullshit as in C.
> To make it fast you need simd, which implied using unsafe
Is just false. There are multiple safe SIMD libraries for Rust that can exploit the full SIMD potential. Only very rarely they require unsafe for maximum performance and only to avoid bound checks.
Counterpoint, more than memory bugs exist, and everything's written in C. You're welcome to rewrite in Rust but you'll create countless bugs that aren't memory bugs that mostly already got fixed in the C version. I can't help but think things like fil-C are the most pragmatic route, despite performance costs, for most people relying on programs written in C.
Yes, you'd introduce a lot of new bugs because the code is newly written[1], but eventually you'll get to the same maturity as today except you can't have all these devastating memory-handling-related vulnerabilities
The question is whether your software will be in use long enough to be worth the cost of change more than whether it's a good idea in the long run. For Linux, I'd argue that that's likely. At least new code would ideally be contributed in a safe language, where practically possible (there'll surely be places where you need to deal with memory as a kernel)
Relevant article: reducing memory vulnerabilities through a combination of memory-safe languages and an exponential decrease of bugs as existing code ages https://security.googleblog.com/2024/09/eliminating-memory-s..., from which I'll also quote my reference for [1]: "A large-scale study of vulnerability lifetimes published in 2022 in Usenix Security [...] found that the vast majority of vulnerabilities reside in new or recently modified code"
This is a dumb argument imo. Critical vulnerabilities are mostly due to memory bugs (and not for a lack of other kinds of bugs). Most people relying on programs written in C (or even C++) should consider plans for migrating to software created with toolchains from this century. You cannot indefinitely carry on this tech debt.
Here are some CVEs identified in Rust coreutils [1]. These are mostly really trivial issues. I'd bet money that the nastier logic bugs are still in there and that the people who maintained the old C utils or helped identify the old bugs can find similar ones in these utils, although half these issues probably never appeared in the C version because Rust is much more complicated than C so makes it easier to hide logic bugs in plain site, looking at many of the issues in this article they seem like bugs that are extremely unlikely to get written in C, like accidentally forcing everything to be UTF-8, or aborting on routine errors.
I strongly disagree with the idea that Rust makes it easier to hide logic bugs. Rust is a much more complicated system than C but allows software engineers to work at a much higher level of abstraction which generally reduces logic bugs. Of course, new projects will inherently have bugs but with Rust it is easier to achieve a higher level of rigor.
To be clear, this is not due to the borrow checker at all, Rust does not have the tooling to statically determine the absence of logic bugs. What it has is the necessary programming language features to manage much more complex systems through abstraction and modeling.
At least it doesn't silently launch nuclear rockets, smaller bugs are manageable, like accidentally forcing everything to be UTF-8 is basically nothingburger.
One issue with this argument is that, almost everything is memory, especially in C. It's not really descriptive. If you write a reactionary language like Rust, it may be possible that you just fix one type of issue (with an error type taxonomy that's not very refined), and end up with a language that does not necessarily cause less bugs and vulns, but that causes less vulns that can be classified as that type of issue, while increasing other types of bugs/vulns, either of an existing type, or of a new type that only exists in that new language.
Like are we empirically seeing less Rust CVEs? Adjusted for popularity of software and perhaps age of software.
Are you saying by attempting to reduce certain types of bug category such as memory safety, other types of vulns would suddenly be increased because of it? It sounds to me like you are saying we shouldn't treat common cold because cancer rates might increase. And what do you mean by reactionary?
> It sounds to me like you are saying we shouldn't treat common cold because cancer rates might increase
surprisingly that’s almost not a strawman, I’d support an argument like that, and it’s how medicine works
if a cancer treatment is discovered, it needs to be trialled for side effects, and actually chemotherapy can have side effects that are worse than the cancer, it’s entirely possible for chemo to weaken the immune system and thus increase colds.
so hillariously, yes, that’s almost what I’m saying. but to be precise I’m not saying we shouldn’t cure cancer or solve bugs, just saying that solving one kind of issue doesn’t prove the tech is beneficial overall, and the more generic the problem being solved, the more likely the panacea will fail or have side effects
I'm not suggesting anything like "rewrite in Rust", at least not in general. I'm simply poking at the fact that use-after-free (and other such issues) are effectively deprecated classes of bugs.
> I wouldn’t be surprised if we start seeing individual drivers and subsystems move over.
Already happening. https://lwn.net/SubscriberLink/1102982/c3a3a2d4f17108c5/ "Removing binder.c" is an article from yesterday, about discarding the old C implementation of the Android Binder driver (used by every single Android phone) in favor of its Rust reimplementation.
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 blocked packets arriving externally on my firewall with ip-options a couple of days ago. Firewall rule has zero hits, and I've got a very open ISP (andrews+arnold), if I want I can host SMTP, DNS, whatever
I switched to OPNsense last week. Consumer grade WiFi AP is behind it. I’m not depending on firmware updates from a company that has no incentive to make them.
For some reason the submission I saw here last week (not the same article, and I'm struggling to find now) was flagged to death before getting as popular as this one.
My FreeBSD loadbalancers block packets with IP Options with default config. It’s not rocket science, no matter how Cloud providers are trying to tell us.
So, the good news is that I can probably now get root on almost any Linux-based device I own. Don't even need to solder on a serial port or w/e, just direct network connection.
Yeah this is really a blessing for people seeking more control over nice hardware with horrible software, "smart" spy TVs, Android (moar ads on your) TV boxes, cheap insecure security camera's with only Crappy Cloud subscriptions... Go AI!
Dual or quad core is not that unusual even in very cheap SoCs, but this particular CVE needs a kernel line from this decade. Thousands of other CVEs indeed..
Was going to say that, depending on the device's age, this law may apply, where article 13 sub 9 specifies a decade of updates is the minimum: https://eur-lex.europa.eu/eli/reg/2024/2847/oj
But then it turns out that this "applies from" late 2027 :/
Simultaneously Wikipedia says the Act has "entered into force" in 2024. Does anyone know the difference between "enters into force" and "applies"? Is it like this 2016–2018 grace period for GDPR where it was "law" but not enforced? (The wording sounds backwards if it's that, but I'm not a native speaker)
That's how i'd read it but i'm not 100% sure. legal terms can have specific meanings in a legal context that's different from general use.
but also this is one of those cases where, ok you have a law, but, that's meaningless. It's not enforceable. It's not even monitorable. It's nice in theory to write down a bunch of regulations but at best you can make a bunch of EU companies do some paperwork. anything imported from outside the EU, the company can agree to everything and then dissapear. ALl the direct to consumer slop on amazon and whatever. How is the EU supposed to enforce a law against a random fly by night brand name in Shenzhen?
> As volumes rise, enforcement is weakening. In 2025, the EU control rate fell to 65 items per million items imported. The rate of goods ultimately refused at the border due to non-compliance or because they posed serious risks, also fell to below 10 items per million.
> A large-scale customs investigation launched by the Commission in 2025 highlights the scale of the problem. Over 60% of checked toys, small electronics, cosmetics, personal protective equipment and food supplements bought online from outside the EU failed to meet EU product compliance and safety requirements.
> the company can agree to everything and then dissapear.
Isn't that the case for every law related to commitments? Warranty, repair parts and battery longevity is a thing now iirc... haven't had issues with that being avoided so far, at least not in this way
A huge volume of purchases (including in the EU) are direct to consumer from Amazon. There are a lot of fly by night brands on there and you'd be surprised how many of them seem to no longer exist within a year or two. Your big company backed Samsung phone might get security updates, but the IoT junk in question is not likely to.
Re battery longevity - see the power bank bans by the TSA in the US. Maybe you are getting lucky or are only purchasing products from reputable long lived regulated vendors, but the sheer volume of vulnerable devices does not come from those products
> 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.
My understanding is that an app explicitly needs to open a "multipath" socket. Go 1.24 does that by default, so does Caddy, these would be the big ones.
Anthropic only exploited multipath TCP, but the bug is deeper and also affects TCP connections, but it looks like this path is harder to exploit, and it's unclear if anybody managed to.
Thanks. Expanding exploits is something LLMs seem pretty good at so I’d expect people to manage a more general exploit soon if not already. Hopefully it’ll be patched before that happens.
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?
alright alright, what's going on? This doesn't seem to correlate with a big model release? (or does it? Claude Haiku 5.5 is in the vicinity) Is this just Anthropic/OpenAI causing this trouble by themselves to validate their existence? Is this related to Anthropic's IPO?
Maybe broad adoption is the answer? More people are starting to understand how to apply LLMs as tools, some people who previously might have been hesitant are now willing since they're seeing the benefits?
I don't know for sure, but over the past few months I've seen a bunch of skeptical people do a complete 180 and start using LLMs more actively.
_If you’d rather get messages in real time, you can subscribe to the list itself by sending an empty email to oss-security-subscribe@lists.openwall.com. Be aware that the volume is high; October 2026 alone had 460 messages._
That's also well into clanker managed territory ;) (I mean the clanker builds a small automation, no LLM involved after that, I do a lot of that, just use clanker to build, update, organize, monitor and handle edge cases.) I have used free (and therefore limited) agentmail.to for this. I find the subscription to be a bit expensive for my hobby, but it's a nice service if you do this professionally.
The good news is, if you emergency patched your Debian for php2shell, you probably got the new kernel on the same apt run. This time the embargo actually held, and the new kernel was out before the CVE came public
If AI is building all the systems and writing all the code, and AI is finding bugs and exploits in existing code and code being generated by AI... With the assumption that any code base scanned in its entirety by the latest frontier cybersecurity focused models is secure... This assumption only holds until a more advanced model is created to find bugs and exploits in the code from the now lesser advanced model... Which means even the code the top of the line model just created was never really secure...
How does this cycle get broken?? Will people ever be able to be sold the (false idea) that their devices are secure?
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).
You need to do some https://en.wikipedia.org/wiki/Heap_feng_shui. If you can reasonably reliably trigger some other operation that allocated the freed memory for another purpose, you have something like a type confusion vulnerability.
It goes around in circles because a UAF alone isn't enough in a lot of cases, sometimes you also need a chain (an info leak, read/write primitive etc), a way to defeat ASLR and so on depending on what you are working on and target mitigations. Not all UAFs can be used for RCEs, some can be used only for DoS or for nothing really.
One example is that you might be able to read what was written there. Here that may mean you could read another process’s packet(s). Imagine they were sending unencrypted passwords, perhaps because it’s in a trusted LAN connection.
If it’s freed it can be reallocated, so then you have pointers to the same area of memory used for completely different data structures, and this can go very wrong
I get the principle - what I struggle to find is concrete examples of how it can practically be used.
How do you know which pointer (as I say, especially if it’s in the heap)? And I know it can go wrong - but how do you do more than just crash the kernel?
In OOB writes in a stack variable it’s completely clear to me. For other situations I’d love to find real and clearly explained exploits of past UAF or OOB vulnerabilities.
Getting the right thing allocated in the right place to exploit a UAF is usually very very tricky. For a defender we just need to know it's probably possible and therefore we patch the bug, but the attacker still has a difficult job to do even already knowing a UAF bug.
The simplest thing you could try to do is allocate several more of the same type of object and hope one of them lands at the same memory address. For example if you can UAF a web app's user session and keep it open for a long time period (not true in the TCP bug), you might try to wait until an admin happens to log in with their session at the same address, then use their admin session.
Or you can allocate a lot of something else objects and hope a certain field overlaps, like a function pointer if you can write to it. Like suppose you can get some kind of authentication callback pointer to overlap where your packet sequence number was, maybe you can send a certain number of packets to make it point to the return instruction and skip the authentication.
One technique is to just spam the heap full of a certain object you're hoping will overlap it. E.g. if you want to affect a connection object, you might try to open one million simultaneous connections, then touch the UAF object, then check each connection to see if it got messed up. This is called heap spraying and it's often seen in JavaScript vulnerabilities, a bit less in network vulnerabilities since it's easier to allocate a million Uint8Arrays than to open a million TCP connections.
A web search for "exploit chain uaf" found me a few real-world and a few tutorial examples, though I don't know which are good.
At a high level, though: once you've gotten a new object allocated where the old one was, you now have two different views of the same bit of memory. You use valid operations on one view to put the other one into a corrupted state. For example: in a unixlike kernel, maybe one view has a field containing a function pointer (for method dispatch, essentially). You read that field using the other view, use it to deduce something about the target's memory layout, write a new value to the pointer, then use the field via the first view to cause execution to jump to a location you control.
Maybe check https://github.com/sarabpal-dev/IonStack-S22U
It has a full chain reproduction of the use-after-free vulnerability that grants you root on Samsung phones with a locked bootloader.
I don't think a UAF on its own allows control hijacking in an exploit. You will need further logic bugs or the ability to legitimately or illegitimately control memory, either via further requests / function calls, OOB writes and such. And it will always be extremely specific to the application vulnerable.
For example, I remember an exploit workshop around reuse of passwd entries. The vulnerable would validate a passwd entry for a non-root user, use it a bit, and later on free and zero it out for security purposes... except it then looked at the passwd entry again in some conditions. Suddenly, the uid was non-zero at first, and zero later on, so later decisions assumed the user was root.
In a more concurrent situation, a possible vulnerability was a shared cache of these passwd entries. It wouldn't zero them out anymore, but you could create a race condition of starting requests as user A, and then hammering requests as user B, so you'd end up mixing up the permission contexts of these users. Because the passwd entry that had been released back to the pool was overwritten, and then re-read with the value from another context.
The necessary line of thinking tends to be very different from thinking about program code regularly.
been doing exactly this lately with camera firmware and yeah the circles thing is real, but im pretty sure its a feedback loop problem, not a model problem
the model spins because it cant test its own guesses. what fixed it for me was emulating the actual device. qemu with the vendor rootfs, real binaries running, and then every claim becomes checkable: did the daemon actually parse my input, which uid is it under, what does its own log say. once it can check things it stops guessing, getting qemu to actually boot the thing was its own little hell though, took more tries than i want to admit.
the other thing i learned the hard way: most static findings die on reachability, not on exploit primitives. so i run them in the emulator first and kill the unreachable ones cheap, before spending any time on heap work
on heap vs stack, i think that intuition is desktop shaped. device userland usually has weak or no mitigations, heap uafs are way more tractable there than youd expect
Good ideas on the QEMU. I guess you’d have to patch the binary if it’s expecting particular hardware etc?
Not sure what you mean by “desktop shaped”?
Can you give a concrete example of UAF on heap? I’m learning a bit on how this is done, and eventually recognised the LLM is doing something called heap spray. But that seemed to rely on hoping some object you wrote just happened to get interpreted by some process. And that was the “no, wait, pointer f isn’t y” loops.
>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.
You would be surprised. A lot of cheap consumer routers are have two or four ARM cores. The bigger issue is that they are typically running a kernel from the stone age (< 6.0.0). Sometimes a still-supported LTS kernel like 5.10 or 5.15, but then they stopped at an old patch level.
Heck, apparently even the new Unifi UCG Fiber is running 5.4.213 (September 2022), but maybe they backport some fixes?
I’m in the market for a new router. Got a unifi u7 pro for wifi already, what are the options for routers? Sounds like the only safe thing is to roll your own so you can update things on time.
If you have a separate WiFi AP running your own router on your *nix of choice is quite achievable. I use NixOS since I use it everywhere else, if I didn't I'd probably go with OpenBSD.
Linux noob: I run a small VPS for a low stakes side project that runs Caddy and a Go backend that I've shutdown for precaution. Once a Ubuntu patch is made available, I read that applying the patch and reboot will be enough, but how can that be the case if someone used the exploit to break in and leave a rootkit or something like that? What are your full recovery plans for these situations?
If you don't already know and need to be sure, you have to start over with new hardware in a new network with new secrets. Firmware may be compromised and traces covered up, so reinstalling the operating system is not guaranteed to get the attacker out, nor can you trust the system to tell you if it was compromised or not. Your best bet would have been to record all incoming network traffic to a system only accessible offline and use it to verify no one tried to get it. Otherwise you can just hope, which is what mostly everyone will do, and will mostly be alright, because they're not important enough.
If you haven't rebooted yet then you can check how many mtcp handshakes you've received. It takes a lot of them to exploit this. 48 minutes according to the disclosure. So if it's a small number you haven't been hacked. Use "nstat -az | grep -i mpcapable"
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.
I went on a security kick early this year, locking down everything as much as I could. Build your systems with the assumption that you WILL get hacked. Limit blast radius. Be prepared.
The next few years will be crazy, but you're right, we'll come out the other side more secure than ever before. Just gotta make it that far!
Will be interesting to see, if AI will cause an increased demand for sysadmins. Not sure companies will go "Make no mistakes" on their (production) infrastructure.
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)
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?
OpenWrt doesn't open ports by default so I think the impact is minimal, unless this can breach nftables as well. CGNAT also mitigates this as a side effect.
If you have services open on the IPv4 net however, close them immediately as a precaution.
which selects "SNAPSHOT" in the right dropdown box.
Note that this gets you the lastest `master`, not e.g. the 25.12 branch, and may also wipe the OpenWRT UI package (LuCI). If you want to have the "25.12-SNAPSHOT" mentioned above, use the fimware-selector to find your device, note its "Platform" (e.g. "mediatek/filogic" for my OpenWRT One), and browse to that target platform in the URL, e.g. https://mirror-03.infra.openwrt.org/releases/25.12-SNAPSHOT/...
The `*-squashfs-sysupgrade.itb` packages from release-SNAPSHOTs should also not wipe LuCI, I think. But it would likely still wipe installed packages.
If you want to just upgrade to 25.12-SNAPSHOT, without losing any installed GUI or packages, use the CLI:
FWIW if you're stuck on 5.4 (e.g. Ubuntu 20.04 GA) for any reason, the 5.10.272 patch applies cleanly. There is only one function (skb_csum_is_sctp) missing in skbuff.h that needs to be added in, otherwise everything builds just fine.
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 difference between now and next year is that we won’t have time next year to patch before malicious agents use this exploit against everything at lighting speed. Global internet downtime will be the only solution.
Just to add a data point: we added an edge router rule to drop inbound IP packets with options set. Interestingly a) that rule has a hit count of zero so far and b) it was somewhat tricky to test because it turns out every host I could think of to run an nping command from is on a network that filters the packets anyway. Or perhaps our upstream provider is doing the filtering. I had to send packets from a machine where the path didn't go through anyone else's router in order to see hit counts increasing and thereby test the rule.
It works mostly fine, pretty easy to work with, might perform well when you're sleeping / not around, packages are old (not neccesarily a bad thing). The default kernel is vintage 5.15, so just compile your own. Also elilo really sucks so bring your own bootloader while you're at it.
A listener is a piece of software that advertises itself as available to inbound connections. You can do this on a variety of protocols.
Multipath TCP is a neat trick that allows a single TCP connection (TCP = Transport Control Protocol, a stateless protocol for long running connections) to use multiple physical interfaces. You could do something similar before MTCP using bonding, but this was annoying to set up and usually required application level code to efficiently use the bonded connection. MTCP makes this much simpler from an application level point of view and it can use widely diverse underlying transport layers at the same time (for instance, WiFi, Cellular and wired connections).
TCP is in the transport layer! The layers which you name are lower, such as Layer 2 (Data Link)!
MTCP, being in the transport layer, is working at a higher level of abstraction than bonding or link aggregation. There is no need for application-layer support, but it is possible, and easier, with MTCP than with the Layer 2 solutions, because MTCP is in the transport layer. That is why Go was able to activate it, and the POC uses it, because MTCP controls can be exposed at that level.
I wish. No, that was me at 5:30 in the morning after a long night of hacking when I really shouldn't be commenting on HN about anything more complicated than screwdrivers. I use AI but not to write.
It's an extension to TCP that, similar to QUIC, allows you to use multiple address/port pairs to transmit data over a single logical stream. Both client/initiator and server/listener have to opt into the extension. This might need to be enabled explicitly by the application[1], which Go apparently does for you, or judging from other posts may be enabled by default systemwide, depending on your platform.
AFAIU, a major user of MPTCP is Apple and the iPhone, and the ubiquity of iPhone clients motivated implementation in and deployment on Linux servers.
I had to look it up too since I hadn't heard of it. It's an extension to TCP that allows responses across different NICs. Sort of like Link Aggregation on to a switch, except it can go out dissimilar interfaces, like your wifi connection and your hardwired connection. Looks like you have to opt into it when you set up your socket: https://docs.kernel.org/networking/mptcp.html
In addition to aggregating, it can also be useful in cases where one link is much slower or higher latency. For example, if you're sitting in your driveway trying to get directions in maps while your phone is still on your very weak wifi network, it's a better user experience to have it to attempt the request using both radios concurrently so that it can fallback to cellular without waiting for a timeout/connection error if you're too far for wifi to actually work well.
MPTCP is an extension that requires cooperation. So it is only supported if the network stacks of both peers and all middleboxes can support it. The Linux kernel docs describe it as "opt-in", so it is not enabled by default for every socket opened on the system.
Again, the description of this CVE indicates that the vulnerability does not depend on MPTCP. But it is a factor in the proof-of-concept and its likelihood of success.
So if there was any widespread mutual support of MPTCP, it may shrink significantly as network admins deploy mitigations.
This saddens me since MPTCP is quite useful and not the cause of the bug, just a way to ease exploitation (probably simpler heap massaging? Way over my head). Anyway, upgrade, but don't block MPTCP; no exploit is available, and it's just as likely someone finds another path before Anthropic releases theirs.
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.
Add the below rule onto your machine's /etc/ufw/before.rules to mitigate it.
# CVE-2026-98432 mitigation: drop TCP packets carrying IPv4 extended options
-A ufw-before-input -p tcp -m u32 --u32 "0>>24&0xF=6:15" -j DROP
Any value >5 in this field means ip extended header options and so values of 6 through 15 should be dropped.
Note that I don't just drop syn packets like the mptcp exploit because any tcp packet could do it in theory.
This works for me on multiple servers and home desktops and my hardware linux firewall/router. I did it a couple days ago when this was first announced. The iptables counter for matches haven't gone up at all on my VPS servers that gets lots of traffic. The counter only goes up when I manually trigger it to test. Everything continues to work nominally with these in place.
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.
This is misinformed and dangerous advice, MPTCP is not a requirement. You would need to block all TCP packets with any IP options set to fully mitigate this. Thankfully iptables/nft can do it.
It might be bit of an effort to get Fil-C compiling the Linux kernel. As I understand it, it would amount to running garbage collector in the kernel, so some care would probably need to be taken to ensure it doesn't stop things at the wrong time, e.g. interrupts.
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).
With only 0.5% of Rust code in the kernel, this does not say much. The binder thing seems to be the only real Rust component so far, and it also mysteriously already had a race condition despite it being impossible to do such mistakes in Rust.
Indeed, I tried to draw attention to the fact the Rust that eliminates a whole class or errors and the Rust that competes with C in systems programming are not identical languages, but the original comment I replied to assumes exactly this.
Right. The "Affected Products" section on https://nvd.nist.gov is absolutely useless and highly misleading. I don't understand how this can be the case for something so security critical.
> 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.
Quite, however it looks quite rare:
"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.
This is not rare. Every TCP connection in Go by default enables MPTCP [1]. Simply running a Go program that uses TCP without explicitly disabling this behavior will cause the running kernel to be vulnerable.
1: https://groups.google.com/g/golang-announce/c/PCoQcdxoScw
the default on all of my RHEL is to have it disabled, I believe it's the same on Debian based
sysctl -a | grep net.mptcp.enabled net.mptcp.enabled = 0
and golang apps would just gracefully downgrade to non mptcp in that case.
> I believe it's the same on Debian based
"sysctl -a | grep net.mptcp.enabled" gives "net.mptcp.enabled = 1" on Debian 13 (Trixie). That's a non-server desktop install fwiw.
Edit - security advisory is here: (dated Oct 16) https://lists.debian.org/debian-security-announce/2026/msg00...
Does this mean Caddy is vulnerable? IIRC, I think it's written in Go.
[dead]
*Since Go 1.24
But any sane configuration would have the MPTCP port blocked behind a firewall (unless you were intentionally using MPTCP).
> MPTCP port blocked
MPTCP doesn’t use any specific ports. It’s an OSI layer higher than that. It’s part of the TCP protocol itself. So if your firewall routes TCP traffic of a specific port (eg HTTP) already then it’ll route MPTCP along with it too.
MPTCP is a protocol extension that requires cooperation by both peers and all middleboxes. So, if there is a Layer 7 firewall, or DPI/SPI, or TLS termination on the path, and it's not inclined to preserve the MPTCP options, then MPTCP will be disabled.
Firewalls do not operate at layer 7 nor do TLS termination.
What you’re thinking of is load balancers. Most of them will do TLS termination. But there’s also plenty of load balancing solutions out there that will forward the raw TCP traffic (AWS NLB, DNS based solutions, and so forth).
But it’s also worth noting that this vulnerability doesn’t explicitly need MPTCP. Just the POC exploit uses that.
Firewalls can operate at Layer 7, too. The “F” in “WAF” stands for “firewall.”
I thought it stood for "false positives"?
i always thought it was "What the Actual F**"
Attorneys can operate as a firewall too: if they sit in a building with a firewall.
Bwahahah!
fnord
Wait. So; just because you've studied with someone makes your opinion correct? Damn. I wish I would have known that long ago! In both my education tracts of medicine and CS, I've studied with some pretty great minds and I could have been passing off my opinion as fact for decades now.
I wish I would have received that memo. </sarcasm>
A request from authority isn’t a counter argument. And it doesn’t mean your opinions about this attack were correct.
Congratulations on knowing what a bastion server is though. But that’s extremely common knowledge and doesn’t prove your point either.
Perhaps you can share how a layer 7 inspection tool might mitigate a layer 4 attack an actual networking terms?
It seems like the anthropic PoC involves MPTCP, but the bug itself is not in the MPTCP code, it's in a generic TCP codepath relating to options, MPTCP was probably just a convenient codepath for memory manipulation.
Try:
to check. If you're running any Go code, you may be surprised. I was.Btw, one can switch it off for Go programs not only with env variable, but also in go.mod:
That's coolI have cloudflared show up, that's suck i guess ?
Allright, I removed stray anubis install I had on my vps, after running this.
i see lot of tailscale is running and isn't tailscale mostly written in Go?
Tailscale shows up.
From the article:
> The Go team adds that "the underlying bug is not specific to MPTCP. It is possible that systems with no MPTCP listeners are vulnerable to similar attacks"
MPTCP is only required for the known exploit, it isn't necessarily needed.
containerd (docker) uses it
"TCP stack" versus "Linux TCP stack" is an OOM in terms of relevance.
Out of memory?! That's terrible!
That's what I thought, what do they actually mean?
Order of magnitude
Get out of here. What next? TCP means Totally Cool Presentation?
On April 1, 2008, "OOM" was what dyslexic cows say, but today there are 14 bona fide interpretations.
https://en.wikipedia.org/w/index.php?title=OOM&diff=prev&old...
A tragedy that the humourless editor removed that. Flavour text is always welcome.
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.
> Exploitability over the internet is unlikely, most ISP routers drop packets with ipoptions fields.
That doesn't track. Apple iPhones are a major user of MPTCP and they report the majority of requests supporting MPTCP, IIRC 70+%.
MPTCP uses TCP options fields, the vulnerability is in IP options.
There are two types of multipath TCP and they are not at all the same.
What Apple does is, for example, being able to have a connection over WiFi and 5G simultaneously, with different IPs and routes.
The more traditional server side multipath is that you have a network card with 4 ports (eg 4x 25gbit) and connect them to a router, and make those 4 physical ports (paths) behave like a single interface. This helps either load balancing or redundancy.
The latter is what this vulnerability is about.
That’s typically done with thinks like lacp, not multipath
Sorry but that's plain wrong.
Neither has layer 2 LAG nor has layer 3 ECMP anything to-do with layer 4 MPTCP.
What's vulnerable is MPTCP.
And it takes around an hour to do this in lab setting locally:
> An enabling property of this race condition is that a lost race only fails the handshake without crashing the whole system, so a determined attacker can retry indefinitely until they succeed. In our proof of concept, it takes 48 minutes to leak a kernel pointer and another five minutes to reach the shell command execution
source: https://www.anthropic.com/research/discovering-vulnerabiliti...
Tragically not enough people drop IP options. I did it in the early 2000s for a very large US network and was glad. There's lots of obvious reasons as they're generally an old school ddos path to knock out routers (get punted to the RE/RP exception path, a good way to bypass some loopback/routing engine acls if folks don't filter it right). Every few years some academics pop up with let's use IP options because we can stuff more bullshit in the datagram - it's always a bad idea.
Eh, this is why networks ossify and we can’t have nice things like a maintained connection when switching from home wifi to 5G. MPTCP is important, eg Siri uses it I believe?
MPTCP doesn't require IP options. Confused at what you are trying to say.
Doesn't http3 support it?
Dropping packets with IP options from XDP should be a more complete mitigation (also more performant).
Whipped something up: https://github.com/jamilbk/drop-ipv4-opt
https://en.wikipedia.org/wiki/Express_Data_Path for anyone else wondering what that is
tl;dr: eBPF programs that run hot off the DMA buffers, before skbufs are created, that can XDP_DROP packets.
In some cases on the NIC itself! (i'm sure you know this)
I'm wondering if Android is vulnerable, since it is based on Linux?
Do
sudo tcpdump --immediate-mode -p -nn -i eth0 -vvv -c 1 'ip and (ip[0] & 0x0f > 5)'
to see if you even get them from upstream.
You can even ping it from outside with these packets in the meantime
ping -R -c 3 $IP
One can also monitor for it in nftables. This is from my raw table:
Once confident nothing legit would be blocked by dropping the packets one can change "log prefix "CVE-2026-98432: " level debug" to "drop" if on an unpatched kernel.$ADDR4 in my case in my internet facing interface.
For more on why MPTCP is not relevant--my limited understanding is the issue is with SYN retransmits.
SYN packet #1 is received and added to a request queue for processing.
SYN packet #2 is received and is a retransmit of SYN packet #1. It is matched to SYN packet #1 already in the request queue and now there is shared state between both SYN packets #1 and #2 in the request queue.
CPU #1 takes on the task of processing SYN packet #1.
CPU #2 takes on the task of processing SYN packet #2.
CPU #1 responds back with RST packet #1 (e.g. requested TCP port is not open) and _should_ defer the destruction of the request socket for SYN packet #1, as other CPUs may still be processing the shared state for the request socket as is the case for retransmitted SYN packets.[1] However, this deferred destruction wasn't occurring, and CPU #1 was _immediately_ destroying the request socket/shared state for SYN packet #1.
CPU #2 races with CPU #1 and reads from the request socket/shared state for SYN packet #1 after its _immediate_ destruction by CPU #1.
Linux's IPv6 handling is unaffected because in this IPv6 scenario, there is no shared state between SYN packets #1 and #2 in the request queue. Instead, each request socket has duplicate data.
Someone more knowledgeable can confirm/correct me on the above please.
[1] https://www.kernel.org/doc/html/latest/RCU/whatisRCU.html#rc...
What does the vuln have to do with IP option field then?
The use-after-free occurs within ip_options_build (net/ipv4/ip_options.c) which CPU #2 processing the retransmitted SYN packet uses to read/copy options out of the unallocated/reallocated memory that CPU #1 had already freed up. Remember that the options header is variable length too so CPU #2 is seemingly under-reading/over-reading this variable length options header by some fairly random amount between 1-256 bytes depending on what data has been written to the reallocated memory.[1]
The undocumented part (per LKML discussions at least) is what happens next in the attack. Seemingly CPU #2 or CPU #3[2] comes along later to process the random jibberish options header and rarely (in Anthropic's case it took 48min locally) that random jibberish will be returned to the attacker (e.g. copy jibberish options header to a response packet?) and it'll expose a return pointer to a fixed kernel function. The attacker then crafts a SYN packet and retransmits it with an options header that places a return pointer in the right place, and hopes for another race to occur where CPU #3[2] executes a callback to an attacker-controlled pointer stored within the options header data. Anthrophic's case said it took 5min for this stage of the attack to work locally.
Someone will probably write this all up at some point and it'll be quite a long and detailed read of how the 48min and 5min stages of the attack work and perhaps this is where MPTCP code paths are involved due to the way they process the TCP options header data.
[1] https://en.wikipedia.org/wiki/Internet_Protocol_Options
[1] Author of the kernel patch suggests that CPU #3 (three way race) is needed per https://lore.kernel.org/netdev/CAL4WiiroQ8XyDzUnmuy5FmJ4SWfZ...
[flagged]
Here's the NIST link: https://nvd.nist.gov/vuln/detail/cve-2026-98432
Here are my notes so far after digging into this with Claude + defensive access:
1. Not just an MPTCP thing - any received IPv4 packet with options creates the problematic conditions.
2. Also appears that using NetLabel/CIPSO (SELinux or Smack with a CIPSOV4 mapping) creates the same conditions that a packet with IP options would. If you're using these, it might mean that dropping IPv4 packets with IP options might not fully mitigate.
3. At least for our test VMs in Azure (accelerated networking) I wasn't able to get any IPv4 packets with options through, from three different US-based ISPs. Unfortunately Microsoft publishes no docs on whether the fabric drops this or not, so YMMV.
We're using a simple XDP program to mitigate until a patched kernel is available (thanks @tptacek for the idea):
https://github.com/jamilbk/drop-ipv4-opt
Claude suggested this nftables-ipopt config + systemd unit to survive reboot will also fix the issue. Can anyone comment whether this is early enough in the stack to also solve this?
Also couldn't get IPv4 packets with options through between Hetzner cloud servers (different networks), but it's no guarantee.How are Ubuntu and RHEL not fixed? Few operating systems market themselves more as suitable for servers. What are they doing over there?
If you read commit logs of, say kernel.org and a distro kernel, and aren't concerned you are blissfully ignorant (and it is worse for the broader userland repos). It's particularly bad when they don't track a kernel.org LTS. Their kernel orgs are pretty lean and this has been the status quo for decades. CVEs of sufficient stature like this will get fixed but majority of other issues slip by unnoticed. LTS is kind of a myth, it trades ABI and API stability for a lot of other issues.
"Their kernel orgs are pretty lean"
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.
My hearsay, from friends and colleagues that work(ed) there, is that the shipped product is not really where you see these "heavy hitters".. a lot of the maintenance happens offshore.
Just makes sense that they would put the "heavy hitters" on feature development, not backporting security patches.
The Noble 6.8.0 LTS kernel is a mess. Im not sure what we are going to do in our org. We have been discussing it for a few months. I want an in house fork based on an GKH LTS but others are hesitant to take on that level of responsibility.
Unfortunately, as a ZFS on Linux user, LTS is the best way to get continual updates without breaking my system.
Probably best to not leave any ZFS system connected to the internet then.
Or perhaps this illustrates the value of running all web services under KVM rather than bare metal.
Or the value of not running linux everywhere.
Regardless of the OS, kernel, or program you select there will inevitably be holes in your stack. A VM will always provide better isolation and more flexibility. In this instance it would mean being able to patch the box running the service without messing with the driver for the backing storage.
Depends on the VM system. Full blown virtualization add complexity and attack surface. Running vmless[0] could be even better if you trust the design of the isolation enough.
[0]https://www.youtube.com/watch?v=xXWaECk9XqM
Anything important should be virtualised and regularly snapshotted. Nothing is invulnerable but if it can be reconstituted in an hour, that’s close enough. If it isn’t and you care enough then a standby server with failover should take care of it.
I have found that Debian BPO kernel + BPO ZFS works well, and since ZFS gives you complete snapshotting capability a broken upgrade isn't as much of an issue, rolling back with zfsbootmenu is easy.
zfsbootmenu looks very cool, thanks for sharing!
What usually happens to me is that I run a full package update, forget about it for a while, and then reboot. And then the server doesn't come back online - and I'm not in front of it to fix it.
LTS kernel pretty much solved this issue for me when I switched.
ZFS is completely broken on Ubuntu Noble 6.8.0 LTS.
Over the past few months I've started to install newer ubuntu kernels using the mainline PPA. However, it goes long periods of time without getting updates, so it's not really a satisfactory solution. In one case I just built the kernel myself.
LTS doesn't work if you want immediate fixes like the current environment requires.
> How are Ubuntu and RHEL not fixed?
Ubuntu has had kernels in the "proposed" component for several days now if you want to pull it in manually. Not yet pushed to "security" or "updates".
Is there an RTFM for 'pull it manually'?
enable the proposed repo (and pin it to a lower priority) and install the package explicitly
https://ubuntu.com/project/docs/SRU/reference/sru-verificati...
or download the individual package (and dpkg --install ... but this doesn't check signatures)
https://ubuntu.pkgs.org/26.04/ubuntu-proposed-main-amd64/lin...
check https://ubuntu.com/security/CVE-2026-98432
Given the current and rapidly upcoming environment, would that not imply that those are no longer viable choices? As like a fairly urgent emergency consideration?
If they cannot demonstate being systematically able to adapt towards the required reaction time (minutes? hours?) by almost-comically many orders of magnitude (multiple weeks), and it is only going to get worse, then what other conclusion could there be?
Like they'll only organizationally adapt when it's far too late (everybody using their shit has already been pwned), and then it'll be an unpracticed emergency adaptation.
No, they are providing a service, LTS, that customers still want and pay for. Only once the customers realise its not a workable product and they want a rolling update product, with all the changes that implies, will this change.
It seems particularly crazy for Ubuntu given that Debian released their fix something like a couple weeks ago.
They pull from Debian unstable every 6 months and that's it. Afterward, changes made in Debian mean nothing to Ubuntu.
Don't trust Ubuntu's LTS promises, either. Most of the modern packages you care about are in universe, which almost never gets patched after the initial release.
I think they deliberately leave the free LTS version insecure in order to sell Pro licenses. But guess what, even Pro doesn't get timely patches.
I’m pretty confused because apparently Anthropic is the group that followed “responsible disclosure” but apparently even though upstream was patched a couple weeks ago, still nothing on either.
Because upstream is public. Once the patch hit the repos, people would know why and it’s now in the open.
I assume RH and others probably knew at the same time as Linux. I’d lay more blame with them on the lack of movement.
It's one of two things: Either they have found some regression with enterprise customers, or they are not happy with the fix.
RHEL runs with MP-TCP disabled by default, they initially listed it as Important only to later raise it to Critical.
>How are Ubuntu and RHEL not fixed?
IMNSHO this makes them unfit for purpose. I think this is the nail in the coffin for Ubuntu for me.
It's not a good look.
I pulled in from -proposed this time.
Ubuntu was slow on the brotli / CVE-2026-111497 updates as well.
And the PHP update, it took like an hour after the embargo ended.
What would you suggest for enterprise use of Linux if RHEL is no longer fit for purpose?
I'd be seriously considering Debian or, hear me out, NixOS. We run all our work servers on Ubuntu, but ~6 months ago I switched my workstation to NixOS and I couldn't be happier. I've been following "latest" or whatever they call it, being able to treat the OS package versions like the rest of our software (update the flake.lock file and then burn it in in dev+stg for ~2 weeks before rolling to prod) is pretty attractive.
I run Debian on servers and Arch Linux on clients. Debian is definitely the better choice for enterprises.
> NixOS
No legit enterprise is running that clownware — ever.
It used to be true that no one got fired for buying IBM. Now, I would laugh at any organization that chooses IBM.
Times can change.
to be fair their storage, and I mean their SANs, is still the best (excluding very expensive alternatives that are only really beating IBM in few limited scenarios).
I still like DB2, but only for banking/finance core stuff, and their mainframes are just unique machines, I'm very fond of them.
I certainly know people who run NixOS in commercial production. It's hardly "clownware".
I think helsing and or andruil do?
Debian
I don't think I can recall an instance where there was an issue this bad (a box being vulnerable just by virtue of being connected to the internet, or exposing nothing other than ssh) and I didn't have timely patches for it. I had to turn off my server and home automation system because of this. Really not acceptable at all and makes me want to switch everything to debian.
Going by the proxmox forum the fix is already in the sources (proxmox released their kernel based on them a few days ago). But I could not see, if it is already released for the users.
https://forum.proxmox.com/threads/cve-2026-98432-in-proxmox-...
Yes, we (Proxmox) included the fix for this in 7.0.14-25, which was initially packaged two weeks ago.
It went through internal QA and to the test soon after that, then a few days later to the no-subscription repository and as of yesterday morning CET it was cleared for the enterprise one, so it's available on all repos of all Products we got in their current supported releases.
For kernel updates we where even more conservative in the past, but with the current churn on often quite relevant fixes picked up the pace a bit on moving them along, trying still to balance rolling out fixes fast(er) while not doing that so fast that tricky (hardware/setup specific) regressions don't get caught.
edit: As this makes the rounds we also released a PSA for it now [0] to make our status here easier to find.
[0]: https://forum.proxmox.com/threads/proxmox-virtual-environmen...
Remember folks, while you wait for your patches, you might want to install a proxy to prevent these things from happening:
https://news.ycombinator.com/item?id=50330367
Running regression tests I assume; they can't just YOLO shit like most OSS projects for the exact reason you mention.
It could be that it is more YOLO not patching this ASAP. Maybe better to risk some regressions.
For a month?
the default in RHEL/CoreOS is:
sysctl -a | grep net.mptcp.enabled net.mptcp.enabled = 0
No patches for Ubuntu or red hat yet.
https://ubuntu.com/security/CVE-2026-98432
https://access.redhat.com/security/cve/cve-2026-98432
Interestingly, Ubuntu Priority is set to "High" and not "Critical" which is defined as:
"A significant problem, typically exploitable for nearly all users in a default installation of Ubuntu. Includes serious remote denial of service, local root privilege escalations, local data theft, and data loss."
Makes you wonder what the critical level is for
Remote RCE/data theft basically, as opposed to the local of High: https://ubuntu.com/security/cves/about#priority
This is an RCE though...
Yep, and UAF is RCE. DoS must be reliable, like memcpy_s bounds check failure that cleanly aborts the process.
Ah, I misread the first comment and thought it said remote execution, not remote denial
> https://ubuntu.com/security/CVE-2026-98432
The listed kernels are in the "proposed" component (and not yet in "security" or "udpates") if you want to pull them down onto canary systems for testing before going to production.
so just block multipath and add the firewall rule from article that drops packets with IPv4 options
Both of which we are finding out are apparently insufficient to mitigate this.
"the bug sits in code every Linux server runs when it accepts an IPv4 TCP connection, before any application sees the connection."
Is iptables considered an "application" here? I.e. can this bug be triggered before iptables drops the packet?
Put OpenBSD in front to protect that little scared penguin.
That would only work if OpenBSD is terminating that connection.
OpenBSD packet filter blocks packets with IPv4 options or IPv6 hop-by-hop or destination options header by default, according to `man pf.conf`.
Hoping fix will be out soon so we don’t have to.
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.
The fallacy is the idea that a Rust implementation would automatically achieve the same performance, and not resort to "unsafe" to be competitive, and then be open to exactly the same issues.
Illustrative example: This CVE in a Rust matrix transpose code: https://github.com/advisories/GHSA-5gmm-6m36-r7jh
Conceptually, there is not really anything much simpler than a matrix transpose. So how did they manage to create a bug? To make it fast you need simd, which implied using unsafe, and the dimension check to make it safe used unsigned integers that could wrap around. So they same bullshit as in C.
Your fallacy is that you present the comparison 'if' either of the two can be done poorly.
Rust can separate the question: "Is a set of functions is safe in a certain condition" from "using functions in that condition".
They are materially different. SIMD has a safe interface now.
The only question is to what extend this is relevant in reality, and how it compares to other efforts to avoid bugs.
Google already did it and resorted to unsafe rust to be competitive.
I won't comment on your entire comment, but this:
> To make it fast you need simd, which implied using unsafe
Is just false. There are multiple safe SIMD libraries for Rust that can exploit the full SIMD potential. Only very rarely they require unsafe for maximum performance and only to avoid bound checks.
Counterpoint, more than memory bugs exist, and everything's written in C. You're welcome to rewrite in Rust but you'll create countless bugs that aren't memory bugs that mostly already got fixed in the C version. I can't help but think things like fil-C are the most pragmatic route, despite performance costs, for most people relying on programs written in C.
Yes, you'd introduce a lot of new bugs because the code is newly written[1], but eventually you'll get to the same maturity as today except you can't have all these devastating memory-handling-related vulnerabilities
The question is whether your software will be in use long enough to be worth the cost of change more than whether it's a good idea in the long run. For Linux, I'd argue that that's likely. At least new code would ideally be contributed in a safe language, where practically possible (there'll surely be places where you need to deal with memory as a kernel)
Relevant article: reducing memory vulnerabilities through a combination of memory-safe languages and an exponential decrease of bugs as existing code ages https://security.googleblog.com/2024/09/eliminating-memory-s..., from which I'll also quote my reference for [1]: "A large-scale study of vulnerability lifetimes published in 2022 in Usenix Security [...] found that the vast majority of vulnerabilities reside in new or recently modified code"
This is a dumb argument imo. Critical vulnerabilities are mostly due to memory bugs (and not for a lack of other kinds of bugs). Most people relying on programs written in C (or even C++) should consider plans for migrating to software created with toolchains from this century. You cannot indefinitely carry on this tech debt.
Here are some CVEs identified in Rust coreutils [1]. These are mostly really trivial issues. I'd bet money that the nastier logic bugs are still in there and that the people who maintained the old C utils or helped identify the old bugs can find similar ones in these utils, although half these issues probably never appeared in the C version because Rust is much more complicated than C so makes it easier to hide logic bugs in plain site, looking at many of the issues in this article they seem like bugs that are extremely unlikely to get written in C, like accidentally forcing everything to be UTF-8, or aborting on routine errors.
[1] https://corrode.dev/blog/bugs-rust-wont-catch/
I strongly disagree with the idea that Rust makes it easier to hide logic bugs. Rust is a much more complicated system than C but allows software engineers to work at a much higher level of abstraction which generally reduces logic bugs. Of course, new projects will inherently have bugs but with Rust it is easier to achieve a higher level of rigor.
To be clear, this is not due to the borrow checker at all, Rust does not have the tooling to statically determine the absence of logic bugs. What it has is the necessary programming language features to manage much more complex systems through abstraction and modeling.
At least it doesn't silently launch nuclear rockets, smaller bugs are manageable, like accidentally forcing everything to be UTF-8 is basically nothingburger.
until you can't delete a file because it's not valid UTF-8
One issue with this argument is that, almost everything is memory, especially in C. It's not really descriptive. If you write a reactionary language like Rust, it may be possible that you just fix one type of issue (with an error type taxonomy that's not very refined), and end up with a language that does not necessarily cause less bugs and vulns, but that causes less vulns that can be classified as that type of issue, while increasing other types of bugs/vulns, either of an existing type, or of a new type that only exists in that new language.
Like are we empirically seeing less Rust CVEs? Adjusted for popularity of software and perhaps age of software.
Are you saying by attempting to reduce certain types of bug category such as memory safety, other types of vulns would suddenly be increased because of it? It sounds to me like you are saying we shouldn't treat common cold because cancer rates might increase. And what do you mean by reactionary?
> It sounds to me like you are saying we shouldn't treat common cold because cancer rates might increase
surprisingly that’s almost not a strawman, I’d support an argument like that, and it’s how medicine works
if a cancer treatment is discovered, it needs to be trialled for side effects, and actually chemotherapy can have side effects that are worse than the cancer, it’s entirely possible for chemo to weaken the immune system and thus increase colds.
so hillariously, yes, that’s almost what I’m saying. but to be precise I’m not saying we shouldn’t cure cancer or solve bugs, just saying that solving one kind of issue doesn’t prove the tech is beneficial overall, and the more generic the problem being solved, the more likely the panacea will fail or have side effects
It’s also never been easier to replace C programs with safe alternatives.
Sure. Where's my rust chromium rewrite then?
I wouldn't be surprised if Google is experimenting with exactly that right now.
I'm not suggesting anything like "rewrite in Rust", at least not in general. I'm simply poking at the fact that use-after-free (and other such issues) are effectively deprecated classes of bugs.
With all the "Claude rewrote X in rust!" posts lately, I'm waiting on the inevitable Linux kernel rewrite post.
Vibe code aside I feel targeted rewrites are becoming more and more justified.
I wouldn’t be surprised if we start seeing individual drivers and subsystems move over.
The Linux maintainers have been extremely conservative with the Rust introduction but after the endless CVE apocalypse they might be more receptive.
> I wouldn’t be surprised if we start seeing individual drivers and subsystems move over.
Already happening. https://lwn.net/SubscriberLink/1102982/c3a3a2d4f17108c5/ "Removing binder.c" is an article from yesterday, about discarding the old C implementation of the Android Binder driver (used by every single Android phone) in favor of its Rust reimplementation.
Linus is using LLMs
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'm more worried about my consumer-grade router.
I blocked packets arriving externally on my firewall with ip-options a couple of days ago. Firewall rule has zero hits, and I've got a very open ISP (andrews+arnold), if I want I can host SMTP, DNS, whatever
I switched to OPNsense last week. Consumer grade WiFi AP is behind it. I’m not depending on firmware updates from a company that has no incentive to make them.
May CGNAT save you.
The timeline says the CVE was reported over 2 weeks ago, so why are the alarms sounding now?
Anthropic published a blog post claiming RCE with it [0].
[0]: https://www.anthropic.com/research/discovering-vulnerabiliti...
Which was 4 days ago.
For some reason the submission I saw here last week (not the same article, and I'm struggling to find now) was flagged to death before getting as popular as this one.
Note: AWS NLB doesn't terminate TCP for TCP listeners.
It would be great if they introduced mitigations for this vulnerability though.
Another reason hyperscaler cloud providers will continue to grow (IMO)!
My FreeBSD loadbalancers block packets with IP Options with default config. It’s not rocket science, no matter how Cloud providers are trying to tell us.
If I'm not mistaken, looks like pfSense (based on FreeBSD) firewall rules also block IP Options by default too.
Unless they themselves (underlying services) get hacked...
My VPS was auto-updated and restarted more than 14 days ago. The logs have rolled already. Probably October 12 early morning.
Another reason NixOS will continue to grow :)
Everything talks about this in terms of servers, but what about desktop Linux in typical setups? Consumer modems and routers? IoT junk?
IoT devices will get fixes delivered on the 12th of never.
So, the good news is that I can probably now get root on almost any Linux-based device I own. Don't even need to solder on a serial port or w/e, just direct network connection.
Yeah this is really a blessing for people seeking more control over nice hardware with horrible software, "smart" spy TVs, Android (moar ads on your) TV boxes, cheap insecure security camera's with only Crappy Cloud subscriptions... Go AI!
Needs two cpus at least, so a lot IoTs are spared because of that
But are they exploitably vulnerable to this specifically in typical setups?
To be fair probably not as many will be single core and this requires multi-core. As for the thousands of other CVEs though ...
Dual or quad core is not that unusual even in very cheap SoCs, but this particular CVE needs a kernel line from this decade. Thousands of other CVEs indeed..
The security fixed will be installed next tuesday.
Was going to say that, depending on the device's age, this law may apply, where article 13 sub 9 specifies a decade of updates is the minimum: https://eur-lex.europa.eu/eli/reg/2024/2847/oj But then it turns out that this "applies from" late 2027 :/
Simultaneously Wikipedia says the Act has "entered into force" in 2024. Does anyone know the difference between "enters into force" and "applies"? Is it like this 2016–2018 grace period for GDPR where it was "law" but not enforced? (The wording sounds backwards if it's that, but I'm not a native speaker)
That's how i'd read it but i'm not 100% sure. legal terms can have specific meanings in a legal context that's different from general use.
but also this is one of those cases where, ok you have a law, but, that's meaningless. It's not enforceable. It's not even monitorable. It's nice in theory to write down a bunch of regulations but at best you can make a bunch of EU companies do some paperwork. anything imported from outside the EU, the company can agree to everything and then dissapear. ALl the direct to consumer slop on amazon and whatever. How is the EU supposed to enforce a law against a random fly by night brand name in Shenzhen?
From https://taxation-customs.ec.europa.eu/news/report-highlights...
> As volumes rise, enforcement is weakening. In 2025, the EU control rate fell to 65 items per million items imported. The rate of goods ultimately refused at the border due to non-compliance or because they posed serious risks, also fell to below 10 items per million.
> A large-scale customs investigation launched by the Commission in 2025 highlights the scale of the problem. Over 60% of checked toys, small electronics, cosmetics, personal protective equipment and food supplements bought online from outside the EU failed to meet EU product compliance and safety requirements.
It's just regulation theater. It's meaningless.
> the company can agree to everything and then dissapear.
Isn't that the case for every law related to commitments? Warranty, repair parts and battery longevity is a thing now iirc... haven't had issues with that being avoided so far, at least not in this way
A huge volume of purchases (including in the EU) are direct to consumer from Amazon. There are a lot of fly by night brands on there and you'd be surprised how many of them seem to no longer exist within a year or two. Your big company backed Samsung phone might get security updates, but the IoT junk in question is not likely to.
Re battery longevity - see the power bank bans by the TSA in the US. Maybe you are getting lucky or are only purchasing products from reputable long lived regulated vendors, but the sheer volume of vulnerable devices does not come from those products
You should assume your IoT junk is already compromised, that's why your IoT junk runs on a dedicated VLAN.
What kernel is the router managing these VLANs running?
An updated one 'cause you're running a virtual router in a container or VM which gets all the updates your server(s) get.
FreeBSD in my case.
They're on a dedicated VLAN in the county dump
Desktop Linux in typical setups? Consumer modems and routers?
Typical setups probably aren't listening on a public address (or any address for a desktop), so you'd at least need a LAN attacker presumably.
I think fix arrived like two weeks ago or something. So typical Desktop Linux is safe. I use Arch btw
> 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.
My understanding is that an app explicitly needs to open a "multipath" socket. Go 1.24 does that by default, so does Caddy, these would be the big ones.
Your understanding seems to be wrong.
Every Ubuntu version in the last decade is currently vulnerable.
https://ubuntu.com/security/CVE-2026-98432
Patches not yet available. That makes this a big deal.
This article says that this isn’t app level but is level and can be exploited before requests reach apps.
> on servers with a multipath TCP listener
I was talking about the Anthropic blog post, only Go/Caddy enable multipath TCP listeners by default.
Well somebody is wrong, this blog post says:
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.
It reads like it was LLM generated though so who knows. There is at least a simple mitigation for Golang apps if that is the only concern.
Both are correct :)
Anthropic only exploited multipath TCP, but the bug is deeper and also affects TCP connections, but it looks like this path is harder to exploit, and it's unclear if anybody managed to.
Thanks. Expanding exploits is something LLMs seem pretty good at so I’d expect people to manage a more general exploit soon if not already. Hopefully it’ll be patched before that happens.
> what percentage of TCP/IP servers are 'multipath'?
no idea, but at least Tailscale and Caddy were opening MPTCP sockets on servers I checked.
only if it's enabled at the kernel level? I have this, and it's the defaults, on my RHELs:
sysctl -a | grep net.mptcp.enabled net.mptcp.enabled = 0
and found not MPTCP listeners anywhere, including where I have caddy.
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?
https://pwn.watch/ has an RSS feed available
That heat map this month
alright alright, what's going on? This doesn't seem to correlate with a big model release? (or does it? Claude Haiku 5.5 is in the vicinity) Is this just Anthropic/OpenAI causing this trouble by themselves to validate their existence? Is this related to Anthropic's IPO?
Lines up pretty well with the undisclosed anthropic model. But most likely there's some other explanation/combination of explanations.
Maybe broad adoption is the answer? More people are starting to understand how to apply LLMs as tools, some people who previously might have been hesitant are now willing since they're seeing the benefits?
I don't know for sure, but over the past few months I've seen a bunch of skeptical people do a complete 180 and start using LLMs more actively.
For that it's too sudden. Yes, people flip, but not absolutely everyone and their mom flips within a week.
Its just what exponential growth looks like?
Coincidentally, this month was also huge for reverse engineering and recompilation of games.
Thanx, this seems to be the most relevant feed: https://pwn.watch/feed.xml
Any chance you’d mind sharing your list?
From Claude:
_If you’d rather get messages in real time, you can subscribe to the list itself by sending an empty email to oss-security-subscribe@lists.openwall.com. Be aware that the volume is high; October 2026 alone had 460 messages._
That's also well into clanker managed territory ;) (I mean the clanker builds a small automation, no LLM involved after that, I do a lot of that, just use clanker to build, update, organize, monitor and handle edge cases.) I have used free (and therefore limited) agentmail.to for this. I find the subscription to be a bit expensive for my hobby, but it's a nice service if you do this professionally.
[dead]
The openwall oss-security list usually covers a decent number of issues and this CVE was mentioned there yesterday:
https://www.openwall.com/lists/oss-security/
Thanx, the relevant rss feeds seems to be presented here: https://seclists.org/oss-sec/, being https://seclists.org/rss/oss-sec.rss
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?
The good news is, if you emergency patched your Debian for php2shell, you probably got the new kernel on the same apt run. This time the embargo actually held, and the new kernel was out before the CVE came public
The only way to survive is to just update everything daily or faster.
At work we currently have a weekly release schedule but im going to push to speed it up because 1 week is far too long to leave packages out of date.
Then you get exposed to a supply chain attack.
Supply chain attacks through distro repos haven’t really been a thing.
Random npm packages are another thing.
We got very close in XZ Utils.
https://en.wikipedia.org/wiki/XZ_Utils_backdoor
If AI is building all the systems and writing all the code, and AI is finding bugs and exploits in existing code and code being generated by AI... With the assumption that any code base scanned in its entirety by the latest frontier cybersecurity focused models is secure... This assumption only holds until a more advanced model is created to find bugs and exploits in the code from the now lesser advanced model... Which means even the code the top of the line model just created was never really secure...
How does this cycle get broken?? Will people ever be able to be sold the (false idea) that their devices are secure?
The implications are extensive.
> With the assumption that any code base scanned in its entirety by the latest frontier cybersecurity focused models is secure...
The models that many organisations and most individuals don't have access to?
Nope. This was just the start.
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).
You need to do some https://en.wikipedia.org/wiki/Heap_feng_shui. If you can reasonably reliably trigger some other operation that allocated the freed memory for another purpose, you have something like a type confusion vulnerability.
It goes around in circles because a UAF alone isn't enough in a lot of cases, sometimes you also need a chain (an info leak, read/write primitive etc), a way to defeat ASLR and so on depending on what you are working on and target mitigations. Not all UAFs can be used for RCEs, some can be used only for DoS or for nothing really.
One example is that you might be able to read what was written there. Here that may mean you could read another process’s packet(s). Imagine they were sending unencrypted passwords, perhaps because it’s in a trusted LAN connection.
If it’s freed it can be reallocated, so then you have pointers to the same area of memory used for completely different data structures, and this can go very wrong
I get the principle - what I struggle to find is concrete examples of how it can practically be used.
How do you know which pointer (as I say, especially if it’s in the heap)? And I know it can go wrong - but how do you do more than just crash the kernel?
In OOB writes in a stack variable it’s completely clear to me. For other situations I’d love to find real and clearly explained exploits of past UAF or OOB vulnerabilities.
Getting the right thing allocated in the right place to exploit a UAF is usually very very tricky. For a defender we just need to know it's probably possible and therefore we patch the bug, but the attacker still has a difficult job to do even already knowing a UAF bug.
The simplest thing you could try to do is allocate several more of the same type of object and hope one of them lands at the same memory address. For example if you can UAF a web app's user session and keep it open for a long time period (not true in the TCP bug), you might try to wait until an admin happens to log in with their session at the same address, then use their admin session.
Or you can allocate a lot of something else objects and hope a certain field overlaps, like a function pointer if you can write to it. Like suppose you can get some kind of authentication callback pointer to overlap where your packet sequence number was, maybe you can send a certain number of packets to make it point to the return instruction and skip the authentication.
One technique is to just spam the heap full of a certain object you're hoping will overlap it. E.g. if you want to affect a connection object, you might try to open one million simultaneous connections, then touch the UAF object, then check each connection to see if it got messed up. This is called heap spraying and it's often seen in JavaScript vulnerabilities, a bit less in network vulnerabilities since it's easier to allocate a million Uint8Arrays than to open a million TCP connections.
A web search for "exploit chain uaf" found me a few real-world and a few tutorial examples, though I don't know which are good.
At a high level, though: once you've gotten a new object allocated where the old one was, you now have two different views of the same bit of memory. You use valid operations on one view to put the other one into a corrupted state. For example: in a unixlike kernel, maybe one view has a field containing a function pointer (for method dispatch, essentially). You read that field using the other view, use it to deduce something about the target's memory layout, write a new value to the pointer, then use the field via the first view to cause execution to jump to a location you control.
Maybe check https://github.com/sarabpal-dev/IonStack-S22U It has a full chain reproduction of the use-after-free vulnerability that grants you root on Samsung phones with a locked bootloader.
I don't think a UAF on its own allows control hijacking in an exploit. You will need further logic bugs or the ability to legitimately or illegitimately control memory, either via further requests / function calls, OOB writes and such. And it will always be extremely specific to the application vulnerable.
For example, I remember an exploit workshop around reuse of passwd entries. The vulnerable would validate a passwd entry for a non-root user, use it a bit, and later on free and zero it out for security purposes... except it then looked at the passwd entry again in some conditions. Suddenly, the uid was non-zero at first, and zero later on, so later decisions assumed the user was root.
In a more concurrent situation, a possible vulnerability was a shared cache of these passwd entries. It wouldn't zero them out anymore, but you could create a race condition of starting requests as user A, and then hammering requests as user B, so you'd end up mixing up the permission contexts of these users. Because the passwd entry that had been released back to the pool was overwritten, and then re-read with the value from another context.
The necessary line of thinking tends to be very different from thinking about program code regularly.
Out of interest - what models are you using for this? GLM?
From experience OpenAI and Anthropic have pretty heavy safeguards in recent (public) models.
Mixture of GLM 5.3 cloud, and local Qwen 3.8 FN on Strix Halo.
been doing exactly this lately with camera firmware and yeah the circles thing is real, but im pretty sure its a feedback loop problem, not a model problem
the model spins because it cant test its own guesses. what fixed it for me was emulating the actual device. qemu with the vendor rootfs, real binaries running, and then every claim becomes checkable: did the daemon actually parse my input, which uid is it under, what does its own log say. once it can check things it stops guessing, getting qemu to actually boot the thing was its own little hell though, took more tries than i want to admit.
the other thing i learned the hard way: most static findings die on reachability, not on exploit primitives. so i run them in the emulator first and kill the unreachable ones cheap, before spending any time on heap work
on heap vs stack, i think that intuition is desktop shaped. device userland usually has weak or no mitigations, heap uafs are way more tractable there than youd expect
If you really learned anything you should post your own thoughts, not whatever this lowercased Claudish is.
Oh yes definitely seen the reachability problem!
Good ideas on the QEMU. I guess you’d have to patch the binary if it’s expecting particular hardware etc?
Not sure what you mean by “desktop shaped”?
Can you give a concrete example of UAF on heap? I’m learning a bit on how this is done, and eventually recognised the LLM is doing something called heap spray. But that seemed to rely on hoping some object you wrote just happened to get interpreted by some process. And that was the “no, wait, pointer f isn’t y” loops.
[flagged]
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.
You would be surprised. A lot of cheap consumer routers are have two or four ARM cores. The bigger issue is that they are typically running a kernel from the stone age (< 6.0.0). Sometimes a still-supported LTS kernel like 5.10 or 5.15, but then they stopped at an old patch level.
Heck, apparently even the new Unifi UCG Fiber is running 5.4.213 (September 2022), but maybe they backport some fixes?
[1] https://community.ui.com/releases/dd0283dc-bf71-4140-ae1d-c1...
Note that even the latest OpenWRT is vulnerable to this, I'm running OpenWRT 25.12.6 and the kernel version is 6.12.112
IIUC it doesn't have any listening sockets open on WAN by default at least?
I do see sockets listening on all interfaces, but those are blocked by the firewall.
They'd also need to MPTCP right?
Not according to the article, which says the vulnerable path runs "during the TCP handshake, ..."
I’m in the market for a new router. Got a unifi u7 pro for wifi already, what are the options for routers? Sounds like the only safe thing is to roll your own so you can update things on time.
If you wants something with a nice web interface, probably OpenWrt [1] or OPNsense?
[1] Yes, it seems that they are still on 6.12.112, but they'll probably roll out an update quickly. Also see: https://forum.openwrt.org/t/cve-2026-98432-kernel-update-or-...
If you have a separate WiFi AP running your own router on your *nix of choice is quite achievable. I use NixOS since I use it everywhere else, if I didn't I'd probably go with OpenBSD.
My $50 router has two cores.
Those routers probably have 20 other critical un-patched exploits ...
An entire ecosystem of malware crawling and cohabiting in them.
Linux noob: I run a small VPS for a low stakes side project that runs Caddy and a Go backend that I've shutdown for precaution. Once a Ubuntu patch is made available, I read that applying the patch and reboot will be enough, but how can that be the case if someone used the exploit to break in and leave a rootkit or something like that? What are your full recovery plans for these situations?
If you don't already know and need to be sure, you have to start over with new hardware in a new network with new secrets. Firmware may be compromised and traces covered up, so reinstalling the operating system is not guaranteed to get the attacker out, nor can you trust the system to tell you if it was compromised or not. Your best bet would have been to record all incoming network traffic to a system only accessible offline and use it to verify no one tried to get it. Otherwise you can just hope, which is what mostly everyone will do, and will mostly be alright, because they're not important enough.
If you haven't rebooted yet then you can check how many mtcp handshakes you've received. It takes a lot of them to exploit this. 48 minutes according to the disclosure. So if it's a small number you haven't been hacked. Use "nstat -az | grep -i mpcapable"
If it's a small number it's even worse. Then you have still been hacked but are also dealing with an APT instead of just some mundane noisy botnet.
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.
I went on a security kick early this year, locking down everything as much as I could. Build your systems with the assumption that you WILL get hacked. Limit blast radius. Be prepared.
The next few years will be crazy, but you're right, we'll come out the other side more secure than ever before. Just gotta make it that far!
Will be interesting to see, if AI will cause an increased demand for sysadmins. Not sure companies will go "Make no mistakes" on their (production) infrastructure.
> If they all get found we exit the other side more secure and reliable.
I agree, but as yet we have no idea how much pain we have to pass through to get to the other side.
I wonder if switching to openbsd for my servers soon might be a good idea...
On the other side we have a Linux networking stack written in Rust.
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)I've been thinking about this too; it's high time we put the capital-E Engineering into software engineering.
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?
How does your internet work, if the firewall doesn't accept incoming packets?
It accepts packets for established tcp connections, that is opened by a device on LAN.
I am surprised formal verification efforts of the Linux kernel didn’t find this. Any experts care to chime in?
Is OpenWRT affected? Because that would be a real fawkin problem.
OpenWrt doesn't open ports by default so I think the impact is minimal, unless this can breach nftables as well. CGNAT also mitigates this as a side effect.
If you have services open on the IPv4 net however, close them immediately as a precaution.
How do you plan on reopening them again after you've closed 443 and 22?
Admin interfaces should never have been exposed publicly in the first place (and aren't by default). Remote admin over wireguard or sth if you must.
Use IPv6
As much as I hate to link to this site, this particular sub is very good:
https://www.reddit.com/r/openwrt/comments/1xka85h/is_the_ope...
They say 25.12-SNAPSHOT has it fixed
Who says that? Please link the exact comment.
Edit: I see now which comment you mean:
https://www.reddit.com/r/openwrt/comments/1xka85h/comment/19...
The `-SNAPSHOT` build is the pre-release build. Can be downloaded e.g. on https://mirror-03.infra.openwrt.org/releases/25.12-SNAPSHOT/...
To more easily find your model you can use
https://firmware-selector.openwrt.org/?version=SNAPSHOT
which selects "SNAPSHOT" in the right dropdown box.
Note that this gets you the lastest `master`, not e.g. the 25.12 branch, and may also wipe the OpenWRT UI package (LuCI). If you want to have the "25.12-SNAPSHOT" mentioned above, use the fimware-selector to find your device, note its "Platform" (e.g. "mediatek/filogic" for my OpenWRT One), and browse to that target platform in the URL, e.g. https://mirror-03.infra.openwrt.org/releases/25.12-SNAPSHOT/... The `*-squashfs-sysupgrade.itb` packages from release-SNAPSHOTs should also not wipe LuCI, I think. But it would likely still wipe installed packages.
If you want to just upgrade to 25.12-SNAPSHOT, without losing any installed GUI or packages, use the CLI:
There doesn't seem to be a way to do the same from the LuCI web UI, unless you're already on a snapshot release.More details below:
Apparently for the Linux 6.12 series that OpenWRT uses it's only fixed in 6.12.113 (see https://news.ycombinator.com/item?id=50322061).
But the latest OpenWRT release has an older version, 6.12.112, as per https://openwrt.org/releases/25.12/changelog-25.12.6. And the release notes https://openwrt.org/releases/25.12/notes-25.12.6 do not mention CVE-2026-98432.
I checked OpenWRT git (https://git.openwrt.org/openwrt/openwrt/log/?h=openwrt-25.12) and the commit "kernel: bump 6.12 to 6.12.113" is only 40 hours old, and NOT released in an OpenWRT release: https://git.openwrt.org/openwrt/openwrt/commit/?h=openwrt-25...
FWIW if you're stuck on 5.4 (e.g. Ubuntu 20.04 GA) for any reason, the 5.10.272 patch applies cleanly. There is only one function (skb_csum_is_sctp) missing in skbuff.h that needs to be added in, otherwise everything builds just fine.
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 difference between now and next year is that we won’t have time next year to patch before malicious agents use this exploit against everything at lighting speed. Global internet downtime will be the only solution.
You just made some people very excited and happy.
Just to add a data point: we added an edge router rule to drop inbound IP packets with options set. Interestingly a) that rule has a hit count of zero so far and b) it was somewhat tricky to test because it turns out every host I could think of to run an nping command from is on a network that filters the packets anyway. Or perhaps our upstream provider is doing the filtering. I had to send packets from a machine where the path didn't go through anyone else's router in order to see hit counts increasing and thereby test the rule.
Without a test-case, read POC, how do I verify if my server is affected?
This particular page (and other pages at altasum.net) is a CPU hog.
It usually means: suspicious activity or poor taste or disregard for web standards, or a combination of these.
There is a plenty of information on that CVE from other places.
would be funny if this page is used to attack servers
MikroTik routers seem affected but mitigations are available.
Watch your Linux systems for kernel updates. Reboot!
If you use sysctl to disable mptcp, you need to do that again after each reboot.
If I am reading this right, Slackware 15.0 is already fixed:
You’re still on slackware? I’ve not thought about it in years! How’re things over there?
It works mostly fine, pretty easy to work with, might perform well when you're sleeping / not around, packages are old (not neccesarily a bad thing). The default kernel is vintage 5.15, so just compile your own. Also elilo really sucks so bring your own bootloader while you're at it.
What is a "multipath TCP listener"?
A listener is a piece of software that advertises itself as available to inbound connections. You can do this on a variety of protocols.
Multipath TCP is a neat trick that allows a single TCP connection (TCP = Transport Control Protocol, a stateless protocol for long running connections) to use multiple physical interfaces. You could do something similar before MTCP using bonding, but this was annoying to set up and usually required application level code to efficiently use the bonded connection. MTCP makes this much simpler from an application level point of view and it can use widely diverse underlying transport layers at the same time (for instance, WiFi, Cellular and wired connections).
> Transport Control Protocol, a stateless protocol
TCP is stateful by definition, and that is why it supports robust error correction and reliable streams of data. UDP is its stateless counterpart.
> bonding, ... usually required application level code
No, it doesn't. https://en.wikipedia.org/wiki/Link_aggregation
> underlying transport layers
TCP is in the transport layer! The layers which you name are lower, such as Layer 2 (Data Link)!
MTCP, being in the transport layer, is working at a higher level of abstraction than bonding or link aggregation. There is no need for application-layer support, but it is possible, and easier, with MTCP than with the Layer 2 solutions, because MTCP is in the transport layer. That is why Go was able to activate it, and the POC uses it, because MTCP controls can be exposed at that level.
Sorry, total failure on my part I meant to write 'stateful'.
AI slop reply
I wish. No, that was me at 5:30 in the morning after a long night of hacking when I really shouldn't be commenting on HN about anything more complicated than screwdrivers. I use AI but not to write.
See https://en.wikipedia.org/wiki/Multipath_TCP
It's an extension to TCP that, similar to QUIC, allows you to use multiple address/port pairs to transmit data over a single logical stream. Both client/initiator and server/listener have to opt into the extension. This might need to be enabled explicitly by the application[1], which Go apparently does for you, or judging from other posts may be enabled by default systemwide, depending on your platform.
AFAIU, a major user of MPTCP is Apple and the iPhone, and the ubiquity of iPhone clients motivated implementation in and deployment on Linux servers.
[1] https://docs.kernel.org/networking/mptcp.html#sockets-api
I had to look it up too since I hadn't heard of it. It's an extension to TCP that allows responses across different NICs. Sort of like Link Aggregation on to a switch, except it can go out dissimilar interfaces, like your wifi connection and your hardwired connection. Looks like you have to opt into it when you set up your socket: https://docs.kernel.org/networking/mptcp.html
You have a Wifi network interface and a wired Ethernet one, multipath is somehow combining the two together.
In addition to aggregating, it can also be useful in cases where one link is much slower or higher latency. For example, if you're sitting in your driveway trying to get directions in maps while your phone is still on your very weak wifi network, it's a better user experience to have it to attempt the request using both radios concurrently so that it can fallback to cellular without waiting for a timeout/connection error if you're too far for wifi to actually work well.
Do apps actually use this possibility though?
MPTCP is an extension that requires cooperation. So it is only supported if the network stacks of both peers and all middleboxes can support it. The Linux kernel docs describe it as "opt-in", so it is not enabled by default for every socket opened on the system.
Again, the description of this CVE indicates that the vulnerability does not depend on MPTCP. But it is a factor in the proof-of-concept and its likelihood of success.
So if there was any widespread mutual support of MPTCP, it may shrink significantly as network admins deploy mitigations.
If you run caddy it's written in go so probably listening on an mtcp socket meaning you are probably vulnerable. Watch out!
This saddens me since MPTCP is quite useful and not the cause of the bug, just a way to ease exploitation (probably simpler heap massaging? Way over my head). Anyway, upgrade, but don't block MPTCP; no exploit is available, and it's just as likely someone finds another path before Anthropic releases theirs.
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 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.
Add the below rule onto your machine's /etc/ufw/before.rules to mitigate it.
Any value >5 in this field means ip extended header options and so values of 6 through 15 should be dropped. Note that I don't just drop syn packets like the mptcp exploit because any tcp packet could do it in theory.This works for me on multiple servers and home desktops and my hardware linux firewall/router. I did it a couple days ago when this was first announced. The iptables counter for matches haven't gone up at all on my VPS servers that gets lots of traffic. The counter only goes up when I manually trigger it to test. Everything continues to work nominally with these in place.
Thanks a lot! I had a similar rule but miscalculated the options header positions. Yours works.
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.
There is zero context, zero information, very alarming language but nothing about mitigation factors.
This is a terrible way of communicating vulnerabilities.
> Anthropic says Claude built a remote root exploit for servers with a multipath TCP listener. It hasn't published the exploit.
Bro, we've gained a root RCE with this vulnerability. No, you can't see a PoC, just trust me bro, we have a root RCE, also buy our IPO pls bro.
> No, you can't see a PoC
Surely you understand why they wouldn't want to publicize a PoC, right?
Every time Anthropic limits what we can do, I start switching more of my process to open weights.
Planning with Claude, implementation with Kimi.
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.
Unfortunately that kernel has some regressions, so they are holding it, I think
I was sorely tempted to fully bypass the kernel for networking before, and this isn't exactly giving me warm fuzzies for staying.
Weird, front page >500points today; flagged to death last week.
If you run a custom kernel chances are you're not affected:
# CONFIG_MPTCP is not set
This is misinformed and dangerous advice, MPTCP is not a requirement. You would need to block all TCP packets with any IP options set to fully mitigate this. Thankfully iptables/nft can do it.
Yup, was nice to see on my gentoo system. And then this amusing tweet from the grsecurity guy: https://x.com/spendergrsec/status/2116602388471758887
What does this enable an attacker to do exactly? RCE? DoS? Unknown?
RCE as root
[06:00]
Oh joy.
Is Traefik affected?
Nothingburger as per usual
[dead]
[dead]
[dead]
How are people finding Fil-C? It's designed to avoid things like this.
It might be bit of an effort to get Fil-C compiling the Linux kernel. As I understand it, it would amount to running garbage collector in the kernel, so some care would probably need to be taken to ensure it doesn't stop things at the wrong time, e.g. interrupts.
Does it support writing kernels?
Who wrote the bug? Very likely someone at Redhat.
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).
With only 0.5% of Rust code in the kernel, this does not say much. The binder thing seems to be the only real Rust component so far, and it also mysteriously already had a race condition despite it being impossible to do such mistakes in Rust.
That's such a bizarre claim to make. The Rust manual explicitly says that it doesn't prevent race conditions.
It does not not claim to prevent all race conditions, but it should prevent data races, and this binder bug was a data race.
Are you talking about CVE-2025-68260? That involved code in an `unsafe {}` block.
Rust doesn't guarantee that code in `unsafe {}` blocks is safe. This is also covered in the manual.
I know. Without "unsafe" you would not get far in systems code.
Then it sounds like it should not have been so mysterious to you after all.
Indeed, I tried to draw attention to the fact the Rust that eliminates a whole class or errors and the Rust that competes with C in systems programming are not identical languages, but the original comment I replied to assumes exactly this.
maybe
i’d focus on writing new stuff with rust though, not rewriting old stuff
and time will tell whether it actually reduces bugs or just change the failure modes to something else
also C will always be there in some way or the other, at least in conventions and syntax
Get rewriting, soldier!
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.
Wrong. Every kernel from 4.4 onward is affected until the fixed releases (5.10.272, 5.15.223, 6.1.190 and so on).
Right. The "Affected Products" section on https://nvd.nist.gov is absolutely useless and highly misleading. I don't understand how this can be the case for something so security critical.