Copy Fail 2: Electric Boogaloo

36 points
1/21/1970
a day ago
by larusso

Comments


alecco

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

15 hours ago

cassianoleal

How is this different from Dirty Frag [0]?

It seems to use the same vector.

[0] https://github.com/V4bel/dirtyfrag

17 hours ago

auscompgeek

From what I can gather it is the exact same vulnerability.

13 hours ago

cpach

Does anyone know how to mitigate this one? Is it sufficient to disable the esp4/esp6/rxrpc modules?

16 hours ago

nonamesleft

sysctl kernel.unprivileged_userns_clone=1 keeps on giving.

20 hours ago

sickthecat

Yes. Giving me a massive... Well.. Dopamine rush.

20 hours ago

Mindless2112

How much pain must there be until people realize we actually do need memory safety?

21 hours ago

delamon

How would've memory safety helped here?

21 hours ago

Mindless2112

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.

20 hours ago

delamon

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

20 hours ago

Mindless2112

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.

20 hours ago

delamon

Apparently it is both...

19 hours ago

tatersolid

Because “Page-cache write into any readable file” is a memory safety bug? All of these recent Linux LPEs are memory safety issues.

10 hours ago