121–130 of 370 posts
Earlier quoted context omitted.
The commit for the fix was public. Someone noticed. An exploit was published.
I think I read on the bug's website that "No fix has been released". I understood that as there is no public fix, but maybe it only means it's not in a tagged version of the kernel and no hotfixed distro kernels have been released?
I'm curious what broke the embargo. Did it leak or did a third party find it independently?
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.
Distro maintainers blacklisting specific functionality because they believe YAGNI is a pretty big ask. They just don't know who is using what. It's always possible for users to go back and tailor their builds for the stuff they actually want. And... I remember the early days of Linux where I ran `make menuconfig` and selected exactly the functionality I wanted in my kernel. I'd... rather not end up back there. That s…
Well, because you probably don't, and it's a security risk, so no need to put millions at risk for the benefit of that one person who wants to tinker with packet radio or whatever. Similarly, it would be prudent for distros to not allow autoloading of modules that are extremely niche while giving a simple way to adjust the settings if you want to. God knows they have plenty of GUI configurators and config files already.
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.
It also saddens me greatly, imagining what computing could look like if systems evolved differently.
Earlier quoted context omitted.
Android has a lot of hardening and sandboxing that desktop Linux doesn't (and won't for UX reasons).
> desktop Linux doesn't (and won't for UX reasons) Can you elaborate?
Imagine if Linux only let you run stuff from Flatpak, and if stuff didn't work in Flatpak then too bad for you. Most Linux users would hate it and it would be a mess a lot of the time, so, for user experience (UX) reasons, they don't do it. Android can get away with it because that's been the app paradigm for decades now.
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.
It’s not enabled by default. It’s an optional module that is loaded on demand. The entire setup of the kernel promotes compiling in the core set of things your users will need and offering basically everything else as a module to load on demand.
Earlier quoted context omitted.
AFAIU, Linux and the BSDs have basically the same architecture - the BSDs just value secure and simple, understandable code more highly than Linux vs features and performance.
This is really not a correct statement beyond the fact that both are a type of Unix.
Does anyone know whether Debian is vulnerable? I tried the exploit on a Debian 12+Debian 13 machine but wasn't able to reproduce it myself.
Earlier quoted context omitted.
It absolutely is Linux, and yes the JVM could absolutely run on something else. But it is Linux and you can run Linux binaries directly on it - that just isn’t how it is used by end users.
No you cannot, the NDK has a specific set of oficial APIS, and the Android team feels in the right to kill any application that doesn't follow the law of Android land. Some folks like the termux rebels, occasionally find out there is a sherif in town. > As documented in the Android N behavioral changes, to protect Android users and apps from unforeseen crashes, Android N will restrict which libraries your C/C++ code…
- Is totally Linux