https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo
https://afflicted.sh/blog/posts/copy-fail-2.html
the bug
MSG_SPLICE_PAGES attaches pages from a pipe directly to an skb — no copy, the skb’s frags reference the pipe buffer’s pages. for TCP the path sets SKBFL_SHARED_FRAG on those skbs, which downstream consumers check before mutating frag bytes. for the IPv4/IPv6 datagram append paths, the flag was never set. so a UDP skb built with MSG_SPLICE_PAGES looked, to a downstream consumer, like an ordinary uncloned nonlinear skb whose frags it could mutate freely.
the consumer in question is esp_input():
// net/ipv4/esp4.c (pre-fix) } else if (!skb_has_frag_list(skb)) { nfrags = skb_shinfo(skb)->nr_frags; nfrags++;
goto skip_cow;
}
skip_cow jumps past the skb_cow_data() call. the remaining code path runs the AEAD decrypt in place over the existing scatterlist — which, since the frags are pipe pages we still hold open in userspace, are page-cache pages of whatever file we spliced from.
the kernel writes the decrypt output into those pages. they are still mapped into our pipe. they are also still the page cache for the file. so the kernel just wrote attacker-influenced bytes into the page cache of any readable file we can splice().
the Fixes: chain spans 2017 (esp no-COW fast path for both v4 and v6) and 2023 (UDP/UDP6 MSG_SPLICE_PAGES support). every mainline kernel that has all four sits in scope
A naive attacker will leave log entries and other traceable things behind but an experienced attacker who has gained root permissions can clean up behind themselves very quickly. So yes it’s traceable but in practice it can be hard to find evidence.
There is a lot of concern for situations like you describe but in practice generic users have many paths to privilege escalation if they choose to try. You should either never let untrusted users have access to your systems or take special precautions anyway.
This exploit was notable for it’s ease of use and that it was announced before a patch was released leaving a window of vulnerability. But OS maintainers are on top of things, my debian servers have already rebooted this morning with the mitigation. So overall not too bad as these things go.