Tip: Install a Chromium flavor browser (Chromite) separate from the main browser.
Disable Javascript and hardware accelerated video decoder (commonly exploited) from the flags page and enable reader mode to fix broken JS-dependent websites when browsing blogs and random sites on your personal devices, else dedicate a tablet.
Thanks for testing, we currently only tested it on Pixel 10, but there are a few people on our repo creating PR to support other devices, you can take a look here https://github.com/NebuSec/CyberMeowfia
I've been noodling with porting the kernel exploit to other devices, and the exploit is very sensitive to how the compiler happens to lay out stack frames, which varies between kernel builds. Once you figure out the right "stamp method" and offsets for a particular kernel build though, it's fairly reliable.
Root for these RCs has been available under the guise of “FCC hack” for a really long time now; different groups have different exploits (it’s DJI so there are plenty) that work on different firmware versions.
Mostly they’re used to enable illegal RF parameters in Europe (FCC hack); DJI disabled strict geofencing in most of the “west” several years ago and that was also enforced in the drone anyway.
2. I saw some output from the execution of the POC.
However, after I went to <https://rootme.nebusec.io/b9e3f1a4-7c82-4d6e-9a51-2f8c4b3e0d...> the phone froze and refused to respond to any input. The only thing that worked was restarting, which I wonder how it works given the, I think, the kernel has hung. Does anyone know how the kernel is able to respond to events whilst the system has hung? The screen remains on with the partial output of the execution of the POC until the screen saver kicks in ...
The kernel is not a single-threaded process - a "kernel hang" is not a very specific description and you don't have a way to know that it happened anyway. The screen timing out is evidence that the kernel was largely working, actually. Of course if some data structure got corrupted it could have affected a specific essential part of the system, such as the touchscreen driver or the display compositor.
> Two boot looped, I had to enter recovery and the other just powered off [0].
Absolutely crazy that it is possible to brick someone's phone via an exploit but ... hey.
After the power off what happened? Do things seem normal?
When it entered recovery mode where you able to get the phone in a clean state again? I take it that you did?
I'd really like to run this but I, ideally, do not want to run something random from the internet. It's a shame there is no `Dockerfile` to build this exploit/POC. All I want is LPE to `root` on a Samsung (Snapdragon) phone.
Not really. Generally we use "Local Privilege Exploit" to describe an exploit that goes from a reasonably normal user privileges to root privileges.
And we don't usually worry about them, because an application with normal user privileges can already to so much damage.
But this exploit can be triggered from inside a tightly sandboxed process, such as firefox's isolated browser process. Which means the attacker now only needs to chain two exploits together: One javascript exploit to get local code execution in an isolated sandbox, and this one to jump all the rest of the way to kernel mode.
Which means, you should update both firefox, and your linux kernel.
Realistically, if you have a browser sandbox, the system LPE exploit gives you very little more. Everything interesting on a desktop system is accessible by the user account directly.
They are a security boundary. The fact that you need a vulnerability to escape them is proof of that. They just don't have a particularly high cost of escape because reachable kernel vulnerabilities are so common.
I don't think this would change anything even if it were true, which it is not. Running as root in a container opens up tons of footguns but it is not a path out of the container on its own.
If you are given a shell with `docker run -it --rm alpine:3 sh`, can you read the /etc/shadow on the host without kernel exploit? Assuming the docker and kernel are sufficiently update-to-date (e.g. latest Docker on Debian Stable).
Does Docker use user namespaces by default? Otherwise root in the container is actually root on the host, from what I read. Correct me if I'm wrong.
(Privileges are still limited by seccomp filters blocking some syscalls, and there's SELinux to block some other stuff, but it's still the actual root user without user namespaces, I think?)
That's right. Docker still runs without user namespaces by default, which means that root is the same user inside and outside of the container. This does open up attack surface and configuration footguns.
Confinement still leverages dropping some root caps, seccomp, various other namespaces, etc.
There are a million ways to load a kernel module from inside of a container into the host kernel (ie: to trigger a load), but seccomp/ linux caps will block the direct ways (as another commenter notes).
Root is not just one thing on modern Linux, almost all in-kernel privilege checks are now gated via (slightly) more fine-grained capabilities and the default capability set for Docker containers disallows module loading (CAP_SYS_MODULE) and the relevant syscalls (namely (f)init_module) are also blocked with seccomp.
People still should use user namespaces (and tools like Podman and Incus do by default) but basic stuff like that is not the reason.
Presumably Docker's seccomp profile [1] blocks the init_module system call which is used by insmod [2]. Although, looking at the default profile, it seems to explicitly allow it - but maybe only if you have CAP_SYS_MODULE, which I think means running Docker with "--cap-add=SYS_MODULE".
Hmm. Either I've lost my mind, or you're running a different Docker than me, or you're thinking of some strange scenario such as a Mac where docker is actually inside a VM, or you're wrong.
While there is a feature to do with UID mapping, it doesn't actually work/isn't usable/nobody uses it in current docker iirc.
Therefore root in the container very much is root on the host.
My mistake, leaving out some adjective one could interpret as a misunderstanding of containers as an effective (etc.) security boundary. Fool me 100+ times and all that.
There must be at least a triple-digit number of CVEs by now demonstratimg that in practice containers are a thinner layer of security (perhaps not quite as thin as the classic recommendation of running SSH on a nonstandard port, but that might be leaning toward the safer side of analogies vs. malicious code!) rather than a boundary like virtualization (not perfect but a best practice for isolation).
Runpod, digital ocean's gpu cloud, and at least a few others use Linux containers for isolation between tenants (look at Wiz's blog post about the nvidia container toolkit bug; digitalocean just puts everyone in a massive k8s cluster)
Huge kudos to the security researchers for 1, finding an exploit, and 2, unlike copyfail, excluding a zero-day ready-to-use LPE script that anyone could have used.
I tried using this for LPE on a Rocky9 for a couple of hours and thankfully couldn't get it to work. So that means unless you have quite some free time on your hand, or are extremely good at doing what you do, you can't actually use this to get LPE on enterprise distros.
Considering that it's rare to get kernel (or any) updates on non-flagship phones, it seems likely.
Backporting an old kernel should be possible, but the only indicator is the system update changelog that explicitly mentions it, I rarely see CVEs mentioned in changelogs on any smartphone. A tool to test the vulnerability is the only way.
Any compromised app on the Play store or external can get root access instantly, but we can still rely on trust and audits when installing apps which should always be the rule.
I suspect that this will be added to all Google Play integrity levels, limiting many apps from being installed on unpatched phones in the future.
That's not the case with browsers with random sites and ads which is hardly avoidable, having any sandbox escape is now more severe considering that it bypasses the app container. It's similar to JailbreakMe on iOS [0]
Google is the good actor here. 7 years of updates, unlocked bootloader, support for LineageOS, etc. The reason it sucks is all the other OEMs who don't care about anything other than the current year's models.
That's Google as the hardware OEM, not Google as the OS/platform vendor. They should be standing on Qualcomm's neck until they upstream their drivers and whatever else is necessary to make it practical for anyone to run updated kernels on their hardware, the same as it has worked for PCs for decades.
FWIW, when Windows NT was ported to mobile it also was compiled against binary blobs for specific Qualcomm SoCs. It's not an Android deficiency; what works on PCs just doesn't really work in mobile-land.
The reason it's like that is that 1990s Microsoft used carrot and stick to make the hardware vendors do the right thing and present day Google isn't doing that when they're the ones who would need to.
The alternative would be for the hardware market to be less consolidated (the government keeps allowing Qualcomm to buy up competitors) so that the chip companies would have to compete on things like this. But that's no excuse for Google to be sitting on their hands when they could fix it too.
Part of the problem I believe sits on how chip manufacturers (looking at you Qualcomm) handle device trees that should be part of upstream, but are never done due to differences in tooling/proprietary blobs which are also part of the DT. This increases the effort on the OEMs to keep comptability across kernel versions.
> I suspect that this will be added to all Google Play integrity levels, limiting many apps from being installed on unpatched phones in the future.
You do realize that a full kernel vulnerability like this allows you to feed falsified information to SafetyNet? Just like DRM, it gives the developer the illusion of control, but doesn't do anything to actually improve "safety" or "integrity".
It's silly that whenever I see a vulnerability like this, all I can think about is "finally, a way to get control over my own devices back". Once again, Stallman was right.
Personally, I'll use this to root my Android TV and Chromecast devices and remove the shitty ads in the launcher (which Google added after I bought the devices!).
Agreed, but I think this will force the average user to upgrade* their phones after losing access to sensitive apps (bank, gov) before getting compromised.
Good news for reusing old phones and taking control.
We should be fighting against SafetyNet and similar attestation systems.
The proper solution is one we had with desktop computing for decades. If you keep the key material on your eID or bank card, you don't need a locked down operating system. Which then allows devices to live for much longer.
We're slowly losing the war on General Purpose Computing.
> We should be fighting against SafetyNet and similar attestation systems.
The proper solution is one we had with desktop computing for decades. If you keep the key material on your eID or bank card
So you want a bank card/ID card to be required each time you use Google Pay? What's the point of Google Pay then.
Actually I have a better idea. What if, instead of holding my phone up to the payment terminal, the bank could give me a plastic card with an antenna and chip, that I could hold up to the payment terminal. The chip could be powered by induction from the terminal.
Maybe I could even duct-tape it to my phone if I really want to do that.
The obvious way to do this is that you need to physically attach the bank card in order to authorize a new vendor. So then when you sign up for Google Pay or Paypal or what have you, you need to get out your card -- which is good. You can't steal a physical card by breaching some other merchant it was used at.
From then your Google Pay account is authorized to initiate charges until you tell your bank otherwise and you don't need the card again unless you want to sign up for Venmo etc.
And it makes things easy if someone steals your phone, because you just sign into the payment processor and deauthorize the device or, if they've already changed your password etc., sign into (or go to) the bank and deauthorize the payment processor.
> Agreed, but I think this will force the average user to upgrade* their phones after losing access to sensitive apps (bank, gov) before getting compromised.
The problem being that there are many millions of people who can't afford to replace a phone they only recently bought just because the vendor never updates it, which means those banks and things can't in practice demand that people do that. Indeed, it creates the opposite problem, because installing a custom ROM on that device would give it a patched kernel but cause it to fail attestation, so what the attestation is actually doing is requiring those people to continue to use the vulnerable OS.
"this will force the average user to upgrade their phones"
A lot of phones don't receive any upgrades after 1 or 2 years...
I wish that Google would have forced vendors to implement a proper hardware abstraction (uefi or similar) so that a single kernel could run on any smartphone, just like it's the case for PCs...
> You do realize that a full kernel vulnerability like this allows you to feed falsified information to SafetyNet?
Are you sure that's true? The whole reason why modern Safetynet/Play Integrity uses HSM data where possible is that you can't spoof that with root (without a microcode bug). It does not trust the running OS by design
I just tried GrapheneOS's https://attestation.app/ on a stock Pixel, and all of the OS version info shows in the "hardware verified" section
There's a lot of confusion around attestation, some of which is IMO done intentionally.
First there is Android's attestation framework. That does actual hardware attestation, as used by GrapheneOS, and supported by literally no app whatsoever.
Then there is SafetyNet, now Play Integrity. Depending on what level of integrity checking is being done, this will do a combination of cursory surface-level software checks, delegation to the aforementioned hardware attestation framework, and several other checks.
Importantly, SafetyNet/Play Integrity rejects some devices that pass hardware attestation (e.g., Graphene OS), and accepts some devices that fail hardware attestation (fairphone, many cheaper devices with broken ROMs, etc).
e.g., fairphone leaked the private key for their attestation, but many of their devices still pass SafetyNet, while some other devices that pass attestation but have known bootloader flaws are blocked by SafetyNet.
Because this isn't strict cryptographic verification, but a mess of heuristics and guesswork, it's a constant cat and mouse game.
What Google really achieved here is to make it expensive enough that no casual user can bypass it to e.g. cheat in Pokemon Go, but only a determined attacker has a chance.
And with "determined attacker" I'm not just talking about states, but even e.g. movie pirates breaking DRM to rip Netflix movies.
Of course, even full cryptographic attestation isn't perfect, and can be bypassed with enough effort. As shown by the famous iPhone hardware jailbreak, where you drill into the SoC and solder directly to the CPU's internal wiring.
selinux doesn't help when the kernel itself has been compromized like this. Sandboxes from Android and containerisation tools like Docker do not protect you against this exploit. The only feasible method of restriction is full virtualisation (assuming that if you use KVM, last week's CVE-2026-53359 patches are rolled out everywhere).
Any app that can run native code execution on any version of Linux in the past fifteen years can get root until kernel updates arrive on your devices.
Also one order of magnitude less than you could get on the black market for a universal Linux LPE and two orders less if you can make it work reliably.
I believe you are two orders of magnitude wrong, in the upward direction, on that number (the first of them). You're talking about reliable remote numbers there, full chain, full enablement, tranched with maintenance.
It requires being able to execute arbitrary code on the machine in userspace. If you have that, most of the time you don't even care about kernel level exploits.
I don't know what "bugged" means but what you're seeing is probably an artifact of HN's re-upping system. We re-upped this thread and that relativized the timestamps on the previously existing comments (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...). Sorry for the confusion—I know it's weird but so far no one has come up with an alternative that is less confusing.
The reason I re-upped this post, btw, is that it was at the top of a list called "underwater" that we try to look at every day, which lists the most-upvoted posts that for whatever reason didn't happen to make the frontpage. This was at the top of that list.
> This is the same shape as many other life-cycle bugs [...]
Claude-ism detected. IME with Claude Code an object does not have a type or definition, apparently, but rather a shape (or at least it reaches for that word before more technically-accurate ones). Problems are not of a similar class or type, but of the same shape. Functions are not defined by their signatures but by their shape. Who talks like this and how did it make its way into the training data so pervasively?
I think you're probably right that the article was AI-assisted, but (if so) it's important not to confuse that with the thing the article is about. Google wouldn't pay $90k for a hallucination.
I don't mean that as a criticism—the question of how to receive AI-processed content is chaotic right now. I'm working on a post about that here: https://news.ycombinator.com/item?id=48887149.
Btw, Nebula Sec is a YC startup in the current batch. We've been working with them on how to launch on HN, and one of the things I've been trying to explain is that the HN audience won't respond well to LLM-generated reports. The underlying work, though, is impressive. These guys know what they're doing—the OP is by no means their only significant find—and the fact that they're doing it with an agent, rather than the traditional way, is significant.
A thing that notably triggers my allergies is that if significant human effort went into something, a few paragraphs written by a human seems like a trivial additional investment; if that last touch is missing, it's really hard for me to extend the benefit of the doubt that there really is something there.
Obviously this is only one signal among many, one that can be overruled, but the ick remains regardless.
I agree to an extent, but there are many exceptions, so one can't really withhold the benefit of the doubt.
For example, non-native English speakers (as is the case with these guys IIRC) frequently use these tools. Maybe they shouldn't—as I've been telling a lot of people who email, mistakes are rapidly becoming a sign of authenticity at this point—but the belief that they need to is widespread, and this doesn't mean they didn't do significant work.
(Side note: it's a common assumption that machine-translated text is in a different category from LLM-edited text. From what we're seeing, that assumption is unfortunately completely wrong.)
Another important case is people with disabilities who find these technologies assistive. Again, one can argue that they're increasingly better off just posting their own writing in the raw, but this is a pretty obscure point to get across to people.
Beyond those cases, a lot of people just don't write easily, and/or don't feel their writing is any good. A lot of them are using LLMs to compensate for that, and this by no means implies that their work is bad. Maybe they just have a phobia about writing and/or don't express themselves well that way.
People who enjoy writing or are confident writers fail to understand how emotionally fraught writing is for many others.
Personally I'm down with the "writing is thinking" view, from which it follows that bad writing is bad thinking. But it doesn't follow that "thinking is writing" - that's a much stronger claim, from which it would follow that good thinking is good writing—and this I think is false.
Non-native speakers have learned and improved their English for decades by trial-and-error, let’s stop using that as an excuse to use LLMs. I have been there, and making mistakes is how one learns to communicate effectively in another language.
If one doesn’t put effort in their writing, I am not going to put effort to read whatever slop they put out instead. Simple as that.
What you say implies that people should "learn and improve their English" before posting their work to HN. I'm not with you on that, and here's why: we're trying to optimize for the most-intellectually-interesting site, not the most-English site: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor..., even though people do have to post in English here.
That user is a non-native English speaker who helped get his posts into a format that HN could appreciate. His work is obviously excellent—the community response was unambiguous. But I don't think it would have made it through without our help.
I'm sure you weren't saying that if someone can't describe their work in good English then it must be slop, but the space is larger than you make it sound. Which is unfortunate in a way—it would be easier to narrow it down, but then we'd miss posts like that one.
Pie-in-the-sky synthesis: translation is easy these days, so maybe non-english writers can and should just write in their own native language and let the readers provide their own translation. Perhaps English no longer needs to be the lingua anglais of western tech writing :p
I don’t buy it, Dan, because non-native English speakers were somehow managing to produce, publicize, and communicate before LLMs did the heavy lifting for them. Perhaps they had human assistance before, but the slop that’s so endemic today reminds us of its value.
Sorry, I was posting hastily and can see how that was unclear. Unfortunately I've forgotten my point.
Perhaps it was this: there are many non-native English speakers who have valuable things to contribute to HN, who don't yet have sufficient English or don't feel they do, and therefore resort to LLMs to do their English for them. Should they automatically be excluded?
They should be included! But there's a difference between machine translation and technical-writing-using-an-LLM, in my opinion. One has a lot more humanness to it, still.
You said earlier that we don't allow LLM-generated content on HN itself (i.e., the comments). So, at least in principle, that's already taken care of through exclusion.
If you mean the linked content: can come from anyone and anywhere--it's just whatever someone submits and is deemed good enough by The Algorithm to get attention. So that's not "HN content" - the content exists independently of HN. As for that, I'll repeat myself: the scientific community has managed somehow to intercommunicate for centuries despite language barriers before LLMs existed. (English was neither Einstein's nor Madame Curie's first language.) It's an existence proof that LLMs aren't needed to overcome those barriers.
It frankly doesn't matter how much human effort went into finding the vulnerability, it just matters if it exists, how severe it is, and how easy it is to exploit.
If an exploit is actually working, human effort is void and the ML has done a great job. However most of the time its hallucinating, confidently talking gibberish in technical lingo. This phenomena is only amplified by those who try to make a quick buck without effort using older models, not reviewing output or prompting properly ('find me bugs in Linux, make no mistakes')
We apologize for the confusion. We used AI to run final grammar pass and didn't noticed it changed some wording (shape is one of them). Will be more careful in the future
I've used phrasing like this from time to time before, like when trying to compare two ideas that are unalike but have some fuzzy similarities. I wouldn't use it to describe functions but "problems", "solutions", and other fuzzy things.
I must confess that I asked a leading question. At no point did I say that the usage wasn't real; by way of dramatic omission I was more pointing to the fact that a common ECMAScript/React-ism is overrepresented in Claude's training set to the point that it's being applied to situations not involving duck-typed languages.
I'm not a grammatical prescriptivist but I find it viscerally troubling that a bunch of LLM cargo-culted terms are starting to inform how we talk about our work.
It's not so widely used and it's not explained in the first couple screenfuls of TFA (which by itself is weirdly structured, taking entire paragraphs to explain when it was introduced, when it was discovered, etc. before even explaining what it actually is).
Of course the title was chosen when the article was first published on a site dedicated to security, where probably everyone knows it. This suggests that insisting on unmodified titles when republishing in HN is a poor rule.
Has anyone in infosec ever seen the term "use after free" before LLMs? Or is this basically an acronym claude invented? I say this because I see claude use this term all the time like its common knowledge but in 15+ years in tech never seen it myself. I've seen all kinds of terms used to describe memory errors: memory corruption, heap corruption, stack corruption, whatever, just never this acronym.
I'm surprised that UAF as an acronym is apparently unusual even among people familiar with use-after-free as a concept. I thought that was a pretty typical acronym in the context of software.
This is and has been a common term in any systems programming concept for decades. You can, for example, search CVEs and easily find some from over 15 years ago: https://www.cve.org/CVERecord?id=CVE-2010-1119
It was even enumerated in the first pass of CWE as CWE-416 in 2006.
if you have spend any amount of time in low level c vulnerabilities you will have heard about it, it is a very common time on the low level/cybersec space.
Yes, it was a common attack vector in binary exploitation. Heap based attack vector like use after free, double free, heap overflows, and others are pretty neat. They force you to learn a lot about how malloc works.
There is a lot of cool work that went into making memory allocation work well; the different arenas, fast bins, chunk headers, etc. are super cool.
Huh? That is a really common term. There have been even memes about it. I remember roughly 5 years ago I first heard the ironic; "Real men use after free" in a discussion about Rust's benefits as its borrowing checker would have also prevented this one.
"Use after free" is also described in most standard books about C as a thing you should never do, have you read one?
Do we really need infosec companies now that a skid with claude can find decades-old kernel privesc over a weekend?
Also can we talk about how bad Linux security is? At this point it's becoming a real liability to run anything on Linux that needs to be secure. OpenBSD has been around for ages, is written in C, and is really, really secure. Do they support containers yet (or microVMs)? Cuz if they do, I'm moving my workloads to obsd.
Personal laptop use with Ada Lovelace or Ampere family NVIDIA GPUs (did you mean this or CUDA, i couldnt tell), personal desktop use with unusual peripherals, dependency on ports, existence and competition of FreeBSD etc. I love OpenBSD's code philosophy (they were the first to introduce a lot of security techniques[1]) and the programs they produce, OpenSSH is a lifesaver, and I use doas for its low footprint on my Linux machine. Still, they have a convulated install process, dubious hardware and software compatibility that is better solved in the Linux world today.
So pretty much only GPU compute (CUDA) and exotic peripherals?
I don't see any ports dependency issues as there's been binary packages available forever. Even the install process is a lot faster than any linux I have to use at $work, not to mention easier to automate with autoinstall[0] if needed.
GPU driver support is not limited to CUDA. Devices that require binary blobs of firmware to work properly are not always exotic. Some examples off the top of my head that won't work with OpenBSD hassle-free is Vantage (LLL), Solaar ... but I haven't tested. I understand you finding it easier to work with and it's faster install speeds do pique my interest, yet you being on HN already puts your technical literacy on some low % of gen pop. OpenBSD may be comparable to distros like Gentoo, Void or Arch but certainly not out-of-the-box ones like Ubuntu. They serve different auidences.
If there was a similar class of bug in the illumos kernel, it would also allow for a container escape, no?
There are many issues with the formulation of containers on Linux (though I think people overstate it whenever bugs like this happen) but ultimately this bug was a UAF that gave you arbitrary code execution in the kernel. Zone IDs are also just numbers in kernel memory... right?
Not necessarily. Zones in illumos (and Solaris before) were designed from ground up to be secure in multitenant workloads[0]. It's quite different from the duct tape style[1] of linux containerization.
I am aware of the history behind Zones and Jails, but my point is still the same -- the (lack of) protection you get against kernel exploits should be the same because the only thing protecting you from escapes is kernel data structures.
(I've been one of the maintainers of runc -- the most widely use used container runtime on Linux -- for more than a decade, so I'm at least somewhat well-informed on the topic.)
The duct tape criticisms are fair when talking about other vulnerabilities (such as when container runtimes have misconfiguration or other inatomicity bugs) but not really here in the context of a kernel arbitrary code execution gadget. It also seems quite unlikely that the illumos kernel doesn't contain any of these kinds of bugs.
Tested on three Android devices (version 9, 13, 16) with different Firefox versions under 150 (had to modify for older).
Two boot looped, I had to enter recovery and the other just powered off [0].
The demo modifies the wallpaper on supported Pixel devices.
[0] IonStack https://rootme.nebusec.ai
____
Tip: Install a Chromium flavor browser (Chromite) separate from the main browser.
Disable Javascript and hardware accelerated video decoder (commonly exploited) from the flags page and enable reader mode to fix broken JS-dependent websites when browsing blogs and random sites on your personal devices, else dedicate a tablet.
Thanks for testing, we currently only tested it on Pixel 10, but there are a few people on our repo creating PR to support other devices, you can take a look here https://github.com/NebuSec/CyberMeowfia
Can you please provide a `Dockerfile` to build the POC/exploit?
I've been noodling with porting the kernel exploit to other devices, and the exploit is very sensitive to how the compiler happens to lay out stack frames, which varies between kernel builds. Once you figure out the right "stamp method" and offsets for a particular kernel build though, it's fairly reliable.
Would be amazing if this was used to root so-far unrootable android devices. Any suggestions.
Wonder if it were possible to use this to (finally) jailbreak DJIs original RC that came with the Mini 3 Pro.
It doesn't have a web browser or, virtually, anything of use... but I think it supports enough of a web browser to log in into wifi captive portals.
Root for these RCs has been available under the guise of “FCC hack” for a really long time now; different groups have different exploits (it’s DJI so there are plenty) that work on different firmware versions.
This would almost surely work there too, though.
What can you do with a jailbroken drone rc?
Mostly they’re used to enable illegal RF parameters in Europe (FCC hack); DJI disabled strict geofencing in most of the “west” several years ago and that was also enforced in the drone anyway.
If you don't mind going to jail and/or paying a fine, flying in restricted/illegal areas.
Makes sense
So I took the risk and ran it on a Samsung S26 Ultra - I will confirm the full details once I have `adb` installed and running.
The exploit/POC (call it what you want) ran or appeared to have executed because:
1. I saw output on the Firefox tab when I navigated to <https://rootme.nebusec.io/b9e3f1a4-7c82-4d6e-9a51-2f8c4b3e0d...>.
2. I saw some output from the execution of the POC.
However, after I went to <https://rootme.nebusec.io/b9e3f1a4-7c82-4d6e-9a51-2f8c4b3e0d...> the phone froze and refused to respond to any input. The only thing that worked was restarting, which I wonder how it works given the, I think, the kernel has hung. Does anyone know how the kernel is able to respond to events whilst the system has hung? The screen remains on with the partial output of the execution of the POC until the screen saver kicks in ...
The kernel is not a single-threaded process - a "kernel hang" is not a very specific description and you don't have a way to know that it happened anyway. The screen timing out is evidence that the kernel was largely working, actually. Of course if some data structure got corrupted it could have affected a specific essential part of the system, such as the touchscreen driver or the display compositor.
I've created an issue in GitHub, please see https://github.com/NebuSec/CyberMeowfia/issues/46 (Samsung SM-S948B (S26 Ultra)).
It would be nice to get a `Dockerfile` to build the exploit/POC.
fwiw, the firefox vulnerability seems to be CVE-2026-10702 (type confusion in the ionmonkey jit compiler): https://www.sentinelone.com/vulnerability-database/cve-2026-...
Severity score of 4.3 seems low considering the click2pwn in this thread. Though Firefox on Android is uniquely bad because of the lack of sandboxing.
What Android devices did you test on exactly?
I take it you did NOT unlock the bootloader?
> Two boot looped, I had to enter recovery and the other just powered off [0].
Absolutely crazy that it is possible to brick someone's phone via an exploit but ... hey.
After the power off what happened? Do things seem normal?
When it entered recovery mode where you able to get the phone in a clean state again? I take it that you did?
I'd really like to run this but I, ideally, do not want to run something random from the internet. It's a shame there is no `Dockerfile` to build this exploit/POC. All I want is LPE to `root` on a Samsung (Snapdragon) phone.
Originally tested on non personal devices
Honor 10 - Moto G04 - Poco X3
Poco is unlocked.
There is no brick on any, they're boot loader bugs and unrelated to the exploit. Recovery "reboot" was used.
You need to modify it to root, the example only crashes the kernel.
Forgot to include "LPE" (local...) in the title so most of us can get back to weekending.
Not really. Generally we use "Local Privilege Exploit" to describe an exploit that goes from a reasonably normal user privileges to root privileges.
And we don't usually worry about them, because an application with normal user privileges can already to so much damage.
But this exploit can be triggered from inside a tightly sandboxed process, such as firefox's isolated browser process. Which means the attacker now only needs to chain two exploits together: One javascript exploit to get local code execution in an isolated sandbox, and this one to jump all the rest of the way to kernel mode.
Which means, you should update both firefox, and your linux kernel.
> this exploit can be triggered from inside a tightly sandboxed process
Thank you for emphasizing this important detail.
> you should update both firefox, and your linux kernel
No doubt, update all the things! My point was, it can most likely wait until Monday.
Realistically, if you have a browser sandbox, the system LPE exploit gives you very little more. Everything interesting on a desktop system is accessible by the user account directly.
This gets you code execution in the kernel, at which point sandboxing is irrelevant.
Got me confused for a sec, as the exploit in the top comment implies JavaScript→root, but it actually relies on two separate exploits.
Since this enables container escape, sounds like this might still impact quite a lot of us?
I guess, if you thought Docker/etc. was a security boundary
They are a security boundary. The fact that you need a vulnerability to escape them is proof of that. They just don't have a particularly high cost of escape because reachable kernel vulnerabilities are so common.
Escape from docker containers is trivially easy, if you are able to run as the root user in the container itself.
Many (maybe most) containers actually default to running programs as root. Kernel exploit not required.
I don't think this would change anything even if it were true, which it is not. Running as root in a container opens up tons of footguns but it is not a path out of the container on its own.
If you are given a shell with `docker run -it --rm alpine:3 sh`, can you read the /etc/shadow on the host without kernel exploit? Assuming the docker and kernel are sufficiently update-to-date (e.g. latest Docker on Debian Stable).
No.
The "root" you get in docker is not actually root outside of the namespace the container in running in.
Assuming no bugs in the kernel, it should not be able to do anything more than the UID that it's mapped from.
Does Docker use user namespaces by default? Otherwise root in the container is actually root on the host, from what I read. Correct me if I'm wrong.
(Privileges are still limited by seccomp filters blocking some syscalls, and there's SELinux to block some other stuff, but it's still the actual root user without user namespaces, I think?)
That's right. Docker still runs without user namespaces by default, which means that root is the same user inside and outside of the container. This does open up attack surface and configuration footguns.
Confinement still leverages dropping some root caps, seccomp, various other namespaces, etc.
I don't think this is true, otherwise you could just load a kernel module into the host kernel from a container.
There are a million ways to load a kernel module from inside of a container into the host kernel (ie: to trigger a load), but seccomp/ linux caps will block the direct ways (as another commenter notes).
Root is not just one thing on modern Linux, almost all in-kernel privilege checks are now gated via (slightly) more fine-grained capabilities and the default capability set for Docker containers disallows module loading (CAP_SYS_MODULE) and the relevant syscalls (namely (f)init_module) are also blocked with seccomp.
People still should use user namespaces (and tools like Podman and Incus do by default) but basic stuff like that is not the reason.
Presumably Docker's seccomp profile [1] blocks the init_module system call which is used by insmod [2]. Although, looking at the default profile, it seems to explicitly allow it - but maybe only if you have CAP_SYS_MODULE, which I think means running Docker with "--cap-add=SYS_MODULE".
[1] https://docs.docker.com/engine/security/seccomp/
[2] https://tldp.org/HOWTO/Module-HOWTO/x627.html
It is very possible to load a kernel module into the host from a container.
https://stackoverflow.com/questions/33013539/docker-loading-...
FYI, looks like you are shadowbanned.
At least podman does if running rootless, I assume docker supports rootless operation as well.
Not sure about running rootful though. I don't really use rootful containers personally.
Hmm. Either I've lost my mind, or you're running a different Docker than me, or you're thinking of some strange scenario such as a Mac where docker is actually inside a VM, or you're wrong.
While there is a feature to do with UID mapping, it doesn't actually work/isn't usable/nobody uses it in current docker iirc.
Therefore root in the container very much is root on the host.
UID mapping is how rootless docker works, so tons of people are using it
Some people clearly do use containers as deployment mechanism, with security not in mind.
s/some/most/
That's not meant to be snide, just true, I think.
> They are a security boundary
My mistake, leaving out some adjective one could interpret as a misunderstanding of containers as an effective (etc.) security boundary. Fool me 100+ times and all that.
There must be at least a triple-digit number of CVEs by now demonstratimg that in practice containers are a thinner layer of security (perhaps not quite as thin as the classic recommendation of running SSH on a nonstandard port, but that might be leaning toward the safer side of analogies vs. malicious code!) rather than a boundary like virtualization (not perfect but a best practice for isolation).
Runpod, digital ocean's gpu cloud, and at least a few others use Linux containers for isolation between tenants (look at Wiz's blog post about the nvidia container toolkit bug; digitalocean just puts everyone in a massive k8s cluster)
Why aren’t they using a fast VM like Firecracker?
To squeeze out 5% more profit.
There was a virtual machine KVM escape found like 2 weeks ago.
Nothing is a security boundary anymore.
I know there's a lot you can do in k8s to mitigate it, but I didn't think that prevented it outright.
A lot of us rely on Linux containers' being escape-proof?
I would have hoped that only a few of us are so misinformed as to do that.
If you run critical containers under Linux instead of a dedicated hypervisor, you deserve to get hacked.
they also found a type confusion in firefox/ionmonkey, so you can go from random website to pwned very quickly.
as if in these times there aren't hundreds of "0days" in everyone's hands waiting to be burned for situations just like this.
from ssh to node, so much stuff showing every other week. might as well call everything remote unless you run 100% behind wireguard or something.
Pretty much, the rate at which quality exploits are dropping is mind blowing.
Huge kudos to the security researchers for 1, finding an exploit, and 2, unlike copyfail, excluding a zero-day ready-to-use LPE script that anyone could have used.
I tried using this for LPE on a Rocky9 for a couple of hours and thankfully couldn't get it to work. So that means unless you have quite some free time on your hand, or are extremely good at doing what you do, you can't actually use this to get LPE on enterprise distros.
Could this be used to unlock bootloaders on typically non unlockable phones? If so this could be one of the best things to happen to Android.
Does that mean any android app can use ndk native code execution to become root? Does selinux help here?
Considering that it's rare to get kernel (or any) updates on non-flagship phones, it seems likely.
Backporting an old kernel should be possible, but the only indicator is the system update changelog that explicitly mentions it, I rarely see CVEs mentioned in changelogs on any smartphone. A tool to test the vulnerability is the only way.
Any compromised app on the Play store or external can get root access instantly, but we can still rely on trust and audits when installing apps which should always be the rule.
I suspect that this will be added to all Google Play integrity levels, limiting many apps from being installed on unpatched phones in the future.
That's not the case with browsers with random sites and ads which is hardly avoidable, having any sandbox escape is now more severe considering that it bypasses the app container. It's similar to JailbreakMe on iOS [0]
[0] https://en.wikipedia.org/wiki/JailbreakMe
> Considering that it's rare to get kernel (or any) updates on non-flagship phones
How the cluster f*k of the Android update situation Google has allowed this to happen really needs a regulator to step in.
Planned obsolescence is supposed to be illegal in Europe.
Google is the good actor here. 7 years of updates, unlocked bootloader, support for LineageOS, etc. The reason it sucks is all the other OEMs who don't care about anything other than the current year's models.
That's Google as the hardware OEM, not Google as the OS/platform vendor. They should be standing on Qualcomm's neck until they upstream their drivers and whatever else is necessary to make it practical for anyone to run updated kernels on their hardware, the same as it has worked for PCs for decades.
FWIW, when Windows NT was ported to mobile it also was compiled against binary blobs for specific Qualcomm SoCs. It's not an Android deficiency; what works on PCs just doesn't really work in mobile-land.
The reason it's like that is that 1990s Microsoft used carrot and stick to make the hardware vendors do the right thing and present day Google isn't doing that when they're the ones who would need to.
The alternative would be for the hardware market to be less consolidated (the government keeps allowing Qualcomm to buy up competitors) so that the chip companies would have to compete on things like this. But that's no excuse for Google to be sitting on their hands when they could fix it too.
Why would Google be responsible for Samsung and Huawei?
Because it's their operating system and their live services?
Just like Microsoft with Windows.
Great analogy! Why would Microsoft be responsible for Lenovo?
Microsoft is responsible for the updates on a Lenovo.
Part of the problem I believe sits on how chip manufacturers (looking at you Qualcomm) handle device trees that should be part of upstream, but are never done due to differences in tooling/proprietary blobs which are also part of the DT. This increases the effort on the OEMs to keep comptability across kernel versions.
More to do with how the ARM ecosystem works and the resulting lack of openness and standardisation in the hardware interface.
There's a fair amount of blame there, but it's also partially how Android has to be compiled/built for the hardware.
> I suspect that this will be added to all Google Play integrity levels, limiting many apps from being installed on unpatched phones in the future.
You do realize that a full kernel vulnerability like this allows you to feed falsified information to SafetyNet? Just like DRM, it gives the developer the illusion of control, but doesn't do anything to actually improve "safety" or "integrity".
It's silly that whenever I see a vulnerability like this, all I can think about is "finally, a way to get control over my own devices back". Once again, Stallman was right.
https://www.gnu.org/philosophy/right-to-read.en.html
Personally, I'll use this to root my Android TV and Chromecast devices and remove the shitty ads in the launcher (which Google added after I bought the devices!).
Agreed, but I think this will force the average user to upgrade* their phones after losing access to sensitive apps (bank, gov) before getting compromised.
Good news for reusing old phones and taking control.
*as in replace
We should be fighting against SafetyNet and similar attestation systems.
The proper solution is one we had with desktop computing for decades. If you keep the key material on your eID or bank card, you don't need a locked down operating system. Which then allows devices to live for much longer.
We're slowly losing the war on General Purpose Computing.
https://media.ccc.de/v/28c3-4848-en-the_coming_war_on_genera...
> We should be fighting against SafetyNet and similar attestation systems. The proper solution is one we had with desktop computing for decades. If you keep the key material on your eID or bank card
So you want a bank card/ID card to be required each time you use Google Pay? What's the point of Google Pay then.
Actually I have a better idea. What if, instead of holding my phone up to the payment terminal, the bank could give me a plastic card with an antenna and chip, that I could hold up to the payment terminal. The chip could be powered by induction from the terminal.
Maybe I could even duct-tape it to my phone if I really want to do that.
The obvious way to do this is that you need to physically attach the bank card in order to authorize a new vendor. So then when you sign up for Google Pay or Paypal or what have you, you need to get out your card -- which is good. You can't steal a physical card by breaching some other merchant it was used at.
From then your Google Pay account is authorized to initiate charges until you tell your bank otherwise and you don't need the card again unless you want to sign up for Venmo etc.
And it makes things easy if someone steals your phone, because you just sign into the payment processor and deauthorize the device or, if they've already changed your password etc., sign into (or go to) the bank and deauthorize the payment processor.
Once upon a time(tm), Google had a great solution for that: You could get a credit card in nano SIM format, and insert into in your dual-SIM phone.
That then allows you to do secure NFC credit card payments even on a rooted phone with custom ROM.
That doesn't work when someone has multiple or virtual cards. That also means if someone steals my phone they get my credit card too.
Not a great solution.
You can load multiple card identities onto the same SIM and select the one you want to use.
> That also means if someone steals my phone they get my credit card too.
Which hasn't been an issue since Chip & PIN became required, 22 years ago (at least over here).
I think some banks still do this with NFC instead?
Do you have more details on the sim credit card?
> Agreed, but I think this will force the average user to upgrade* their phones after losing access to sensitive apps (bank, gov) before getting compromised.
The problem being that there are many millions of people who can't afford to replace a phone they only recently bought just because the vendor never updates it, which means those banks and things can't in practice demand that people do that. Indeed, it creates the opposite problem, because installing a custom ROM on that device would give it a patched kernel but cause it to fail attestation, so what the attestation is actually doing is requiring those people to continue to use the vulnerable OS.
"this will force the average user to upgrade their phones"
A lot of phones don't receive any upgrades after 1 or 2 years...
I wish that Google would have forced vendors to implement a proper hardware abstraction (uefi or similar) so that a single kernel could run on any smartphone, just like it's the case for PCs...
Google has required vendors to do that since Android 12. For a given version that same exact kernel is used on all phones with that version.
https://source.android.com/docs/core/architecture/kernel/gen...
Unfortunately it still requires OEMs to ship that kernel.
> You do realize that a full kernel vulnerability like this allows you to feed falsified information to SafetyNet?
Are you sure that's true? The whole reason why modern Safetynet/Play Integrity uses HSM data where possible is that you can't spoof that with root (without a microcode bug). It does not trust the running OS by design
I just tried GrapheneOS's https://attestation.app/ on a stock Pixel, and all of the OS version info shows in the "hardware verified" section
There's a lot of confusion around attestation, some of which is IMO done intentionally.
First there is Android's attestation framework. That does actual hardware attestation, as used by GrapheneOS, and supported by literally no app whatsoever.
Then there is SafetyNet, now Play Integrity. Depending on what level of integrity checking is being done, this will do a combination of cursory surface-level software checks, delegation to the aforementioned hardware attestation framework, and several other checks.
Importantly, SafetyNet/Play Integrity rejects some devices that pass hardware attestation (e.g., Graphene OS), and accepts some devices that fail hardware attestation (fairphone, many cheaper devices with broken ROMs, etc).
e.g., fairphone leaked the private key for their attestation, but many of their devices still pass SafetyNet, while some other devices that pass attestation but have known bootloader flaws are blocked by SafetyNet.
Because this isn't strict cryptographic verification, but a mess of heuristics and guesswork, it's a constant cat and mouse game.
What Google really achieved here is to make it expensive enough that no casual user can bypass it to e.g. cheat in Pokemon Go, but only a determined attacker has a chance.
And with "determined attacker" I'm not just talking about states, but even e.g. movie pirates breaking DRM to rip Netflix movies.
Of course, even full cryptographic attestation isn't perfect, and can be bypassed with enough effort. As shown by the famous iPhone hardware jailbreak, where you drill into the SoC and solder directly to the CPU's internal wiring.
selinux doesn't help when the kernel itself has been compromized like this. Sandboxes from Android and containerisation tools like Docker do not protect you against this exploit. The only feasible method of restriction is full virtualisation (assuming that if you use KVM, last week's CVE-2026-53359 patches are rolled out everywhere).
Any app that can run native code execution on any version of Linux in the past fifteen years can get root until kernel updates arrive on your devices.
>Google has rewarded us $92,337 in kernelCTF
I'm all ears now
Seems low considering the wide impact, but maybe the only thing corporations throw big money at is remote exploits?
That's a huge amount of money for a vulnerability.
Also one order of magnitude less than you could get on the black market for a universal Linux LPE and two orders less if you can make it work reliably.
I believe you are two orders of magnitude wrong, in the upward direction, on that number (the first of them). You're talking about reliable remote numbers there, full chain, full enablement, tranched with maintenance.
Surely working on Android adjusts the number upwards by a lot?
https://www.forbes.com/sites/daveywinder/2026/05/05/google-t...
How is it a wide impact?
It requires being able to execute arbitrary code on the machine in userspace. If you have that, most of the time you don't even care about kernel level exploits.
It's a browser to kernel full chain exploit, from url click to root your device.
https://rootme.nebusec.io/
Supposedly it can root Android.
Daaaaamn: "GhostLock was introduced in Linux 2.6.39 and fixed in Linux 7.1."
Fuck it. I’m exclusively running the book version of minix from now on, neovim be damned. The exploit surface of these kernels is wild.
A good think I use JS less browsers.
Is HN bugged? I swear I have read these comments the day prior, there is no way they are from within 10 hours?
I don't know what "bugged" means but what you're seeing is probably an artifact of HN's re-upping system. We re-upped this thread and that relativized the timestamps on the previously existing comments (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...). Sorry for the confusion—I know it's weird but so far no one has come up with an alternative that is less confusing.
The reason I re-upped this post, btw, is that it was at the top of a list called "underwater" that we try to look at every day, which lists the most-upvoted posts that for whatever reason didn't happen to make the frontpage. This was at the top of that list.
Ah, I didn't know actual post timestamps for comments are updated. That explains it, thank you!
New 'lastSubmission' field for the post item. Show both if they're different. Then just update lastSubmission on re-up?
Messing with the displayed times people sent their comments is honestly akin to rewriting their answers.
Sometimes similar articles are merged into one. Including the comments.
> This is the same shape as many other life-cycle bugs [...]
Claude-ism detected. IME with Claude Code an object does not have a type or definition, apparently, but rather a shape (or at least it reaches for that word before more technically-accurate ones). Problems are not of a similar class or type, but of the same shape. Functions are not defined by their signatures but by their shape. Who talks like this and how did it make its way into the training data so pervasively?
I think you're probably right that the article was AI-assisted, but (if so) it's important not to confuse that with the thing the article is about. Google wouldn't pay $90k for a hallucination.
I don't mean that as a criticism—the question of how to receive AI-processed content is chaotic right now. I'm working on a post about that here: https://news.ycombinator.com/item?id=48887149.
Btw, Nebula Sec is a YC startup in the current batch. We've been working with them on how to launch on HN, and one of the things I've been trying to explain is that the HN audience won't respond well to LLM-generated reports. The underlying work, though, is impressive. These guys know what they're doing—the OP is by no means their only significant find—and the fact that they're doing it with an agent, rather than the traditional way, is significant.
A thing that notably triggers my allergies is that if significant human effort went into something, a few paragraphs written by a human seems like a trivial additional investment; if that last touch is missing, it's really hard for me to extend the benefit of the doubt that there really is something there.
Obviously this is only one signal among many, one that can be overruled, but the ick remains regardless.
I agree to an extent, but there are many exceptions, so one can't really withhold the benefit of the doubt.
For example, non-native English speakers (as is the case with these guys IIRC) frequently use these tools. Maybe they shouldn't—as I've been telling a lot of people who email, mistakes are rapidly becoming a sign of authenticity at this point—but the belief that they need to is widespread, and this doesn't mean they didn't do significant work.
(Side note: it's a common assumption that machine-translated text is in a different category from LLM-edited text. From what we're seeing, that assumption is unfortunately completely wrong.)
Another important case is people with disabilities who find these technologies assistive. Again, one can argue that they're increasingly better off just posting their own writing in the raw, but this is a pretty obscure point to get across to people.
Beyond those cases, a lot of people just don't write easily, and/or don't feel their writing is any good. A lot of them are using LLMs to compensate for that, and this by no means implies that their work is bad. Maybe they just have a phobia about writing and/or don't express themselves well that way.
People who enjoy writing or are confident writers fail to understand how emotionally fraught writing is for many others.
Personally I'm down with the "writing is thinking" view, from which it follows that bad writing is bad thinking. But it doesn't follow that "thinking is writing" - that's a much stronger claim, from which it would follow that good thinking is good writing—and this I think is false.
Non-native speakers have learned and improved their English for decades by trial-and-error, let’s stop using that as an excuse to use LLMs. I have been there, and making mistakes is how one learns to communicate effectively in another language.
If one doesn’t put effort in their writing, I am not going to put effort to read whatever slop they put out instead. Simple as that.
What you say implies that people should "learn and improve their English" before posting their work to HN. I'm not with you on that, and here's why: we're trying to optimize for the most-intellectually-interesting site, not the most-English site: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor..., even though people do have to post in English here.
That may sound like too fine a distinction, but it isn't. Here's an example: Show HN: Getting GLM 5.2 running on my slow computer - https://news.ycombinator.com/item?id=48842459, which was the #1 thread on HN a couple days ago (https://news.ycombinator.com/front?day=2026-07-09).
That user is a non-native English speaker who helped get his posts into a format that HN could appreciate. His work is obviously excellent—the community response was unambiguous. But I don't think it would have made it through without our help.
I'm sure you weren't saying that if someone can't describe their work in good English then it must be slop, but the space is larger than you make it sound. Which is unfortunate in a way—it would be easier to narrow it down, but then we'd miss posts like that one.
Pie-in-the-sky synthesis: translation is easy these days, so maybe non-english writers can and should just write in their own native language and let the readers provide their own translation. Perhaps English no longer needs to be the lingua anglais of western tech writing :p
I don’t buy it, Dan, because non-native English speakers were somehow managing to produce, publicize, and communicate before LLMs did the heavy lifting for them. Perhaps they had human assistance before, but the slop that’s so endemic today reminds us of its value.
Not on HN they weren't. Right?
Non native speakers have been on HN since its inception. Unless you mean something else?
Sorry, I was posting hastily and can see how that was unclear. Unfortunately I've forgotten my point.
Perhaps it was this: there are many non-native English speakers who have valuable things to contribute to HN, who don't yet have sufficient English or don't feel they do, and therefore resort to LLMs to do their English for them. Should they automatically be excluded?
They should be included! But there's a difference between machine translation and technical-writing-using-an-LLM, in my opinion. One has a lot more humanness to it, still.
You said earlier that we don't allow LLM-generated content on HN itself (i.e., the comments). So, at least in principle, that's already taken care of through exclusion.
If you mean the linked content: can come from anyone and anywhere--it's just whatever someone submits and is deemed good enough by The Algorithm to get attention. So that's not "HN content" - the content exists independently of HN. As for that, I'll repeat myself: the scientific community has managed somehow to intercommunicate for centuries despite language barriers before LLMs existed. (English was neither Einstein's nor Madame Curie's first language.) It's an existence proof that LLMs aren't needed to overcome those barriers.
It frankly doesn't matter how much human effort went into finding the vulnerability, it just matters if it exists, how severe it is, and how easy it is to exploit.
If an exploit is actually working, human effort is void and the ML has done a great job. However most of the time its hallucinating, confidently talking gibberish in technical lingo. This phenomena is only amplified by those who try to make a quick buck without effort using older models, not reviewing output or prompting properly ('find me bugs in Linux, make no mistakes')
There is no if, it works, people have video proof, google confirmed, Linux patched and fixed. And you still believe this is AI gibberish
You should put a note in Find a Cofounder not to do that as well. Huge turnoff for me, though I guess a great filter.
No this is normal programming terminology. Here I am using 'shape' in this sense back in 2021:
https://www.marginalia.nu/log/40-wasted-resources/
and even more similar usage again in 2023 'the shape of the algorithm' (which was post-claude I guess, but this was before I even tested any LLM):
https://www.marginalia.nu/log/87_absurd_success/
We apologize for the confusion. We used AI to run final grammar pass and didn't noticed it changed some wording (shape is one of them). Will be more careful in the future
I've used phrasing like this from time to time before, like when trying to compare two ideas that are unalike but have some fuzzy similarities. I wouldn't use it to describe functions but "problems", "solutions", and other fuzzy things.
When working in Elixir, everything is about the shape of things. I have now taken that word usage from that ecosystem because I find it useful.
Isn't this just observation bias? "If I haven't encountered something, then it must not be real?" (Paraphrasing)
I must confess that I asked a leading question. At no point did I say that the usage wasn't real; by way of dramatic omission I was more pointing to the fact that a common ECMAScript/React-ism is overrepresented in Claude's training set to the point that it's being applied to situations not involving duck-typed languages.
I'm not a grammatical prescriptivist but I find it viscerally troubling that a bunch of LLM cargo-culted terms are starting to inform how we talk about our work.
Except that working with Claude has me saying things like shape lately. I think I like it.
talking about data and function shapes is quite common in functional programming world
https://blog.jle.im/entry/functors-to-monads-a-story-of-shap...
A what?
Use after free?
Thanks! I've put that in the toptext now.
I don't actually see that change, unless I misunderstand the meaning of toptext.
Weird - it was there and then went away. It's back now. Thanks!
I'm glad someone else asked. :)
It's not so widely used and it's not explained in the first couple screenfuls of TFA (which by itself is weirdly structured, taking entire paragraphs to explain when it was introduced, when it was discovered, etc. before even explaining what it actually is).
Of course the title was chosen when the article was first published on a site dedicated to security, where probably everyone knows it. This suggests that insisting on unmodified titles when republishing in HN is a poor rule.
Not that everyone should know it but it's definitely widely used. A Google search for "stack UAF" also turns it up.
Unidentified Aerial Fenomenom
"Nothing could have prevented this from happening," say users of only language where this happens
Not true, it can also occur in C++, Zig, and assembly language.
Or Rust, when not sticking exclusively to safe Rust, but this is not really possible in many systems programming scenarious.
Golang, C# and even Java does have its exploits.
Maybe just Algol68 and Rust can withstand this, among ADA. And PL/1 under Multics.
Firefox it's written in Rust.
No it's not. Yes it contains a lot of Rust, but it's still mostly C++.
Has anyone in infosec ever seen the term "use after free" before LLMs? Or is this basically an acronym claude invented? I say this because I see claude use this term all the time like its common knowledge but in 15+ years in tech never seen it myself. I've seen all kinds of terms used to describe memory errors: memory corruption, heap corruption, stack corruption, whatever, just never this acronym.
I'm surprised that UAF as an acronym is apparently unusual even among people familiar with use-after-free as a concept. I thought that was a pretty typical acronym in the context of software.
This is and has been a common term in any systems programming concept for decades. You can, for example, search CVEs and easily find some from over 15 years ago: https://www.cve.org/CVERecord?id=CVE-2010-1119
It was even enumerated in the first pass of CWE as CWE-416 in 2006.
if you have spend any amount of time in low level c vulnerabilities you will have heard about it, it is a very common time on the low level/cybersec space.
Yes, it was a common attack vector in binary exploitation. Heap based attack vector like use after free, double free, heap overflows, and others are pretty neat. They force you to learn a lot about how malloc works.
There is a lot of cool work that went into making memory allocation work well; the different arenas, fast bins, chunk headers, etc. are super cool.
yes, it’s a very common term in infosec. I haven’t heard the “UAF” acronym before though
I've heard of use after free, but I've only heard UAF to mean Ukraine Armed Forces.
It has been a known bug class for quite some time.
Huh? That is a really common term. There have been even memes about it. I remember roughly 5 years ago I first heard the ironic; "Real men use after free" in a discussion about Rust's benefits as its borrowing checker would have also prevented this one.
"Use after free" is also described in most standard books about C as a thing you should never do, have you read one?
I haven't really seen it as an acronym "UAF", but I can't recall the first time I heard "use after free". It was probably in the previous century.
The idea that Claude came up with it is ridiculous.
You have somehow lived in a strange bubble.
2025: https://redis.io/blog/security-advisory-cve-2025-49844/ 2023: https://seclists.org/oss-sec/2023/q2/133 2022: https://www.zerodayinitiative.com/advisories/ZDI-22-1690/ 2014: https://ftp.openbsd.org/pub/OpenBSD/patches/5.4/common/008_o...
It's an issue as old as time, or thereabouts.
So has the church of the subgenius.
Damn
Do we really need infosec companies now that a skid with claude can find decades-old kernel privesc over a weekend?
Also can we talk about how bad Linux security is? At this point it's becoming a real liability to run anything on Linux that needs to be secure. OpenBSD has been around for ages, is written in C, and is really, really secure. Do they support containers yet (or microVMs)? Cuz if they do, I'm moving my workloads to obsd.
OpenBSD is the Linux of a decade or two ago, not attracting attention and not being compatible or useful for quite a lot of stuff.
Just OpenSSH, nothing ;)
Not counting GPU compute, what exactly is OpenBSD not useful for?
Personal laptop use with Ada Lovelace or Ampere family NVIDIA GPUs (did you mean this or CUDA, i couldnt tell), personal desktop use with unusual peripherals, dependency on ports, existence and competition of FreeBSD etc. I love OpenBSD's code philosophy (they were the first to introduce a lot of security techniques[1]) and the programs they produce, OpenSSH is a lifesaver, and I use doas for its low footprint on my Linux machine. Still, they have a convulated install process, dubious hardware and software compatibility that is better solved in the Linux world today.
[1]: https://www.openbsd.org/innovations.html
So pretty much only GPU compute (CUDA) and exotic peripherals?
I don't see any ports dependency issues as there's been binary packages available forever. Even the install process is a lot faster than any linux I have to use at $work, not to mention easier to automate with autoinstall[0] if needed.
[0]https://man.openbsd.org/autoinstall.8
GPU driver support is not limited to CUDA. Devices that require binary blobs of firmware to work properly are not always exotic. Some examples off the top of my head that won't work with OpenBSD hassle-free is Vantage (LLL), Solaar ... but I haven't tested. I understand you finding it easier to work with and it's faster install speeds do pique my interest, yet you being on HN already puts your technical literacy on some low % of gen pop. OpenBSD may be comparable to distros like Gentoo, Void or Arch but certainly not out-of-the-box ones like Ubuntu. They serve different auidences.
Try illumos with zones. We run all critical services on SmartOS nowadays. Even linux bhyve VMs get confined inside a zone.
If there was a similar class of bug in the illumos kernel, it would also allow for a container escape, no?
There are many issues with the formulation of containers on Linux (though I think people overstate it whenever bugs like this happen) but ultimately this bug was a UAF that gave you arbitrary code execution in the kernel. Zone IDs are also just numbers in kernel memory... right?
Not necessarily. Zones in illumos (and Solaris before) were designed from ground up to be secure in multitenant workloads[0]. It's quite different from the duct tape style[1] of linux containerization.
[0]https://www.usenix.org/legacy/event/lisa04/tech/full_papers/...
[1]Tape different things together and see if it holds.
I am aware of the history behind Zones and Jails, but my point is still the same -- the (lack of) protection you get against kernel exploits should be the same because the only thing protecting you from escapes is kernel data structures.
(I've been one of the maintainers of runc -- the most widely use used container runtime on Linux -- for more than a decade, so I'm at least somewhat well-informed on the topic.)
The duct tape criticisms are fair when talking about other vulnerabilities (such as when container runtimes have misconfiguration or other inatomicity bugs) but not really here in the context of a kernel arbitrary code execution gadget. It also seems quite unlikely that the illumos kernel doesn't contain any of these kinds of bugs.
> Do we really need infosec companies now that a skid with claude can find decades-old kernel privesc over a weekend?
Why are you not making easy money hand over fist from these rewards? A couple of weekends of work and you can retire early.
Maybe that's exactly what these infosec companies are. And maybe you need more than "a skid with claude over a weekend" to get anything worthwhile.
Why didn't you find it with claude over a weekend?
> and is really, really secure
... until its getting popular usage and gets targeted for vulnerability research
TIL OpenBSD doesn't have jails