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.
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]
> 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.
"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
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.
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.
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)
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.
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).
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).
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.
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
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.
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?
Please don't be snarky or cross into putdowns or personal attack. We're all in (let's call it) the unlucky 10,000 about something. About most things actually.
To an extent that's fair, but you do understand that "ive not heard of a vulnerability older than me" begs credulity? Especially with the fifteen years experience comment? I'm all for not being snarky (I'm not), but this was bait
There is an interesting episode of This American Life about how everyone, everyone, has weird gaps in their knowledge that eventually get filled in sometimes fun or humiliating ways. You have these too.
Hey guys - please don't do tit for tat spats on HN. I know how it feels (believe me, I know how it feels down to such a level that any hypothetical offspring would also know how it feels), but it only makes everything worse.
Hey guys - please don't do tit for tat spats on HN. I know how it feels (believe me, I know how it feels down to such a level that any hypothetical offspring would also know how it feels), but it only makes everything worse.
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.
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.
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.
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
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.
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!).
Good news for reusing old phones and taking control.
*as in replace
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...
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.
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...
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
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.
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.
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.
Many (maybe most) containers actually default to running programs as root. Kernel exploit not required.
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).
I would have hoped that only a few of us are so misinformed as to do that.
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.
I'm all ears now
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.
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.
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 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.
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.
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.
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.
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.
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?
https://blog.jle.im/entry/functors-to-monads-a-story-of-shap...
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.
It was even enumerated in the first pass of CWE as CWE-416 in 2006.
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.
"Use after free" is also described in most standard books about C as a thing you should never do, have you read one?
The idea that Claude came up with it is ridiculous.
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.
https://news.ycombinator.com/newsguidelines.html
These are the times we make.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
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.
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.
... until its getting popular usage and gets targeted for vulnerability research