alecco 1 day ago 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
cassianoleal 1 day ago How is this different from Dirty Frag [0]?It seems to use the same vector.[0] https://github.com/V4bel/dirtyfrag auscompgeek 1 day ago From what I can gather it is the exact same vulnerability.
cpach 1 day ago Does anyone know how to mitigate this one? Is it sufficient to disable the esp4/esp6/rxrpc modules?
Mindless2112 1 day ago How much pain must there be until people realize we actually do need memory safety? delamon 1 day ago How would've memory safety helped here? Mindless2112 1 day ago 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. delamon 1 day ago 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). Mindless2112 1 day ago 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. delamon 1 day ago Apparently it is both... tatersolid 1 day ago Because “Page-cache write into any readable file” is a memory safety bug? All of these recent Linux LPEs are memory safety issues.
delamon 1 day ago How would've memory safety helped here? Mindless2112 1 day ago 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. delamon 1 day ago 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). Mindless2112 1 day ago 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. delamon 1 day ago Apparently it is both... tatersolid 1 day ago Because “Page-cache write into any readable file” is a memory safety bug? All of these recent Linux LPEs are memory safety issues.
Mindless2112 1 day ago 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. delamon 1 day ago 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). Mindless2112 1 day ago 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. delamon 1 day ago Apparently it is both...
delamon 1 day ago 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). Mindless2112 1 day ago 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. delamon 1 day ago Apparently it is both...
Mindless2112 1 day ago 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. delamon 1 day ago Apparently it is both...
tatersolid 1 day ago Because “Page-cache write into any readable file” is a memory safety bug? All of these recent Linux LPEs are memory safety issues.
nonamesleft 1 day ago sysctl kernel.unprivileged_userns_clone=1 keeps on giving. sickthecat 1 day ago 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?
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...
Because “Page-cache write into any readable file” is a memory safety bug? All of these recent Linux LPEs are memory safety issues.
sysctl kernel.unprivileged_userns_clone=1 keeps on giving.
Yes. Giving me a massive... Well.. Dopamine rush.