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

all 25 comments

sorted by: hot top controversial new old
[–] 41 points 1 week ago (5 children)

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

  • source
  • hideshow 5 child comments
  • [–] 4 points 1 week ago (3 children)

    rebuilding internet facing servers

    Because of one vulnerability?

    Jebus. Response at one site was a 10-minute thing and then letting cron do the work.

    Where the hell is your D-R? I worry you've made some very non-optimal decisions in the past and are taking on way too much work now.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 6 points 1 week ago (2 children)

    It took longer than planned as we are in the process of getting everything sorted for quick rebuilds, most of the time was waiting for GitHub to not poo it's self.

    If we had everything in ansible it would be 5 minutes

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 1 week ago* (1 child)

    If we had everything in ansible it would be 5 minutes

    Ansible at the day-job takes about 45 min to do a patch. As someone who's used a fair number of alternatives, maybe consider anything else on the planet?

    But, seriously. The response to this particular sploit wasn't really "config management"-y. It was a simple process that cron generally handled anyway, and network segregation and firewalling allowed us to prioritize easily. My worry is that there are some core architectural decisions you may need to revisit in the post-mortem on this, because there may be some fundamental changes required to get sensible wins in the future.

    (If you're on containers, I weep for your validation challenges; also, get bazel)

  • source
  • parent
  • hideshow 1 child comment
  • [–] 11 points 1 week ago

    that's the point. you're supposed to be exhausted enough so that you just relent and let AI take over your duties.

    second objective is to showcase your incompetence to leadership so they are scared enough to replace you with AI.

    this is the plan.

  • source
  • parent
  • [–] 101 points 1 week ago (8 children)

    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.

  • source
  • hideshow 8 child comments
  • [–] 12 points 1 week ago (2 children)

    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?

  • source
  • parent
  • hideshow 2 child comments
  • [–] 28 points 1 week ago (1 child)

    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.

  • source
  • parent
  • hideshow 1 child comment
  • [–] -3 points 1 week ago

    They’re overhyping every god damn bug they can because they know most people won’t know how bad it actually is

    Where is Anthropic doing this? The one that finds the vulnerability are not the ones that assigns it a CVSS score. CVSS is calculated with a standardized format, and is not mean to be a measure of risk. So this is no the AI companies saying how bad the vulnerabilities are, but rather the owners/maintainers of the code.

    Hell, they don’t even manage to understand proper bug disclosure practices.

    Have you ever stopped to consider previous bug disclosure practices aren't as applicable? If anyone can find bugs using AI, then even if Anthropic or OpenAI finds a vulnerability, they can't know for sure they are the first. Even if they are the first, it's only a matter of time before the next people find it even if the first discovery was never publicly disclosed.

    There have also been countless bugs given directly to companies, and fixed without a big blow up or news spectacle. You didn't hear about those, because they didn't blow up. So you are going to have a level of confirmation bias.

    Why couldn't it be that there are just a ton of really bad vulnerabilities that have never been discovered until a tool like AI came by to find them? There is nothing special about Anthropic or OpenAI, they are just the fastest moving with this new technology. Why couldn't the bugs they find be just as bad as they are claimed to be, especially when severity is often not determined by the AI company anyway

  • source
  • parent
  • [–] 28 points 1 week ago (4 children)

    The Php vulnerabilities were and are being exploited in the wild

  • source
  • parent
  • hideshow 4 child comments
  • [–] 4 points 1 week ago (3 children)

    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.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 12 points 1 week ago (6 children)

    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...

  • source
  • hideshow 6 child comments
  • [–] [S] 8 points 1 week ago (1 child)

    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.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 4 points 1 week ago* (last edited 1 week ago)

    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.

  • source
  • parent
  • [–] 0 points 1 week ago (3 children)

    if you run Ubuntu as a server nobody should take you seriously.

    Debian literally exists as a server first while Ubuntu exists as desktop first.

    the only valid excuse to using Ubuntu server is if your hardware is a RPI or rpi-clone and at that point you're at a hobbyist level which makes more sense why you'd be using Ubuntu at all.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 2 points 1 week ago* (last edited 1 week ago) (2 children)

    if you run Ubuntu as a server nobody should take you seriously.

    May I ask: Why do you recommend to not use Ubuntu as a server OS?

    They offer a server version, provide LTS releases and there is a (limited) extended security maintenance program if one decides to use a distribution after the EOL of the LTS. Which led me to believe it was a viable option.

    I'm seriously interested in your insights.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 1 week ago (1 child)

    Ubuntu is notoriously finicky as a server. multiple issues with how system configuration is different from other servers like Debian, redhat, etc. firewall used to be an absolute terror. also, as described, your patch levels are tailored to the whims of a corporate entity that historically has sided with desktop stability and experience over server stability and performance.

    while we're at it, canonical captures and sells system information like Microsoft does. by using Ubuntu, you become the product. IDK how much you know about companies that sell their consumers data, but typically they put profits over security.

    I've worked for a handful of MSP/CSP vendors over the years and they only offer Ubuntu as a server option with one big caveat. you are responsible for the maintenance of the system. lo and behold, four years later they always come crying about how they're about to fail an audit because it's never been updated, or is misconfigured, or was hacked because they installed a bad library, ad nauseam.

    from my own experience using it, though aged, it came with a service that was listening on port 3306. was it mysql? nope. what was it? dunno. I killed everything on that system that wasn't required by the kernel. still listening. couldn't install a database on it, so it was wiped and I never used it again.

    simply put, Ubuntu is a desktop first OS. if you use it as a server you're going to have a bad time because statistically speaking only amateurs use it that way.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 6 days ago*

    Thanks.

    Firewall. Ufw works fine as long as docker isn't involved, which isn't a Ubuntu nor ufw issue.

    Information stealing: that's true. One needs to get rid of some bloat.

    1. What did the system itself say? Interesting. It didn't happen to me.

    Packet maintenance seems to be an issue when eol is reached. But this cve is the first bigger issue for me. Their efforts to build an own app ecosystem based on snaps is bothersome. Luckily there is no real lock-in. I can switch to Debian if needed. It just takes time.

  • source
  • parent
  • [–] 4 points 1 week ago (1 child)

    Does unattended upgrades fix this on Debian? Or do I have to reboot now for it to take effect?

  • source
  • hideshow 1 child comment
  • [–] [B] 1 point 6 days ago* (last edited 6 days ago)

    Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:

    Fewer Letters More Letters
    LTS Long Term Support software version
    NAS Network-Attached Storage
    RPi Raspberry Pi brand of SBC
    SBC Single-Board Computer

    3 acronyms in this thread; the most compressed thread commented on today has 4 acronyms.

    [Thread #155 for this comm, first seen 2nd Nov 2026, 22:20] [FAQ] [Full list] [Contact] [Source code]

  • source
  • 24 comments in c/programming@programming.dev view that post
    [–] [S] 29 points 1 week ago (3 children)

    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.

  • source
  • hideshow 3 child comments
  • [–] 21 points 1 week ago (3 children)

    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.

  • source
  • hideshow 3 child comments
  • [–] 14 points 1 week ago

    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.

  • source
  • parent
  • [–] 3 points 1 week ago

    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.

  • source
  • parent
  • [–] 49 points 1 week ago (4 children)

    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.

  • source
  • hideshow 4 child comments
  • [–] [S] 57 points 1 week ago (2 children)

    Because some have released updated kernels while others haven't

  • source
  • parent
  • hideshow 2 child comments
  • [–] 27 points 1 week ago (9 children)

    This specific issue would have been prevented with with Rust.

  • source
  • hideshow 9 child comments
  • [–] 3 points 1 week ago (5 children)

    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.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 4 points 1 week ago (4 children)

    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.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 4 points 1 week ago (3 children)

    Clearly, but it's worth pointing out that this kind of problem isn't uniquely fixed by "just use Rust".

  • source
  • parent
  • hideshow 3 child comments
  • [–] 2 points 1 week ago (2 children)

    I never said that only Rust prevents this. I just said using Rust in the Kernel would have prevented this issue.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 1 week ago (1 child)

    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?

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 1 week ago

    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.

  • source
  • parent
  • [–] 1 point 1 week ago
    12 comments in c/linux@lemmy.ml view that post
    [–] 38 points 1 week ago (1 child)

    On Linux, an application must request MPTCP when it opens a socket.

    Ah nothing to worry about.

    As of Go 1.24, Go programs do so by default for the sockets they listen on

    Fuuuck

  • source
  • hideshow 1 child comment
  • [–] 22 points 1 week ago (1 child)

    If you build your own kernel, the fix is in Linux 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3

  • source
  • hideshow 1 child comment
  • [–] 18 points 1 week ago (2 children)

    Debian was patched much earlier, how?

  • source
  • hideshow 2 child comments
  • [–] 27 points 1 week ago* (1 child)

    Mainline kernel devs applied the fix upstream on October 5, ten days before the CVE was published

    Debian's kernel team imports entire upstream stable point releases rather than backporting individual CVE patches into heavily patched kernel trees like some of the other distros. Once the fix shipped in the 6.12.113, 6.1.190 and 7.2.10 stable releases, it arrived in Debian unstable/sid as part of a routine version bump

    Then a day after the cve was published and marked as 9.8 (16th) Debian also patched the frozen versions like Trixie and bookworm

  • source
  • parent
  • hideshow 1 child comment
  • [–] 4 points 1 week ago

    Fedora is at 7.2.13 today, so all good (so long as dnf-automatic is doing it's thing and auto reboots are enabled).

  • source
  • [–] 2 points 1 week ago (3 children)

    Ai adoption is going great I see

  • source
  • hideshow 3 child comments
  • [–] [S] 14 points 1 week ago (1 child)

    of all the things i hate about LLMs, getting vulnerabilities in important software like linux discovered and fixed is not one of them

  • source
  • parent
  • hideshow 1 child comment
  • [–] 4 points 1 week ago

    Yeah. As horrible as LLMs are in many ways, finding vulnerabilities is something they're great at.

    It's absolutely a good thing that a good actor with an LLM finds a vulnerability before a bad actor with or without such tools.

  • source
  • parent