On 5/21/26 14:25, Hyunwoo Kim wrote: > On Thu, May 21, 2026 at 08:06:41PM +0200, Solar Designer wrote: >> Hi, >> >> On Fri, May 22, 2026 at 02:19:42AM +0900, Hyunwoo Kim wrote: (snip)
>>> 4. https://github.com/v12-security/pocs/tree/main/fragnesia-5db89c99566fc >>> (2026-05-15) >>> >>> Note that the fourth PoC was confirmed to be blocked as well by the v3 >>> fix (skb_gro_receive) [1] that resolves the third PoC, >> >> This matches Sultan's analysis. It may be that the rediscovery by V12 >> was based on Sultan's public posting on the issue (including exploit). >> I called them out on this in their Twitter thread and got no reply. >> >>> and the v4 [2] and v5 [3] changes address potential issues. >>> >>> As long as the in-place path in esp remains, further variants of this >>> kind are expected to be found in the esp module. As mentioned >>> previously, I recommend keeping the mitigation in place for the time >>> being. >> >> As a maybe better mitigation, can we somehow make in-place / zero-copy >> runtime configurable, and not only for esp? > > A generic mechanism would require careful trade-off analysis, and I > don't yet have a good idea for it. > > That said, at least for the networking stack, it looks likely that > the root cause will be addressed going forward: > https://lore.kernel.org/all/[email protected]/ What about netfilter? That can also mutate packets. Does it always copy? -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
