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.
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'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.
I think you're probably right that the article was AI-assisted, but (if so) it's important not to confuse that property of the article 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 a huge one that is in a state of chaotic turbulence right now. I'm working on a post about that over 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 very 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.
Personally I'm down with the "writing is thinking" crowd, 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.
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')
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 cargo-culted terms of art are starting to inform how we talk about our profession
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.
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 question 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. I'm at least somewhat well-informed on the topic.
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 Google Play integrity levels, limiting many sensitive 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]
> 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!).
Then I can finally get rid of my current workaround: running an auto-clicker on Google Ads until Google responds with a 429, which then stops ads from rendering on Android TV and Chromecast for a day or two.
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.
"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...
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.
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.
> 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.
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.
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.
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.
80 comments
[ 2.8 ms ] story [ 52.0 ms ] thread"Use after free" is also described in most standard books about C as a thing you should never do, have you read one?
I don't mean that as a criticism—the question of how to receive AI-processed content is a huge one that is in a state of chaotic turbulence right now. I'm working on a post about that over 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 very 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.
Obviously this is only one signal among many, one that can be overruled, but the ick remains regardless.
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.
Personally I'm down with the "writing is thinking" crowd, 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.
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.
I'm not a grammatical prescriptivist but I find it viscerally troubling that a bunch of cargo-culted terms of art are starting to inform how we talk about our profession
https://blog.jle.im/entry/functors-to-monads-a-story-of-shap...
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/
Imagine how much money you could make from these rewards. Why not go for it? A couple of weekends of work and you can retire early.
... until its getting popular usage and gets targeted for vulnerability research
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?
[0]https://www.usenix.org/legacy/event/lisa04/tech/full_papers/...
[1]Tape different things together and see if it holds.
I've been one of the maintainers of runc, the most widely use used container runtime on Linux, for more than a decade. I'm at least somewhat well-informed on the topic.
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 Google Play integrity levels, limiting many sensitive 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
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!).
Then I can finally get rid of my current workaround: running an auto-clicker on Google Ads until Google responds with a 429, which then stops ads from rendering on Android TV and Chromecast for a day or two.
Good news for reusing old phones and taking control.
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...
https://source.android.com/docs/core/architecture/kernel/gen...
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...
That then allows you to do secure NFC credit card payments even on a rooted phone with custom ROM.
Not a great solution.
Which hasn't been an issue since Chip & PIN became required, 22 years ago (at least over here).
Maybe I could even duct-tape it to my phone if I really want to do that.
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.
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.
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
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.
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.
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.
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.
Maybe just Algol68 and Rust can withstand this, among ADA. And PL/1 under Multics.
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.