The 3 recent Linux LPEs are sort of interesting in that each one took a different path from discovery to disclosure.

[wdormann@infosec.exchange]

And just to clarify about "Dirty Frag" vs. "Copy Fail 2":

Dirty Frag is TWO vulnerabilities:

1. The xfrm-ESP Page-Cache Write vulnerability has been assigned CVE-2026-43284 and patched in mainline at f4c50a4034e6.
2. 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...

[wdormann@infosec.exchange]

@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.

[ferrix@mastodon.online]

@wdormann @troed @wodny there's so much less daylight than I thought between "a serious process for security professionals" and "oops all 0-day LPEs"

[ewenmcneill@cloudisland.nz]

@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.)

oss-security - Copy Fail 2 / Dirty Frag — n-day from public commit, not embargo break

(www.openwall.com)

[wdormann@infosec.exchange]

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.

[nyanbinary@infosec.exchange]

@wdormann Ok Siri, how do I temporarily disable the Linux kernel in general

[wiert@mastodon.social]

@wdormann English version of that post: https://ikotaslabs.com/news/2026-05-11?page=1&lang-en

[wdormann@infosec.exchange]

@wiert
Is it though?

Interstingly if I get rid of the page=1 part of your link, it works fine.

[wiert@mastodon.social]

@wdormann

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=1

I 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.

[wdormann@infosec.exchange]

@wiert
I mean, even Mastodon itself renders the link in your first reply as Japanese. ‍️

[wiert@mastodon.social]

@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@infosec.exchange]

@wiert
Eh, I blame their web server.

[wiert@mastodon.social]

@wdormann

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`).

[wiert@mastodon.social]

@wdormann

I just compared these:

```
curl --verbose --cookie-jar - 'https://ikotaslabs.com/news/2026-05-11?page=1&lang-en'
curl --verbose --cookie-jar - 'https://ikotaslabs.com/news/2026-05-11?lang-en'
```

and

```
curl --verbose --cookie-jar - --cookie "lang=en" 'https://ikotaslabs.com/news/2026-05-11?page=1'
```

The first two deliver Japanese returning cookie `lang=ja` ; the last one delivers English with a cookie `lang=en`.

All deliver `<html lang="ja">` which is very odd for the second one.

[wiert@mastodon.social]

@wdormann

(sorry, I thought I already had posted this one)

I tried multiple connections (we have two ISPs at home - hello redundancy) and sometimes it server side remembers the output language. Not sure why yet as I could not reliably reproduce this. This is intriguing. Any ideas?

//end (for now)

[wdormann@infosec.exchange]

@wiert
Eh, sorry. It's not past my threshold of caring enough at this point.

[wiert@mastodon.social]

@wdormann I thought so, but not asking means definitely a "no" answer

[wdormann@infosec.exchange]

Are you losing track of the Linux LPEs these days?
Good. Me too.

Here we have fragnesia.

It has been said that CVE-2026-46300 has been assigned for this issue, except that it hasn't. At least not yet.
And in case you don't yet believe that the Linux kernel's handling of CVEs is malicious compliance, note the wording of the CVE mention:

For those that like to track these by CVE ids...

Ubuntu (and Debian?) isn't affected, due to default AppArmor rules.

The same mitigation for Dirty Frag blocks this as well, so if you were on top of Dirty Frag protections, you don't need to worry about fragnesia.

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"

[viss@mastodon.social]

@wdormann wow another? nice

[awkwardturing@infosec.exchange]

@wdormann from GitHub: "This is a separate bug in the ESP/XFRM from dirtyfrag which has received its own patch. However, it is in the same surface and the mitigation is the same as for dirtyfrag."

Curious phrasing. Does that mean the patch (not: the mitigation) will work for this as well or no?