158 points oger 2 hours ago 75 comments
voidfunc 1 hour ago | parent
mrob 1 hour ago | parent
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.
dist-epoch 1 hour ago | parent
An entire ecosystem of malware crawling and cohabiting in them.
microtonal 1 hour ago | parent
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...
wiskinator 1 hour ago | parent
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.
dist-epoch 1 hour ago | parent
grey-area 1 hour ago | parent
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.
dist-epoch 1 hour ago | parent
I was talking about the Anthropic blog post, only Go/Caddy enable multipath TCP listeners by default.
grey-area 1 hour ago | parent
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.
dist-epoch 1 hour ago | parent
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.
grey-area 1 hour ago | parent
cataflam 1 hour ago | parent
no idea, but at least Tailscale and Caddy were opening MPTCP sockets on servers I checked.
theteapot 1 hour ago | parent
dist-epoch 1 hour ago | parent
sweetjuly 1 hour ago | parent
cowlevel 39 minutes ago | parent
Noxwizard 1 hour ago | parent
wahern 1 hour ago | parent
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
jacquesm 1 hour ago | parent
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).
swinglock 1 hour ago | parent
Shank 1 hour ago | parent
Flockster 1 hour ago | parent
https://forum.proxmox.com/threads/cve-2026-98432-in-proxmox-...
tlamponi 59 minutes ago | parent
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...
kev009 25 minutes ago | parent
gadtfly 24 minutes ago | parent
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?
throw0101d 20 minutes ago | parent
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".
Shank 1 hour ago | parent
> 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-...
sebmellen 1 hour ago | parent
gwbas1c 1 hour ago | parent
wtch98 47 minutes ago | parent
daemonologist 1 hour ago | parent
ogogmad 1 hour ago | parent
cowlevel 39 minutes ago | parent
_flux 32 minutes ago | parent
jmclnx 1 hour ago | parent
% uname -a
Linux XXXX 5.15.223 #1 SMP PREEMPT Thu Oct 22 00:03:07 CDT 2026
x86_64 Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz GenuineIntel GNU/Linuxcyberpunk 4 minutes ago | parent
api 1 hour ago | parent
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.
grey-area 1 hour ago | parent
AdrianCX 1 hour ago | parent
codegeek 19 minutes ago | parent
"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."
throw0101d 17 minutes ago | parent
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.
peanut-walrus 1 hour ago | parent
- 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.
wahern 1 hour ago | parent
That doesn't track. Apple iPhones are a major user of MPTCP and they report the majority of requests supporting MPTCP, IIRC 70+%.
peanut-walrus 1 hour ago | parent
tptacek 38 minutes ago | parent
gadtfly 1 hour ago | parent
eterm 53 minutes ago | parent
marcosscriven 1 hour ago | parent
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).
kstrauser 1 hour ago | parent
fguerraz 51 minutes ago | parent
marcosscriven 45 minutes ago | parent
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.
cowlevel 44 minutes ago | parent
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.
wiml 9 minutes ago | parent
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.
lakeviewterrace 1 hour ago | parent
ronnier 1 hour ago | parent
https://www.reddit.com/r/openwrt/comments/1xka85h/is_the_ope...
They say 25.12-SNAPSHOT has it fixed
lunar_rover 1 hour ago | parent
If you have services open on the IPv4 net however, close them immediately as a precaution.
basilikum 14 minutes ago | parent
bana-io 59 minutes ago | parent
lakeviewterrace 54 minutes ago | parent
rurban 49 minutes ago | parent
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.
pizza234 42 minutes ago | parent
geye1234 48 minutes ago | parent
winwang 7 minutes ago | parent