The 3 recent Linux LPEs are sort of interesting in that each one took a different path from discovery to disclosure.
-
@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 -
@wdormann misunderstanding
I meant if dirty frag >patch< works for fragnesia@AwkwardTuring
Oh, sorry. I suppoi didn't read your message too carefully.
No, it's a separate patch, and therefore it should expected that the Dirty Frag patch does not fix fragnesia. The reasoning is that patches are precise, the mitigation for Dirty Frag is painted with a broad stroke (module level). -
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" -
@erlenmayr
Using / telling others a CVE ID before it actually exists is a choice, sure.But is not the recommended way to use CVE.
