221–230 of 370 posts
Earlier quoted context omitted.
So you think someone is going to break into your house, find your default credentials somehow and get root access?
With physical access, root access is as simple as setting init=/bin/bash in the kernel parameters from a bootloader. No need for credentials or anything.
This again does not work under Android, at least in termux compiled with clang/gcc.
Android has a lot of hardening and sandboxing that desktop Linux doesn't (and won't for UX reasons).
https://durovscode.com/google-android-security-update-warnin...
Earlier quoted context omitted.
The fix has been commited to the git tree for the `netdev` linux subsystem fork. That's how it was noticed by the grsecurity guy who published an exploit. Then, it will be merged by linus either into a RC/master for the next linux minor version release, or into the patch releases branch by GregKH/Sasha for already-released versions. Or in this case, both, because it's a security fix.
Spender didn't publish any exploit afaik
https://xcancel.com/encrypted_past/status/205240982299839296... https://xcancel.com/encrypted_past https://github.com/0xdeadbeefnetwork https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boo...
Earlier quoted context omitted.
"proper read-write mode" for the input fd is reading only. The exploit is writing to the splice() input fd. Also, NB, I said permission check, not mode check. The input fd to splice can and will be open for only reading quite often. Doesn't mean the kernel can't still do a write permission check. (Except I didn't say that here. Oops. Getting confused with my posts.)
OK, I may likely have too much sleep debt to understand, but given the bug is that splice can write to the input fd, you're suggesting maybe splice should only let you use an input fd if the process has access to write to it? But splice is a more or less a generalization of sendfile, and sendfile is often used for webserving where the serving process does not have ownership of the documents it is serving. It doesn't…
Not really, splice(2) is actually more limited, it's an optimisation for reading and writing data between files and pipes without needing to make copies.
sendfile(2) works with any fds because it just exists to remove a fair bit of the copy overhead when doing a userspace read/write loop, but it does actually do a copy.
Anyone here with experience providing multi-tenant Linux systems (CI and the like), do providers usually disable kernel modules they don’t need to eliminate attack surface? Every time one of these comes out I wonder if I should be rotating every key in my GitHub CI or PaaS host. So far I haven’t seen any reports from the providers I use that they were pwned by any of these exploits.
At this point, a microvm can be booted in ~200ms so you don't even have to keep a warm pool, you can just launch em on demand.
GitHub CI (actions) uses virtual machines.
Earlier quoted context omitted.
Unfortunately that is not what they proposed. To stretch the automotive analogy too far, you could say: if you invite a carjacker in, their seatbelt is not going to stop them from carjacking you.
"Avoid shared-kernel attack surfaces" is not an unreasonable proposition in 2026.
If this indeed works on all major distributions, I just continue to be amazed by how irresponsible the maintainers are. We're talking about optional kernel functionality that's presumably useful to something like This feels like the practice of Linux distros back in 1999 when they'd ship default installs with dozens of network services exposed to the internet. Except it's not 1999 anymore.
Today it's 0.1%, tomorrow it might become 100%. User demand is hard to anticipate, so it's reasonable to include small features that don't cost a lot to run by default.
It's not ideal, but you really don't want to prevent user from finishing their task, because maybe then they'll just give you a bad name and switch to another distro.
That's to say, it's not "irresponsible", it's reasonably maximums (at least trying to be).
This is very similar in root cause and exploitation to Copy Fail. Which illustrates pretty well something that's lost when relying heavily on LLMs to do work for you: exploration. I find that doing vulnerability research using AI really hinders my creativity. When your workflow consists of asking questions and getting answers immediately, you don't get to see what's nearby. It's like a genie - you get exactly what yo…
Very much aligns with my experience. For me this is the most unsatisfying thing about AI-based workflows in general, they miss stuff humans would never miss.
All the time I wonder what am I missing that's right nearby? It's remarkable how many times I have to ask Claude code to fully ingest something before it actually puts it into context. It always tries to laser through to target it's looking for, which is often not what you want it to look for, at least not all you want it to look for. Getting these models to open up their field of vision is tough.