143
This specific issue would have been prevented with with Rust.
So could have Java, Go, C# or any language with GC. With garbage collection, the options object stays alive as long as any CPU holds a pointer to it, so use-after-free can't happen.
Besides, this exploit is so hard to pull off the only realistic outcome is a kernel panic, and that hasn't even been publicly demoed.
So could have Java, Go, C# or any language with GC.
No. Those aren't allowed in Linux Kernel.
With garbage collection
Garbage Collection is not usable in an operating system Kernel.
Clearly, but it's worth pointing out that this kind of problem isn't uniquely fixed by "just use Rust".
I never said that only Rust prevents this. I just said using Rust in the Kernel would have prevented this issue.
Fair enough. Don't you think it simplifies the issue a little bit? How long would it take to rewrite the entire TCP stack in rust?
I don't think a rewrite in Rust is necessary for everything that has a bug. Instead fixing the bug is probably more secure, before such alternative Rust code is mature enough to replace it.
Rust haters in shambles
Why are they calling out specific distros for a kernel issue? It's the kernel, it affects every distro using an affected release of it.
Because some have released updated kernels while others haven't
Maybe they should use better distros.
I use Arch, btw.
I use Arch, btw
Yes. We figured. Lol
I know the answer to that. It's in the article.
You can disable multipath TCP by issuing this command
sudo sysctl -w net.mptcp.enabled=0
persist across reboots with
echo "net.mptcp.enabled=0" | sudo tee /etc/sysctl.d/99-mptcp.conf
If your kernel is older than 5.6 then there is no multipath TCP to disable. e.g. Ubuntu 20.04 should be fine.
Tacking this on here to increase visibility.
You can see who is already listening to multipath TCP by running:
ss -Mln
running the sysctl command will prevent future ports being opened, but it will not close existing ones, you need to manually restart the services/containers.
Go applications enable the functionality in their ports by default.
My understanding is that a proper fix will come from a kernel update, since this affects plain TCP, but MPTCP has a known attack path.
Note: It's unclear whether this is an adequate mitigation.
The score sounds a bit overblown considering this is for MPTCP which is as far as I understand rarely used? And it sounds like the chance of this leading to anything more than a crash is low. But whatever.
It's a data race. Memory safety is still super important for security.
Every Go application since 1.24 will activate MPTCP on their sockets by default, so it's in fact quite widely used.
Many orgs consider the rating overblown. While the impact is devastating, the attack is hard to pull of.
They're able to issue shell commands as root.
IPv6 is not affected by this race because the kernel copies the options for IPv6 connections.
It's been a slow-going effort to get a compile flag into the kernel that disables IPv4, but this is precisely the type of bug which that flag would have avoided. When devices choose to natively use IPv6-only -- eg IoT -- they really shouldn't have to also accept an increased attack surface from Legacy IP, something that is increasingly unnecessary.
Disabling IPv4 when it's unneeded is good security posture, but such a choice is not available yet in Linux.
On every embedded including a few IoT devices I worked on, every single time the IPv6 is either outright disabled, ignored, or treated like IPv4 even when telling my client what they want is not how IPv6 is designed.
May not be the same everywhere, just my anecdotal experience.
Also remember:
The 'S' in IoT stands for security.
I've been doing this at home. So far, none of my phones or access points use IPv4. I should be able to get the desktops off it soon. Microsoft finally got it working in Windows after decades of (stalled) development.
I disable IPv6 to reduce the vector
Nice.
this post was submitted on 29 Oct 2026
143 points (100.0% liked)
Programming
29050 readers
619 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS