We won $92,337 bug bounty using a single kernel 0-day

https://nebusec.ai/research/ionstack-part-2/

by etenal • 15 days ago

31 9 15 days ago

etenal• 15 days ago

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

djfergus• 15 days ago

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)

tryauuum2• 15 days ago

it's all so tiresome

so no mitigation except for kernel updates?

xtajv• 13 days ago

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.

tryauuum2• 13 days ago

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

ranger_danger• 11 days ago

I believe they were speaking from the perspective of a general Linux user who wishes for their system to no longer be affected by this bug/exploit, and was asking if there are any ways to mitigate the issue (such as blacklisting certain modules ala other recent LPEs), short of updating to a patched kernel version.

valentynkit• 14 days ago

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.

We won $92,337 bug bounty using a single kernel 0-day

Related Stories