Will DormannMay 8

The 3 recent Linux LPEs are sort of interesting in that each one took a different path from discovery to disclosure.

  • Copy Fail: Publicity stunt where they claim to have done the right thing, yet didn't bother to tell a single distro vendor, and lied about updates being available.
  • Dirty Frag: Attempted to do proper coordination, including notifying the linux-distros mailing list. But the embargo was broken, so it was disclosed unexpectedly ahead of time.
  • Copy Fail 2: Discovered as an n-day by looking at kernel commit logs and Spender noticing that it was copyfail-class

    • Each path had basically exactly the same outcome (No fixes at publication time). 😂

    Show threadWill DormannMay 8

    And just to clarify about "Dirty Frag" vs. "Copy Fail 2":

    Dirty Frag is TWO vulnerabilities:

  • The xfrm-ESP Page-Cache Write vulnerability has been assigned CVE-2026-43284 and patched in mainline at f4c50a4034e6.
  • The RxRPC Page-Cache Write vulnerability has been reserved as CVE-2026-43500 for tracking; no patch exists in any tree yet.

    • Copy Fail 2 is a "clean room" rediscovery/exploitation of f4c50a4034e6 (CVE-2026-43284)

    Since Copy Fail 2 was published to GitHub 1 hour earlier than Dirty Frag was published. The Dirty Frag writeup specifies that the embargo was broken, and as a result TWO vulnerabilities were disclosed.

    Personally, I think that if you publish a patch for a vulnerability, and then you begin an embargo a week after it was published, that doesn't really count as an "embargo"? 🤷‍♂️

    Fun stuff...

    Show threadWill DormannMay 11

    And in case Dirty Frag wasn't unpatched enough for you, IKotas labs has found a new variant of Dirty Frag still captured as CVE-2026-43500

    So far, patches have only landed in today's Linux 7.0.6 and 6.18.29.

    Show threadWill Dormann5d ago

    Are you losing track of the Linux LPEs these days?
    Good. Me too.

    Here we have fragnesia.

    It has been said that CVE-2026-46300 has been assigned for this issue, except that it hasn't. At least not yet.
    And in case you don't yet believe that the Linux kernel's handling of CVEs is malicious compliance, note the wording of the CVE mention:

    For those that like to track these by CVE ids...

    Ubuntu (and Debian?) isn't affected, due to default AppArmor rules.

    The same mitigation for Dirty Frag blocks this as well, so if you were on top of Dirty Frag protections, you don't need to worry about fragnesia.

    sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"
    Show threadAwkward Turing5d ago

    @wdormann from GitHub: "This is a separate bug in the ESP/XFRM from dirtyfrag which has received its own patch. However, it is in the same surface and the mitigation is the same as for dirtyfrag."

    Curious phrasing. Does that mean the patch (not: the mitigation) will work for this as well or no?

    Show threadWill Dormann5d ago
    @AwkwardTuring
    Yes, the Dirty Frag mitigation works to protect against fragnesia CVE-2026-46300 as well.
    Show threadAwkward Turing
    @wdormann misunderstanding :) I meant if dirty frag >patch< works for fragnesia
    May 13 at 5:02pmWeb
    Show threadWill Dormann5d ago
    @AwkwardTuring
    Oh, sorry. I suppoi didn't read your message too carefully.
    No, it's a separate patch, and therefore it should expected that the Dirty Frag patch does not fix fragnesia. The reasoning is that patches are precise, the mitigation for Dirty Frag is painted with a broad stroke (module level).