The 3 recent Linux LPEs are sort of interesting in that each one took a different path from discovery to disclosure.
-
The 3 recent Linux LPEs are sort of interesting in that each one took a different path from discovery to disclosure.
- Copy Fail: Publicity stunt where they claim to have done the right thing, yet didn't bother to tell a single distro vendor, and lied about updates being available.
- Dirty Frag: Attempted to do proper coordination, including notifying the
linux-distrosmailing list. But the embargo was broken, so it was disclosed unexpectedly ahead of time. - Copy Fail 2: Discovered as an n-day by looking at kernel commit logs and Spender noticing that it was copyfail-class
Each path had basically exactly the same outcome (No fixes at publication time).
@wdormann All this proves is that the world is full of bad eggs and you have to look out for yourself by adopting zero-trust.
It doesn't mean that white hats shouldn't disclose early to distros to give them time to fix, and red hats still need to push back on the black hats.
-
@wdormann Dirty Frag: embargo breach has been done by who and how?
2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.
️ -
@wdormann I pasted your toot in claude asking if the three are somehow related other than by all of them being LPEs.
Result: "This request triggered restrictions on violative cyber content and was blocked [...] request an adjustment pursuant to our Cyber Verification Program..."
hmm....
-
2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.
️@wdormann really would like to see some proof on that.
-
@mxk @wodny
Ah right.
Dirty frag is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4 and a yet to be committed fix.Copy Fail 2 is also https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4
-
@wdormann Dirty Frag and Copy Fail 2 target the same bug, correct?
My understanding is that the Copy Fail 2 publication on Github _is_ the "broken embargo" that triggered publication of Dirty Frag.
-
-
The 3 recent Linux LPEs are sort of interesting in that each one took a different path from discovery to disclosure.
- Copy Fail: Publicity stunt where they claim to have done the right thing, yet didn't bother to tell a single distro vendor, and lied about updates being available.
- Dirty Frag: Attempted to do proper coordination, including notifying the
linux-distrosmailing list. But the embargo was broken, so it was disclosed unexpectedly ahead of time. - Copy Fail 2: Discovered as an n-day by looking at kernel commit logs and Spender noticing that it was copyfail-class
Each path had basically exactly the same outcome (No fixes at publication time).
And just to clarify about "Dirty Frag" vs. "Copy Fail 2":
Dirty Frag is TWO vulnerabilities:
- The xfrm-ESP Page-Cache Write vulnerability has been assigned CVE-2026-43284 and patched in mainline at f4c50a4034e6.
- The RxRPC Page-Cache Write vulnerability has been reserved as CVE-2026-43500 for tracking; no patch exists in any tree yet.
Copy Fail 2 is a "clean room" rediscovery/exploitation of f4c50a4034e6 (CVE-2026-43284)
Since Copy Fail 2 was published to GitHub 1 hour earlier than Dirty Frag was published. The Dirty Frag writeup specifies that the embargo was broken, and as a result TWO vulnerabilities were disclosed.
Personally, I think that if you publish a patch for a vulnerability, and then you begin an embargo a week after it was published, that doesn't really count as an "embargo"?
️Fun stuff...
-
@troed @wodny
The irony of this:
The Dirty Frag timeline shows that the patch was published a week before the "embargo" was started.And when the "embargo" was broken, Dirty Frag was published, releasing TWO vulnerabilities.
How one embargoes something that is essentially public already is a head-scratcher.
-
@troed @wodny
The irony of this:
The Dirty Frag timeline shows that the patch was published a week before the "embargo" was started.And when the "embargo" was broken, Dirty Frag was published, releasing TWO vulnerabilities.
How one embargoes something that is essentially public already is a head-scratcher.
-
2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.
️@wdormann @Lioh I think that refers to the copy fail 2 release, which (from link in top post in this thread, repeated below) seems to be someone who reverse engineered one of the (dirty pipe) bugs from the upstream kernel fix and wrote it up (presumably originally assuming it was already fixed / shipped).
An “embargo” with patches in public is… always going to be fragile. (Looks like “accidental duplicate find” here, because of first copy fail.)
-
And just to clarify about "Dirty Frag" vs. "Copy Fail 2":
Dirty Frag is TWO vulnerabilities:
- The xfrm-ESP Page-Cache Write vulnerability has been assigned CVE-2026-43284 and patched in mainline at f4c50a4034e6.
- The RxRPC Page-Cache Write vulnerability has been reserved as CVE-2026-43500 for tracking; no patch exists in any tree yet.
Copy Fail 2 is a "clean room" rediscovery/exploitation of f4c50a4034e6 (CVE-2026-43284)
Since Copy Fail 2 was published to GitHub 1 hour earlier than Dirty Frag was published. The Dirty Frag writeup specifies that the embargo was broken, and as a result TWO vulnerabilities were disclosed.
Personally, I think that if you publish a patch for a vulnerability, and then you begin an embargo a week after it was published, that doesn't really count as an "embargo"?
️Fun stuff...
And in case Dirty Frag wasn't unpatched enough for you, IKotas labs has found a new variant of Dirty Frag
So far, patches have only landed in today's Linux 7.0.6 and 6.18.29.
-
R relay@relay.infosec.exchange shared this topic
-
And in case Dirty Frag wasn't unpatched enough for you, IKotas labs has found a new variant of Dirty Frag
So far, patches have only landed in today's Linux 7.0.6 and 6.18.29.
@wdormann Ok Siri, how do I temporarily disable the Linux kernel in general
-
And in case Dirty Frag wasn't unpatched enough for you, IKotas labs has found a new variant of Dirty Frag
So far, patches have only landed in today's Linux 7.0.6 and 6.18.29.
@wdormann English version of that post: https://ikotaslabs.com/news/2026-05-11?page=1&lang-en
-
@wdormann English version of that post: https://ikotaslabs.com/news/2026-05-11?page=1&lang-en
-
That's a nice find.
Just tried in an incognito Window without Google Translate active but with JavaScript active.
- Japanese: https://ikotaslabs.com/news/2026-05-11?page=1
- English: https://ikotaslabs.com/news/2026-05-11?lang=en
- English as well: https://ikotaslabs.com/news/2026-05-11?page=1&lang=en
- English as well: https://ikotaslabs.com/news/2026-05-11?page=1I think it is setting a lang=en cookie the first time it encounters a lang=en parameter, but does not always return an English translated page unless the lang=en cookie is in the request.
-
That's a nice find.
Just tried in an incognito Window without Google Translate active but with JavaScript active.
- Japanese: https://ikotaslabs.com/news/2026-05-11?page=1
- English: https://ikotaslabs.com/news/2026-05-11?lang=en
- English as well: https://ikotaslabs.com/news/2026-05-11?page=1&lang=en
- English as well: https://ikotaslabs.com/news/2026-05-11?page=1I think it is setting a lang=en cookie the first time it encounters a lang=en parameter, but does not always return an English translated page unless the lang=en cookie is in the request.
@wiert
I mean, even Mastodon itself renders the link in your first reply as Japanese.️
-
@wiert
I mean, even Mastodon itself renders the link in your first reply as Japanese.️@wdormann maybe it requests it once and without a lang=en cookie set?
The web is full of surprises, not limited to security vulnerabilities (;
-
@wdormann maybe it requests it once and without a lang=en cookie set?
The web is full of surprises, not limited to security vulnerabilities (;
@wiert
Eh, I blame their web server.
-
@wiert
Eh, I blame their web server.Odd indeed, and I still think it is caused by the `lang=en` request cookie being absent or present: the Mastodon preview cards are generated server side without sending cookies.
There is a good description of the Mastodon preview cards state of affairs at https://box464.com/posts/mastodon-preview-cards/
(I had to in-place edit `data-mode="dark"` in the html header into `data-mode="light"` to force it to become readable)
The preview request is at https://github.com/mastodon/mastodon/blob/main/app/services/fetch_link_card_service.rb#L56 (search for `Request.new`).
