Read our technical walkthrough here to see how we won almost $10k bug bounty from a single Linux kernel 0-day -- GhostLock.
Chaining GhostLock with a Firefox 0-day, we managed to remote control any Android device (even the latest Android 17) from a simple URL click. We name this full-chain exploit "IonStack", because it's IonMonkey 0-day in Firefox and a StackOverflow in Linux kernel.
Wow. A universal, unprivileged local kernel stack use-after-free enabling ~97%-reliable privilege escalation and container escape via a constrained write primitive, control-flow hijack, and ROP
The bug itself is almost boring - remove_waiter() clearing current's pi_blocked_on instead of the actual waiter's — which is exactly why it survived 15 years.
What do you mean, "no mitigation" and "except for kernel updates"?
Somebody made a mistake. Somebody found the mistake, and told the maintainers (and even offered a draft patch). The maintainers fixed the mistake and gave the person who found it a prize.
Granted, I'm grouchy about the fact that software engineering is just about the only engineering field which is neither licensed nor bonded nor insured... which sure, makes it more accessible, but also means that software engineering is "like a box of chocolates: you never know what you're gonna get".
(Meanwhile, all the other engineering fields say things like "those regulations are written in blood").
But of all the subspecialties to complain about, I'm not picking on security research. At least security research has an industry norm of responsible disclosure, plus filing CVEs into a neat database so we can know which bugs impact what, plus an industry norm of bug bounty programs to give awards to security researchers as a thank-you (instead of leaving things open to cybercriminals who will find the same issue and use it for nefarious purposes).
To me, that sounds like a model that everybody else should strive for.
I suppose we could talk about whether there could have been more testing or linting or something to prevent the mistake from getting out to production in the first place. But 1. this mistake is pretty subtle -- of all the mistakes to happen, this one seems relatively understandable 2. spending more on prevention seems like a great way for businesses to spend less on bug bounty payouts ;)
Who knows... someday, we might get to a point where software is actually expected to be defect-free once it reaches production, to the point where patch updates are a rare surprise.
That's obviously not the case today, but here's hoping.
When I said about "no mitigations except for the kernel updates" I meant exactly that. Some sysctl config to flip, some kernel module to unload. Apparently such thing doesn't exist in this one
Read our technical walkthrough here to see how we won almost $10k bug bounty from a single Linux kernel 0-day -- GhostLock.
Chaining GhostLock with a Firefox 0-day, we managed to remote control any Android device (even the latest Android 17) from a simple URL click. We name this full-chain exploit "IonStack", because it's IonMonkey 0-day in Firefox and a StackOverflow in Linux kernel.
Our blog post -> https://nebusec.ai/research/ionstack-part-2/
Exploit Github -> https://github.com/NebuSec/CyberMeowfia
Wow. A universal, unprivileged local kernel stack use-after-free enabling ~97%-reliable privilege escalation and container escape via a constrained write primitive, control-flow hijack, and ROP
* Introduced in Linux 2.6.39 in 2011
* patched in 7.1 (April 2026)
The bug itself is almost boring - remove_waiter() clearing current's pi_blocked_on instead of the actual waiter's — which is exactly why it survived 15 years.
it's all so tiresome
so no mitigation except for kernel updates?
What do you mean, "no mitigation" and "except for kernel updates"?
Somebody made a mistake. Somebody found the mistake, and told the maintainers (and even offered a draft patch). The maintainers fixed the mistake and gave the person who found it a prize.
Granted, I'm grouchy about the fact that software engineering is just about the only engineering field which is neither licensed nor bonded nor insured... which sure, makes it more accessible, but also means that software engineering is "like a box of chocolates: you never know what you're gonna get".
(Meanwhile, all the other engineering fields say things like "those regulations are written in blood").
But of all the subspecialties to complain about, I'm not picking on security research. At least security research has an industry norm of responsible disclosure, plus filing CVEs into a neat database so we can know which bugs impact what, plus an industry norm of bug bounty programs to give awards to security researchers as a thank-you (instead of leaving things open to cybercriminals who will find the same issue and use it for nefarious purposes).
To me, that sounds like a model that everybody else should strive for.
I suppose we could talk about whether there could have been more testing or linting or something to prevent the mistake from getting out to production in the first place. But 1. this mistake is pretty subtle -- of all the mistakes to happen, this one seems relatively understandable 2. spending more on prevention seems like a great way for businesses to spend less on bug bounty payouts ;)
Who knows... someday, we might get to a point where software is actually expected to be defect-free once it reaches production, to the point where patch updates are a rare surprise.
That's obviously not the case today, but here's hoping.
whoa, didn't expect a wall of text
When I said about "no mitigations except for the kernel updates" I meant exactly that. Some sysctl config to flip, some kernel module to unload. Apparently such thing doesn't exist in this one
[dead]