[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ag9OMvUP7tEWWEma@v4bel>
Date: Fri, 22 May 2026 03:25:54 +0900
From: Hyunwoo Kim <imv4bel@...il.com>
To: Solar Designer <solar@...nwall.com>
Cc: oss-security@...ts.openwall.com,
Sultan Alsawaf <sultan@...neltoast.com>, imv4bel@...il.com
Subject: Re: Linux kernel: Dirty Frag variants — fix merged into netdev
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/20260514163802.1d49d7cb@kernel.org/
Best regards,
Hyunwoo Kim
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
