Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I find it curious to call someone dropping a weaponized root exploit before major distros or even LTS kernel git branches have patches ready "good guys". This could have been handled with much more grace.


Again: I made the actual distinction between bad guys and good guys clear. Good guys don't become bad guys simply because kernel security is an inconvenience to you.


There are more than just good guys and bad guys; in particular, there are also opportunists.

Opportunists are the ones who will sell a 0day to bad guys. Or who will drop a 0day publicly to promote their services. And they’ll fight tooth and nail against any actual legal obligation to engage in responsible and coordinated disclosure, because they make more money without that.


Seems like a classification you just made up to navigate a message board debate: the category that equates commercial vulnerability research for security products and people who sell zero-day vulnerabilities to bad guys.


People who sell zero-day vulnerabilities currently sell to both good guys and bad guys, they’re a third thing (mercenaries). However, that third thing is also bad, just a different kind of bad than what you’re calling “bad guys.”

The people selling weapons to the Taliban aren’t bad in the same way the Taliban are; one is bad for ideological reasons, the other is bad for enabling bad actors, even if they also sell to the good guys.


Whatever the entity you're thinking of that sells exploits/"CNE enablement packages", they're not in the same bucket as entities that find and disclose vulnerabilities.


Sounds like bounties are unnecessary then. The argument I’ve always seen for them is that if they don’t exist and aren’t substantial enough, the research will still happen but the results will go to the highest bidder.


You've never seen me argue that bounties are necessary.


Good. Doesn’t mean there aren’t others that make that argument though.


To be fair, once Xint gave the heads up and the kernel team committed a patch, what was Xint supposed to do? Keep asking the kernel security team to backport patches for the LTS kernels?

As soon as a patch is committed, the clock starts ticking, the exploit will be discovered by reverse engineering recent commits. The commit was made on April 1st, Xint disclosed it on the 29th. If the Kernel Security team had wanted to, they had 28 days to backport patches in the LTS branches...

So, I wouldn't put any blame on Xint there.


The Linux kernel team back-ported it to 6.18, 6.19, and 7.0 on 2026-04-11 and publicly disclosed the vulnerability via CVE on 2026-04-22.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: