34 points | by larusso 12 hours ago
13 comments
People are blaming the wrong guy for breaking the embargo but via this blog post [1]:
> on 2026-05-05 Steffen Klassert pushed f4c50a4034 to netdev/net.git with Cc: stable@vger.kernel.org.
Once the fix is out it's usual for researchers to race to make the first exploit out of it.
[1] https://afflicted.sh/blog/posts/copy-fail-2.html
How is this different from Dirty Frag [0]?
It seems to use the same vector.
[0] https://github.com/V4bel/dirtyfrag
From what I can gather it is the exact same vulnerability.
Does anyone know how to mitigate this one? Is it sufficient to disable the esp4/esp6/rxrpc modules?
How much pain must there be until people realize we actually do need memory safety?
How would've memory safety helped here?
Because “Page-cache write into any readable file” is a memory safety bug? All of these recent Linux LPEs are memory safety issues.
In CHERI, for example, pointers have permissions. The pointer to the COW memory would not have the "write" permission.
I could be misunderstanding the bug, of course.
If you "forget" to mark COW memory pointer as no-write, the net effect would be same, would it not? If I'm reading the diff correctly, the problem was that code missed to mark some pages as shared (aka no-write).
A fair point...
I thought the bug was a missing check for the COW flag, but looking at it again it seems it was missing both setting and checking the flag.
Apparently it is both...
sysctl kernel.unprivileged_userns_clone=1 keeps on giving.
Yes. Giving me a massive... Well.. Dopamine rush.
People are blaming the wrong guy for breaking the embargo but via this blog post [1]:
> on 2026-05-05 Steffen Klassert pushed f4c50a4034 to netdev/net.git with Cc: stable@vger.kernel.org.
Once the fix is out it's usual for researchers to race to make the first exploit out of it.
[1] https://afflicted.sh/blog/posts/copy-fail-2.html
How is this different from Dirty Frag [0]?
It seems to use the same vector.
[0] https://github.com/V4bel/dirtyfrag
From what I can gather it is the exact same vulnerability.
Does anyone know how to mitigate this one? Is it sufficient to disable the esp4/esp6/rxrpc modules?
How much pain must there be until people realize we actually do need memory safety?
How would've memory safety helped here?
Because “Page-cache write into any readable file” is a memory safety bug? All of these recent Linux LPEs are memory safety issues.
In CHERI, for example, pointers have permissions. The pointer to the COW memory would not have the "write" permission.
I could be misunderstanding the bug, of course.
If you "forget" to mark COW memory pointer as no-write, the net effect would be same, would it not? If I'm reading the diff correctly, the problem was that code missed to mark some pages as shared (aka no-write).
A fair point...
I thought the bug was a missing check for the COW flag, but looking at it again it seems it was missing both setting and checking the flag.
Apparently it is both...
sysctl kernel.unprivileged_userns_clone=1 keeps on giving.
Yes. Giving me a massive... Well.. Dopamine rush.