CIRCLE WITH A DOT

@jschauma Cool, another group of people who are going to be Very Interested in any kind of coordinated disclosure.

@patnat If I had to give a name to a vulnerability, then I'd call it CVE-1871-84711 (as the name.. not a CVE number) .. Just so that the Press that posts about it, has to use the confusing name: CVE-2026-12345 "CVE-1871-84711" and to create utter chaos

Mitigating Dirty Frag (RHSB-2026-003) on RHEL with Ansible: https://codeberg.org/Larvitz/gists/src/branch/main/2026/20260508-RHSB-2026-003_DirtyFrag_RHEL_Mitigation.md#cve #dirtyfrag #rhel #redhat #vulnerability #security

CVE-2026-43284 / "Dirty Frag" .. Antoher one of those nasty local-privilege-escallations.Quickfix for Centos/Fedora based systems: 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; trueCaution: That also effectively disables IPSEC and AFS client support. But it can easily be reverted by removing the file when a patched kernel arrives.#dirtyfrag #cve_2026_43284 #security #centos #fedora #redhat

Btw, there's _no_ way we're done here with #DirtyFrag and #CopyFail. Everybody is aiming their LLMs at this attack path through the page cache now, and there's bound to be other ways.Be ready to rinse and repeat a few more times before the dust settles, so I guess keep an even closer eye on linux kernel commits for a while.(And no, I don't know how this will be sustainable.)

#DirtyFrag status/advisories:AlmaLinux:https://almalinux.org/blog/2026-05-07-dirty-frag/Debian:https://security-tracker.debian.org/tracker/CVE-2026-43500https://security-tracker.debian.org/tracker/CVE-2026-43284Gentoo:https://bugs.gentoo.org/974307RedHat:https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2026-43284https://access.redhat.com/security/cve/cve-2026-43284nothing yet on CVE-2026-43500Rocky:https://kb.ciq.com/article/rocky-linux/rl-dirty-frag-mitigationSUSE / OpenSUSE:https://www.suse.com/security/cve/CVE-2026-43500.htmlhttps://www.suse.com/security/cve/CVE-2026-43284.htmlhttps://www.suse.com/c/addressing-copy-fail2-aka-dirtyfrag-in-suse-virtualization/Ubuntu:https://ubuntu.com/security/CVE-2026-43284https://ubuntu.com/security/CVE-2026-43500https://ubuntu.com/blog/dirty-frag-linux-vulnerability-fixes-availableAWS:https://aws.amazon.com/security/security-bulletins/rss/2026-027-aws/ https://explore.alas.aws.amazon.com/CVE-2026-43284.html

@avoca

New Linux 'Dirty Frag' zero-day vulnerability gives root on all major distributionshttps://www.bleepingcomputer.com/news/security/new-linux-dirty-frag-zero-day-with-poc-exploit-gives-root-privileges/- - -Une nouvelle vulnérabilité de jour zéro dans Linux « Dirty frag » donne accès root sur toutes les distributions majeureshttps://www.it-connect.fr/dirty-frag-cette-faille-zero-day-donne-les-droits-root-sur-linux/#Linux #DirtyFrag #InfoSec #Cybersécurité

#Linux 7.0.5, 6.18.28, 6.12.87, 6.6.138, 6.1.172, 5.15.206, and 5.10.255 kernels are now available for download at https://www.kernel.org to patch the new "Dirty Frag" security vulnerability.#OpenSource #LinuxKernel #DirtyFrag

@jwildeboer CVE-2026-23918 against Apache HTTPD was / is at the same time than CopyFail / DirtyFrag and could have been a good way to execute the POC.

variante peu sympa "Unprivileged Linux LPE via xfrm ESP-in-UDP MSG_SPLICE_PAGES no-COW fast path. Page-cache write into any readable file. Overwrites a nologin line in /etc/passwd with sick::0:0:...:/:/bin/bash and sus into it. Same class as Copy Fail (CVE-2026-31431), different subsystem."️ https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo#CyberVeille #Linux

"Ah shit, here we go again…"#dirtyfrag #linux #0day

Given this sentence in "Dirty Frag":"Because the responsible disclosure schedule and the embargo have been broken, no patch exists for any distribution."Can someone please explain to me this portion:> Because the responsible disclosure schedule and the embargo have been broken #DirtyFrag

@david_chisnall Ok, yeah this is a good "technically" point In my head because the kernel packages you install with the distro includes the modules on disk, I did conflate "in the kernel" and "in the kernel PACKAGE". But isn't that the same thing? How many of those autoloaded modules did you really need? I'm not setting up tunnels or have hardware encryption options, so why are those auto "opt-in" vs defaulted "opt-out". The remediation for many of these at the start was replace those modules with /bin/false and things for many people were just fine without them, so did they really need them? should they have been included on disk? Makes a difference of what you run on your workstation vs a herd of servers as well. I'll take a different path of thought there.

@Vive_Levant echo 0 > /proc/sys/kernel/modules_disabled-bash: echo: write error: Invalid argument

and we have another one. This one with CVE. #dirtyfrag #CVE-2026-43500

@ParadeGrotesque Noticed the same when I checked earlier, wasn't sure if the default 'huge' kernel was vulnerable, but, the (patched) generic kernel w/ my initrd was also fine (even ignoring the /usr/bin/su vs /bin/su difference)... so, much like with copyfail, I'm left wondering why these modules are loaded by default on so many systems in the first place, since nothing seems to be breaking without them.

@jschauma At least it was released with a known mitigation. No idea offhand what the esp4, esp6, and rxrpc modules are used for, though.

Another #Linux LPE: https://github.com/V4bel/dirtyfrag/#DirtyFrag

Another #Linux LPE: https://github.com/V4bel/dirtyfrag/#DirtyFrag