The 3 recent Linux LPEs are sort of interesting in that each one took a different path from discovery to disclosure.
-
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`).
-
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`).
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.
-
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.
(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)
-
(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)
@wiert
Eh, sorry. It's not past my threshold of caring enough at this point.
-
@wiert
Eh, sorry. It's not past my threshold of caring enough at this point.@wdormann I thought so, but not asking means definitely a "no" answer
-
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.
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"
-
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"@wdormann wow another? nice
-
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"@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?
-
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"@wdormann oooooh, look at that shiny flickering ASCII animation. No AI-vuln-something marketing content here at all.
-
@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?
@AwkwardTuring
Yes, the Dirty Frag mitigation works to protect against fragnesia CVE-2026-46300 as well.
-
@AwkwardTuring
Yes, the Dirty Frag mitigation works to protect against fragnesia CVE-2026-46300 as well.@wdormann misunderstanding
I meant if dirty frag >patch< works for fragnesia
