← Feed
@rene_mobile@infosec.exchange
Post #2409456
2026-05-10 21:35 UTC
Releasing a universal #Linux #kernel #exploit with very little or even no previous time to distribute a patch through distributions is not cool. Doing it on the day before a weekend - on two weekends in a row - is just being an asshole. Looking at you, #CopyFail and #DirtyFrag.
You may think it helps your PR, that people will queue to use your cool new AI/agentic/whatever tool because you found the bug. You may think that releasing the full exploit because somebody else was even quicker with "leaking" your cool find makes it right. You're wrong. This is neither responsible nor coordinated disclosure. In security, we've tried to learn the hard lessons on keeping in-production, live systems on a global scale safer.
Yes, those bugs have existed for a long time in the kernel source. Yes, other bad actors may already have found them. But you're shining a light on it *and* giving every script kiddie in the world a working exploit to point their mass scans at. That's dangerous. There's a reason why the normal process is to reach out at least to the most widely installed distributions before releasing the bug details publicly. There's a reason why 90 days is a good default - it allows downstream percolation of patches. You can still get the credit. This way, you only create stress for admins.
[For a little relief, refer to https://www.tomshardware.com/tech-industry/cyber-security/dirty-frag-exploit-gets-root-on-most-linux-machines-since-2017-no-patches-available-no-warning-given-copy-fail-like-vulnerability-had-its-embargo-broken for a quick mitigation, because updating kernels and rebooting a fleet of hosts just takes time, weekend or not. #HugOps]
Replies (4)
-
@rene_mobile@infosec.exchange https://github.com/atgreen/rhel-block-copyfail is a runtime block for all three - without needing a reboot. Install and start service. Then have weekend and patch when you can finally reboot the machines in a few days
Open ##2604726
-
@rene_mobile@infosec.exchange I thought I read that dirtyfrag was originally disclosed responsibly, with a delay before publication, but someone else leaked it, so the discoverer had to publish so that people would know. What I read said that was pretty much standard procedure. Is there some article that’s saying this wasn’t the case?
Open ##2604727
-
@rene_mobile@infosec.exchange Dirty frag's embargo was broken due to it being published by an unrelated source, no? So it's not exactly their fault
Open ##2604731
-
@rene_mobile@infosec.exchange FTR: Four weekends at this point, we got another Dirty Frag variant last week and on Friday, this dropped: https://gist.github.com/lcfr-eth/2566a5cef312c94a5ff8d62fa417955f
(but that one isn't *too* widespreadly applicable out of the box)
Open ##2850778