So if I found a vulnerability that lets hackers withdraw withdraw all the money in your account without a trail on where the money went, you'd be fine with them disclosing it to the public at the same time as the bank learns about it?

Even when there is no known use case of the attack (other than the security researcher's)?

> The vulnerability exists for me either way, and I'd rather have the chance to know about it and minimize risk

By the time you hear about it, the money could be gone because 1000 hackers heard about it from the researcher before you did.

> than to be surprised by the fix and hope nothing bad happened in that meantime.

Hope is not a good strategy here.

Yep, I'd be fine with that. My bank has insurance, and my money would be returned.

Seeing your other (rightfully flagged) reply I want to tell you as a neutral party that yes this is missing the point of the analogy. You're basically saying "I would simply hit the brakes on the trolley". It's not that they're so hubristic they think it's impossible to legitimately disagree with their argument, it's that mentioning insurance is sidestepping their argument entirely. You're not addressing the general idea of getting hacked and suffering the consequences of the hack.

You're missing the point (not sure if you're just being dense on purpose...). If you're bank would just return the money then its not a good analogy. If someone gains root access to your machine, presumably they can do damage that can't be undone. In other words, to continue the bank analogy, they would take all your money and you would have no way of getting it back. Presumably, you would not be ok with this. And even if, for some weird reason, you were ok with that, 99.9% of all other people would not be ok with it.

Respectfully, I don't think they're missing the point. Banking, as an institution, has its flaws, but deposit insurance isn't one of them. These vulnerabilities exist whether or not they follow specific disclosure rituals, and systems should be deployed with defense-in-depth so that one privilege-escalation flaw is a recoverable event. Inventing tortured counterfactual analogies doesn't change the basic thrust of the poster's point: the account is insured, so getting drained by an attacker is not a fatal problem. Of course people should still take steps to prevent that from happening, but that doesn't mean prevention is (or should be) the only cure.

My point specifically is that some damage isn't recoverable if there's a vulnerability that gives someone root access. This makes the bank analogy inadequate in the first place. Im not trying to argue about whether deposit insurance is good or bad. Saying they would get the money back assumes the damage done to ones machine would be recoverable, which may not be the case.

I apologize if I'm missing something obvious here, not trying to be difficult.

My understanding is that FDIC deposit insurance only protects against bank failure, not fraudulent activity. Getting your account drained by an attacker may or may not be covered by a patchwork of other laws at various levels, and you could very well end up shit out of luck.

The banks cost of insurance goes up, cost of running an account goes up, how do we correct for this? offer worse accounts to customers...

Why do you assume banks would keep on doing the same old thing but paying more because of it? The cost would make them learn not to design systems where something like this hypothetical scenario was possible.

"I, personally am not affected, and I don't care about anyone else so therefore there are no consequences"

Just socialize losses and all is well.

What could possibly go wrong?

that is basically how all large companies behave anyway. socialize the losses (bailouts, layoffs, negative economic impacts in the communities they reside, etc.) and privatize the gains.

> that is basically how all large companies behave anyway

And do you agree with that behaviour?

nope

And what is the insurance in the Linux case, for which the analogy was being made?

Linux was informed properly, and the vuln was not disclosed until 30 days after the kernel was patched.

The real debate here is what went wrong with getting that info downstream, and whose responsibility was that?

“The choice that maximizes potential damage isn’t irresponsible, because it means I can mitigate my own systems immediately.”

That’s what you’re saying here.

They're literally just restating the argument for full disclosure security. This is one of the oldest debates in information security.

The disclosure doesn't appear very "full". Looks like this was slipped into mainline linux among dozens of other mostly-irrelevant "CVEs" with nobody highlighting the fact that it is in fact dirty-cow-on-steroids.

https://x.com/spendergrsec/status/2049566830771970483

https://lore.kernel.org/linux-cve-announce/2026042214-CVE-20...

Or is everyone expected to upgrade and reboot every 48 hours for all eternity and just deal with potential regressions all the time?

I think this reflects poorly on the original reporters. If you have a weaponized 700-byte universal local root exploit script ready to go, perhaps you should coordinate with major distros for patches to be available before unleashing it on the world. No matter how "veteran" you are.

Um, yes, everyone is expected to upgrade and reboot on a moment's notice. No policy or norm you come up with will change that.

(This bug does not technically require a reboot to mitigate).

I think I must misunderstand. Are you saying that you upgrade and reboot every production system that you administer to apply each commit to the kernel (branch it's using) essentially immediately? That doesn't make sense to me for a few reasons, but I struggle to find a different reading that applies "upgrade and reboot on a moment's notice" to the "slipped into mainline linux" scenario. Kindly help me to do so.

No: your posture with respect to having to cycle servers is a super complicated subject and you address it both with process and with architecture (for instance: you can be blasé about things like CopyFail if you don't allow multitenant shared-kernel in your design in the first place). But no matter what process and design you have, if you're hosting sensitive workloads, you always have to be in a position where you can metabolize having to cycle your servers.

It's a category error to talk about a disclosure event like this as something that would destabilize someone's fleet operations. The Linux kernel is fallible. So is the x64 architecture. You already have to be ready to lock things down and reboot (or mitigate) at a moment's notice.

Remember: whatever else grumpy sysadmins have to say about this, Xint are the good guys. Contrast them with the bad guys, who have vulnerabilities just as bad as CopyFail, but aren't disclosing them at all --- you only find out about them when it's discovered they're actively be exploited. There's no patch at all. There isn't even a characterization of how they work, so that you could quickly see what to seccomp. That's the actual threat environment serious Linux shops operate in.

LPEs are not rare.

Oh, I thought you meant "everyone" in a sense including actual human persons and the devices on their home network.

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.

What the heck is up with people today.

Using quotes around something where you’re actually doing a strawman paraphrase of another commenter you disagree with is bad form.

It was clear that the original comment didn't say that, since we can see it right above. It was clear to me that the GP was using quotes as a way to use direct speech, not to imply that the GP literally said those words.

Those groups care about whether millions of computers are vulnerable, likely including your computer. If "immediate public disclosure" was done in all cases every vuln would be exploited and patches would be much lower quality. Shortening the disclosure timeline might be a good idea, 90 days is starting to feel long.

Millions of computers are still vulnerable. Not-knowing about it doesn't mean the vuln isn't there :p

But now millions more people know about how to exploit it who didn't before. I don't see why you're struggling with this.

You can't bully me into agreeing with you. Why are you struggling with that?

That was my first comment in the thread. I'm not bullying you; if you don't want people to challenge your statements then you came to the wrong place ;-)

You are engaging in bad faith when you act like I only have the belief I have because I don't understand yours yet. Don't comment if you can't respect somebody disagreeing with you.

Being vulnerable is not the important part. They have been vulnerable for years. The problem is the probability of being exploited. If everyone knows about the exploit details before a proper patch is available the number of exploited systems will skyrocket

The Venn diagram of mainstream distros and individual Linux users is virtually a circle.

Ubuntu/RHEL is vulnerable and so are most Linux users by extension.

With immediate disclosure the provider can decide to shut down while it is fixed. Or to notify users and make it their decision. Or to be prepared with a diversified infra and switch over to a non-vulnerable path. e.g, BSDs are not affected by CopyFail

> Immediate public disclosure is the only choice that isn't irresponsible as far as I'm concerned.

No, it's really not.

High severity vulnerabilities are responsibly handled by quietly neutralising them with subtle patches that do not reveal the vulnerability, waiting for those patches to distribute. Then patching or removing the root cause of the vulnerability (at which point opportunists will start to notice), and finally publicly disclosing it when there are already good mitigations in place.

Example: spectre/meltdowm mitigations.

I've been asked to use this approach myself when reaching out to maintainers. Sometimes it's possible to directly fix the vulnerability as a "side effect" by making a legitimate adjacent change.