HN

Need help?
<- Back
CopyFail was not disclosed to Gentoo developer

CopyFail was not disclosed to Gentoo developer

ori_b

Comments (171)

  • xeeeeeeeeeeenu
    For context, the author of the linked post, Sam James, is a Gentoo developer.Anyway, this is a disaster. It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. Who knows how many shared hosting providers were hacked with this.It's also worrying that it seems there's no communication between the kernel security team and distribution maintainers. One would hope that the former would notify the latter, but apparently it's the responsibility of whoever finds the vulnerability.
  • semiquaver
    > Note that for Linux kernel vulnerabilities, unless the reporter chooses to bring it to the linux-distros ML, there is no heads-up to distributions.Why would they imply it is incumbent on the reporter to liaise with distributions? That seems to assume a high level of familiarity with the linux project. Vulnerability reporters shouldn’t be responsible for directly working with every downstream consumer of the linux kernel, what’s the limiting principal there? Should the reporter also be directly talking to all device manufacturers that use Linux on their machines?IMO reporter did more than enough by responsibly disclosing it to linux and waiting for a patch to land.Aren’t there people in the linux project itself with authority over and responsibility for security vulnerabilities? One would think they would be the ones notifying downstream distros…
  • whatevaa
    Stop blaming the reporter. Start asking kernel to fix their process. Linux kernel is no longer a toy project, it has full time employees employed by various companies. They should have handled notifying distributions. Not some rando.
  • GranPC
    Just for what it's worth, I just pushed an eBPF-based workaround for people who are running kernels in which AF_ALG is linked directly into the kernel and not as a module: https://github.com/Dabbleam/CVE-2026-31431-mitigationI am running this in production right now and it mitigates the attack, with no unexpected side-effects as far as I can see.
  • KingMachiavelli
    `nosuid` and probably `nodev` should IMO be the default filesystem mount options. `/dev` is already a special devtmpfs and the initrd minimal /dev can just explicitly mount the initrd tmpfs rootfs with `dev` and `suid` if necessary.Letting SUID binaries just "exist" anywhere is a stupendous security issue. What if you mount some external storage medium, how are you to verify that none of the SUID binaries on that block device are malicious.Additionally, this exploit appears to only work if the user executing the SUID binary can also read the SUID binary. There's no reason for non-root users to have read on a SUID binary.NixOS does this correctly. No SUID in the normal package installation directory `/nix/store` and no package leakage outside of that no `nosuid` can safety be used on all other mountpoints. The exception is just a single-purpose `/run/wrappers.$hash` directory that safety contains executable ONLY SUID wrappers.
  • lrvick
    Was not disclosed to stagex, and I expect a lot of linux distros. Thankfully we were already on kernel 7.0 so not impacted
  • swinglock
  • VladVladikoff
    Hey Xint Code / tylerni7 <https://news.ycombinator.com/threads?id=tylerni7>, maybe you should improve your disclosure process as well? Maybe make it mandatory for users of your tool?
  • ectospheno
    The Bleeping Computer link below mentions a potential remedy until a patch is ready.https://www.bleepingcomputer.com/news/security/new-linux-cop...
  • seniorThrowaway
    Ubuntu has patches out, tested before and after patching.
  • uberduper
    `initcall_blacklist` is a thing.
  • ChrisArchitect
  • JasonHEIN
    huh somehow seeing people not using ai to work is like wow moment which i cherish a lot these days