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: > > With the help of several maintainers and developers, a v5 patch > > resolving the "publicly disclosed" Dirty Frag variants other than the > > CVE-2026-46300 (fragnesia) variant has been merged into netdev: > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=48f6a5356a33dd78e7144ae1faef95ffc990aae0 > > > > Separately, the patch resolving CVE-2026-46300 alone has been split > > into its own patch: > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=f84eca5817390257cef78013d0112481c503b4a3 > > Thank you very much Hyunwoo Kim for staying on top of this and focusing > on fixing the issues. Such a contrast from what some others are doing.
This is a bug class I understand well, so I intend to keep an eye on it going forward. > > > This 48f6a5356a33 patch addresses four "publicly disclosed" variants: > > > > 1. https://lore.kernel.org/all/agRhFtawP06hWyRa@v4bel/ (2026-05-13) > > 2. https://lore.kernel.org/all/agSx78pXBFCdn08p@v4bel/ (2026-05-13) > > 3. https://lore.kernel.org/all/agVpIsaSherjHTYg@sultan-box/ (2026-05-14) > > Variant 3 above was found (and exploit generated) by Sultan Alsawaf, my > colleague at CIQ, with use of "Claude Opus 4.6 (1M context)" with "hands > tied since we didn't yet have the cybersecurity bypass." (the quotes are > in Sultan's words) His work was genuinely important. He precisely caught something that could easily have been missed. > > > 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]/ Best regards, Hyunwoo Kim
