Dirty Frag Vulnerability Made Public Early: Root Privilege On All Distributions

[f33dm3bits]

Dirty Frag Vulnerability Made Public Early: Root Privilege On All Distributions - Phoronix

www.phoronix.com

GitHub - 0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo: Copy Fail 2: Electric Boogaloo

Copy Fail 2: Electric Boogaloo. Contribute to 0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo development by creating an account on GitHub.

github.com

 

[craigevil]

Dirty Frag Vulnerability Made Public Early: Root Privilege On All Distributions - Phoronix

www.phoronix.com

 

[Alexzee]

Dirty Frag Vulnerability Made Public Early: Root Privilege On All Distributions - Phoronix

www.phoronix.com

Good article, thanks!

Found additional info. and details on this:-

Linux Kernel Dirty Frag LPE Exploit Enables Root Access Across Major Distributions

Dirty Frag exposes Linux systems to root escalation through chained kernel flaws, impacting Ubuntu, RHEL, Fedora, and others.

thehackernews.com

 

[VP9KS]

Thanks for sharing!

 

[KGIII]

The worst part isn't the bug. Well, I don't think it is. This is the worst part:

as the embargo was broken early

Responsible recording goes something like this:

The security researcher finds an exploit.
They let the project know about the exploit.
They give the project x-amount of time to fix it. (This is the key point here.)
The project verifies the exploit
The project fixes the exploit.
The project provides an update.
The security researcher shows the exploit to the world.
The world is now smarter and more secure. The researcher may also be paid a 'bounty'.

Somebody leaked it before it was fixed.

Note: Stuff is '0-day' if it was not reported by a researcher and is in the wild.

Responsible disclosure has been a good thing. It's a darned shame when it doesn't always happen properly.

And, no... As I've said time and time again, Linux is not as secure as many people express.

 

[ron.alan]

Somebody leaked it before it was fixed.

The article said it was an unrelated third-party . . . which doesn't make any sense to me. How did this "unrelated third-party" get his (or her) hands on all the info concerning it?

 

[KGIII]

The article said it was an unrelated third-party . . . which doesn't make any sense to me. How did this "unrelated third-party" get his (or her) hands on all the info concerning it?

Buggered if I know. Maybe they're a part of a hacking group (which is not uncommon), and one of them leaked the exploit. Tha'd be my first guess.

Also, I checked out their Git.

See:

dirtyfrag/assets/write-up.md at master · V4bel/dirtyfrag

Contribute to V4bel/dirtyfrag development by creating an account on GitHub.

github.com

Scroll down to find the quoted text:

• 2026-05-07: Submitted detailed information about the vulnerability and the exploit to the linux-distros mailing list. The embargo was set to 5 days [emphasis mine], with an agreement that if a third party publishes the exploit on the internet during the embargo period, the Dirty Frag exploit would be published publicly.

I made the important text bold.

That's just a five-day grace period. That's not a lot of time, though it does look like they also developed a patch for this.

Still, a patch needs to be tested. It has to function in many situations and can't break something else. It sure as heck can't break user space, as that'll send Linus off on a rant.

I'm not sure who agreed to an embargo (the five days that they sit on the exploit without disclosing it), but they only had five days to do so. I'm not sure that it can be done within five days, but maybe it could be.

What I absolutely DO KNOW is that it's usually a 90-day embargo.

I just checked Google. Yeah, the above is correct. I also learned that most software (in these situations) gets patched by the 9th day. So, even if they fixed it in record time, a five-day embargo isn't really much of an embargo at all.

So, I'm not sure what's going on behind the scenes.

I don't do the 'conspiracy theory' thing. I'll just point out that I don't know what went on behind the scenes, and I do not have enough information to speculate.

As an aside, it turns out that AI is pretty good at finding bugs/exploits. They're obviously verified by humans, but they're finding them at a rapid pace. (That's a good thing. In fact, it's a great thing.)

 

[Condobloke]

Stay tuned.

 

[osprey]

The dirtyfrag exploit is a local privilege escalation. For users of home computers that may usually have just one user or a small number of trusted users, the exploit is unlikely to be of threat.

The report here: https://www.openwall.com/lists/oss-security/2026/05/07/8, provides a workaround in the form of a shell script which one can copy from the linked site above.

@KGIII wrote:

Responsible recording goes something like this:

The way in which the exploit has been exposed with less than optimal embargoing and a third-party release is unfortunate. One can hope I guess that responsible behaviour can prevail. The linux community does have a lot of resources to recover from these things, witness the xz issue some time ago. There's a long history of mitigations against vulnerabilities, some of which can be seen in the bottom section of the lscpu command.

 

[CaffeineAddict]

Linus must be beating his devs with a metal rod right now.

 

[Fae3iSUx]

There's a long history of mitigations against vulnerabilities, some of which can be seen in the bottom section of the lscpu command.

In lscpu you only see hardware (CPU) vulnerabilities and mitigations.
There's thousands more being documented and fixed regularly, they just not so widely talked about in news and social media.
This one here is just local escalation. Worrisome for shared customer services like shells, VPSes etc. Not very harmful for personal at home computing. For me, no one else is using my computers so I have nothing to worry about.

 

[kc1di]

Good to know

 

[KGIII]

The way in which the exploit has been exposed with less than optimal embargoing and a third-party release is unfortunate. One can hope I guess that responsible behaviour can prevail.

I'm actually more concerned with the way this was handled than I am concerned about the exploit itself -- and I have all sorts of public-facing content online, some of it on servers I don't actually control. (I have a few VPS plans, a stupid amount of shared hosting, and now a dedicated bare-bones unmanaged server.)

In short, I have some skin in the game.

Also, I'm probably going to (eventually/hopefully) do a lot of consolidation with said dedicated server. Also, it's quite a lot of fun to manage a server. It's really just a hobby.

 

[dos2unix]

with said dedicated server. Also, it's quite a lot of fun to manage a server. It's really just a hobby.

I have a home lab also, but unfortunately.. I manage servers for people who manage me. It's nice when I get to be my own boss.
But sometimes I'm at the mercy of non-echnical people.. who just want it "fixed", whether the fix actually exists or not doesn't matter to them.. just "fix it".

Having said that.. my "rolling release distro". got 243 updates this morning... very unusual.

 

[dos2unix]

Sure enough 7.0.4 kernel fixes this


kernel-7.0.4-200.fc44.x86_64
ray@BlackTower1:~$ sudo su -
root@BlackTower1:~# rpm -q --changelog kernel-7.0.4-200.fc44.x86_64 | grep -i "esp\|xfrm\|frag\|CVE-2026"

• xfrm: esp: avoid in-place decrypt on shared skb frags (Kuan-Ting Chen)
• rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present (Hyunwoo Kim)
• uki-virt: add systemd-repart module (Emanuele Giuseppe Esposito)
• redhat: add all namespace-dependent selftests to kernel-selftests-internal (Joel Savitz)
• redhat: add more namespace selftests to kernel-modules-internal package (Joel Savitz) [RHEL-94503]
• redhat: add downstream SBAT for UKI addons (Emanuele Giuseppe Esposito)
• uki_addons: provide custom SBAT as input parameter (Emanuele Giuseppe Esposito)
• uki_addons: remove completely sbat/sbat.conf (Emanuele Giuseppe Esposito)
• redhat: add namespace selftests to kernel-modules-internal package (Joel Savitz) [RHEL-88635]
• redhat: create 'systemd-volatile-overlay' addon for UKI (Emanuele Giuseppe Esposito)
• redhat/configs: automotive: Disable IPsec Protocols and XFRM (Dorinda Bassey)
• spec: Respect rpmbuild --without debuginfo (Orgad Shaneh)
• redhat/uki_addons/virt: add common FIPS addon (Emanuele Giuseppe Esposito)
• redhat/kernel.spec: add uki_addons to create UKI kernel cmdline addons (Emanuele Giuseppe Esposito)
• redhat/dracut-virt.conf: add systemd-veritysetup module (Emanuele Giuseppe Esposito)
• Revert "net: bump CONFIG_MAX_SKB_FRAGS to 45" (Marcelo Ricardo Leitner)
• net: bump CONFIG_MAX_SKB_FRAGS to 45 (Marcelo Ricardo Leitner)
• kabi: add support for symbol namespaces into check-kabi (Prarit Bhargava)
• redhat/Makefile: Target whitespace cleanup (Prarit Bhargava)
• Update CONFIG_INET6_ESPINTCP (Justin Forbes)
• kernel packaging: Fix extra namespace collision (Don Zickus)
• redhat/genspec: awk unknown whitespace regex pattern (Bruno Meneguele)
• redhat: drop whitespace from with_gcov macro (Jan Stancek)

root@BlackTower1:~#

I assume it looks like this for debian systems?

apt changelog linux-image-$(uname -r) | grep -i "esp\|xfrm\|frag\|CVE"

or maybe..

dpkg-query --showformat='${Version}\n' --show linux-image-$(uname -r)

 

[dos2unix]

and it seems Rocky 10.1, had a large number of updates today.

Including...
kernel 6.12.0-124.55.1.el10_1

rpm -q --changelog kernel-6.12.0-124.55.1.el10_1.x86_64 | grep -i "esp\|xfrm\|frag\|CVE-2026"

(the same command should work for alma, rhel, oracle, etc...)

 

[KGIII]

I have a home lab also, but unfortunately..

I have a partially filled rack in the basement, though a bunch of the mess is my networking solution. (Most rooms have an Ethernet jack in them, for example.)

They're not public-facing (for the most part). One neat trick I can pull is to use my home connection as a VPN. I could be in Mexico, but my IP address will look like I'm home.

The ISP does have 'business class'. It's some ungodly throughput, like 2 GB/sec. Something crazy, at any rate. Though, for some strange reason, the 'new' (October of 2025) provider does not seem to care what I do online. I've torrented all sorts of stuff, for example. They haven't so much as sent me any hate mail -- which was very unlike the satellite provider we previously used.

Also, we generate more electricity than we use. We get credit, and I give those credits to the local school. (I don't think we're allowed to sell said credits.)

I could cover my butt with a business class plan and run my own servers online. I never lose power at my house, which is rather amazing considering how unreliable the grid is at my house. It's not unknown for the mains power to be out for a few days. Whie less common, we had an outage lasting 14 days just a couple of years ago. (We were fine at my house. I didn't even have to reduce our energy consumption.

As it'd probably only be a few servers, I wouldn't have to worry too much about the heat.

I hadn't really thought of it until your post. Thanks! I could probably just buy hardware to host my own servers. They even offer IPv4 addresses and entire IPv6 blocks. I think they're 'just' /24 blocks, but that's far more addresses than I'd ever need.

Now that sounds like fun!

 

[tinfoil-hat]

Is it already fixed in debian?

 

[dos2unix]

Is it already fixed in debian?

Linux Debian13 6.12.85+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.85-1 (2026-04-30) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat May 9 11:47:32 2026 from 192.168.12.108
root@Debian13:~# apt update && apt list --upgradable | grep linux-image
Get:1 http://security.debian.org/debian-security trixie-security InRelease [43.4 kB]
Hit:2 http://mirrors.vcea.wsu.edu/debian trixie InRelease
Get:3 http://mirrors.vcea.wsu.edu/debian trixie-updates InRelease [47.3 kB]
Get:4 http://security.debian.org/debian-security trixie-security/main Sources [148 kB]
Get:5 http://security.debian.org/debian-security trixie-security/main amd64 Packages [156 kB]
Get:6 http://security.debian.org/debian-security trixie-security/main Translation-en [96.3 kB]
Fetched 491 kB in 5s (89.3 kB/s)
7 packages can be upgraded. Run 'apt list --upgradable' to see them.

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

linux-image-amd64/stable-security 6.12.86-1 amd64 [upgradable from: 6.12.85-1]
root@Debian13:~#

Debian 6.12.86 has the patch.

zcat /usr/share/doc/linux-image-$(uname -r)/changelog.gz 2>/dev/null | grep -i "esp\|xfrm\|frag\|CVE-2026" | head -20
(CVE-2026-23468)
- nvme: respect NVME_QUIRK_DISABLE_WRITE_ZEROES when wzsl is set
- rxrpc: Fix memory leaks in rxkad_verify_response()
- rxrpc: Fix re-decryption of RESPONSE packets
(CVE-2026-31709)
f2fs_write_end_io() (CVE-2026-31715)
- media: rc: ttusbir: respect DMA coherency rules
- net: bonding: fix use-after-free in bond_xmit_broadcast() (CVE-2026-31419)
* rxrpc: Fix conn-level packet handling to unshare RESPONSE packets
* xfrm: esp: avoid in-place decrypt on shared skb frags
* rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present
- firmware: arm_ffa: Correct 32-bit response handling in
- [arm64] drm/msm/dpu: Set vsync source irrespective of mdp top support
- platform/chrome: cros_ec_lightbar: Fix response size initialization
- smb: client: correct value for smbd_max_fragmented_recv_size
- xfrm: fix ip_rt_bug race in icmp_route_lookup reverse path
- power: reset: nvmem-reboot-mode: respect cell size for nvmem_cell_write
(CVE-2026-23231)
- wifi: rtw89: mac: correct page number for CSI response
- wifi: rtw89: fix unable to receive probe responses under MLO connection
root@Debian13:~#

 

[The Duck]

Is there any way a user can check to see if the bug exists.

Is there a command a user can copy and paste into the terminal.