- cross-posted to:
- linux@lemmy.ml
- cross-posted to:
- linux@lemmy.ml
Every Go application since 1.24 will activate MPTCP on their sockets by default.
And I’ve read that this includes Syncthing, which is why I’m posting this here
You must log in or register to comment.
Does unattended upgrades fix this on Debian? Or do I have to reboot now for it to take effect?
Depends on your settings. You need to reboot for kernel upgrades, so you’re good if you have automatic periodic reboots configured and kernel updates applied unattended.
Could everyone stop blowing holes in things please, spent all yesterday rebuilding internet facing servers.
On the plus side, everything will be up to date. So there’s that
Also with both this kernel and the php thing, Debian had a fix way before the big corporations. Even Amazon
This is shady as hell. It’s an AI company again (Anthropic), they do not follow rules of responsible disclosure (again), it’s a race condition again, they do not provide a proof of concept (obviously since they shouldn’t talk about it at all until after we got the patch) but instead create big media fuzz about their glorious AI… hell, they do not even tell us the kernel versions or anything.
If we find out eventually that you have to disable default mitigations for this to become dangerous (like the stunt they did with Firefox) it’s too late, the media won’t give a shit anymore. Like we just had with PHP - huge panic, enormous media circus, barely any real-life consequences in the end and the responsible disclosure process being a total mess to blow it up even more.
Honestly, every time I see some AI company hyping yet another huge and super dangerous exploit only their superior AI found “after X years of nobody seeing it” I now expect a nothingburger.
We’re probably fine, nothing out of the ordinary to see here.
The Php vulnerabilities were and are being exploited in the wild
For server crashes, but not for RCEs. The only proven case of this I know of was with a specifically prepared PHP instance as honeypot that had an optimal attack surface and was done by Perplexity (another AI company). Outside of that there’s no credible large-scale RCE exploitation that’s any worse than the bugs that get fixed on a daily basis. It doesn’t even remotely justify the panic and media frenzy.
it was merely dangerously exploited by AI bros.
Network devices were getting popped. NAS were also.
I agree the media frenzy was overblown but it seems legit at this point.
They found a previously unknown vulnerability and it was fixed:
“This vulnerability (CVE-2026-98432) was patched upstream and backported to all maintained stable kernel branches.”
This is good no?
Not saying fixed bugs aren’t good, I’m just so fed up with this marketing-driven fearmongering. They’re overhyping every god damn bug they can because they know most people won’t know how bad it actually is. They do worse security practices than most homelab enthusiasts and then prophesize the AIpocalypse because their linear algebra “escaped” (the door was wide open). Hell, they don’t even manage to understand proper bug disclosure practices. They’re playing the “Social” Media outrage game on a global scale to drive sales and everyone is suffering for it. I’m so, SO done with all of this bullshit. When the bubble finally crashes I’ll throw a raging party with blackjack and hookers.
Is it known if/ when Ubuntu is going to provide a fix? https://ubuntu.com/security/CVE-2026-98432 Rn the page states: work in progress for a fix.
Someone rated the issue as 9.8.Other distributions provided a fixed kernel package 10days ago. Some say, Ubuntu engineers do not rate the issue as critical. But there are exploits available which prove a DoS. Not sure if the RCE with privilege escalation has an exploit yet and under which circumstances the RCE works. Is a golang service required? Are other services affected - is multipath TCP sufficient? Does the issue affect ipv6 too?
DoS isn’t that bad. RCE with root + an exploit on the other hand. Um…
From what I read about regarding the PHP vulnerabilities, the RCE was extremely difficult to pull off. I’d guess it’s the same here, at least until some non-AI companies weigh in, since these AI companies tend to distort the reporting and severities quite a bit.
Thank you.
Difficult as in unlikely that the exploit works or difficult to write an exploit? The latter doesn’t help me much. :)
Regarding the php2shell issue: a lot of admins took their services down until it was patched. It’s more a decision based on a guess - big number bad, evil acronym scary - than actually understanding what the exploit does. One can either believe it or not.
And that’s the thing about the recent exploit (multipath TCP): I can’t evaluate myself, whether the issue is likely an exploitable RCE. That is one factor missing in risk assessment: is the outcome potentially fatal? Yes, rce and priv escalation. Is it likely? I can’t tell.
I’m sorry. I don’t mean to doubt your expertise. I simply don’t know you. It is the same with hackernews, the author repeats what he’s or she’s told. (Good overview article though. Thanks again for it.) RN It’s: Someone from the internet said don’t panic. A link to a statement from the Ubuntu package maintainer or distribution would make me feel at ease. I still couldn’t make sure for myself - a lack of time and competence in the field - but I would trust it.
Difficult as in unlikely that the exploit works or difficult to write an exploit?
Difficult as in it’s a race condition that can theoretically be exploited when you get the timing right. But timing, if it’s not on a well-known isolated system right before you in some lab, depends on a million details, some –once we are talking about real-life examples– outside your control.
