Steps to repeat the bug:

1) use the cross platform PoC written in C, the Python one that everyone is sharing contains obfuscated code (bad ju-ju) and is x86_64 specific

`git clone https://github.com/tgies/copy-fail-c`

`cd copy-fail-c`

2) compile either on your target device natively, or do what I did and cross-compile it as a static binary using an aarch64-linux-musl toolchain (this made it easy to test on different SBCs)

`PREFIX="/opt/toolchains/aarch64-linux-musl-cross" CC=aarch64-linux-musl-gcc LD=aarch64-linux-musl-ld CFLAGS="-static -fPIC -I/opt/toolchains/aarch64-linux-musl-cross/include -L/opt/toolchains/aarch64-linux-musl-cross/lib" LDFLAGS="-static -fPIE -L/opt/toolchains/aarch64-linux-musl-cross/lib" make -j$(nproc --all)`

3) pass the resulting binaries "payload" and "exploit" to your target device (if you cross compiled)

4) from an unprivileged user account not in the sudo group, run the exploit

 

I'm not here to point fingers but I would like to see AT LEAST an advisory of this potentially devastating bug with a public exploit available on the Armbian homepage, radio silence for over a week seems completely inappropriate to me

59 minutes ago, akabulous said:

radio silence for over a week seems completely inappropriate

 

We understand the concern, and we appreciate the effort put into testing and documenting the issue. At the same time, it is important to understand the realities of the embedded Linux ecosystem. Armbian supports a very large combination of SoCs, vendor kernels, boot chains, and downstream modifications across several hundred boards. Security response and validation in this environment is significantly more complex than in standardized desktop/server distributions.

Explained here:
https://github.com/armbian/build/issues/6937#issuecomment-4366571379

 

This is not a matter of ignoring the issue, but of limited engineering resources, kernel fragmentation, and the high cost of validating fixes safely across multiple platforms. Project can only finance security from your contributions https://github.com/sponsors/armbian volonteers or sponsors. Until none is taking this seriously, there is little what existing team members can do.

 

We already attempted mitigation work on one of the most widely used kernel branches:

https://github.com/armbian/linux-rockchip/pull/475 but even targeted fixes require substantial testing effort and may (i am sure it will) introduce regressions on affected hardware families.

 

Current resources barely sustain even our regular release and maintenance process:
https://docs.armbian.com/Process_Release-Model/

 

For users who need receiving upstream fixes faster and are willing to accept a higher risk of regressions on hardware feature breakage, there is always an option to switch to rolling/daily builds, where fix may already be available:
https://docs.armbian.com/User-Guide_Armbian-Config/System/#rolling

Tradeoff between stability, validation cost, hardware compatibility, and update speed is unfortunately a sad reality of embedded Linux maintenance. 

 

I understand that you're overworked and underpaid. This is free software, so I won't demand more labor from any of you. That said, I think it would build trust to at least have a little temporary pop-up (not the right word but I dont know what it's called) on the homepage that says something like "Current kernels may be vulnerable to this bug, we're working to resolve this, here are some relevant links" and then post the kernel dot org patch for this bug and point people to the Armbian build system. Surely the amount of effort it would take to do that is equal to or even less than it took to give me such a thorough response (which I appreciate btw). 

This, even though serious, it's "only" a privilege escalation, not remote code execution (RCE), so if someone were to use this on you, they would first need to have physical access OR access remotely (RCE) to be able to run the exploit and escalate to root. And if you have a malware with RCE, you are already f**ed.

 

In time, I'm pretty sure upstream patches will spread down to armbian builds too.

 

In the meantime if you think someone might be able to get access and escalate, you can disable algif_aead (or try to apply patches yourself) as mentioned in https://xint.io/blog/copy-fail-linux-distributions

 

Quote

Remediation

Patch the kernel. The fix reverts AF_ALG AEAD to out-of-place operation, eliminating page cache pages from the writable scatterlist.

Update your distribution's kernel package. Major distributions should ship the fix through normal kernel package updates.

 

For immediate mitigation, block AF_ALG socket creation via seccomp or blacklist the algif_aead module:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf rmmod algif_aead 2>/dev/null

 

Another solution is for you to pay a developer to do changes/testing needed

If you don't "demand more labor", then why are you requesting more labor? (don't answer, it's a rhetorical question)

Edited May 8May 8 by bedna

Really disappointing that both responses to the original post (although the first was at least polite) are basically "f*ck you, pay me" 🙄

 

I've already mitigated this on my own devices, my concern is for other users of this distribution.

 

And yeah, LPE isn't RCE, but it still deserves an advisory. Consider how easy it would be for an attacker to embed this exploit in a malicious file download + god knows what kind of payload and turn your computer into a zombie in a botnet, a cryptominer, hit you with ransomware, etc. 

 

When mentioning a real security issue gets a response this crappy, it doesn't bode well for the future of the project. Igor was at least professional. But go ahead, Bedna, tell me more about why the homepage being updated to include an advisory costs money that I should be sending instead of making bug reports 🙄 pathetic 

4 hours ago, akabulous said:

And yeah, LPE isn't RCE, but it still deserves an advisory. Consider how easy it would be for an attacker to embed this exploit in a malicious file download + god knows what kind of payload and turn your computer into a zombie in a botnet, a cryptominer, hit you with ransomware, etc. 

You know there is a fruit company in Cambridge UK that is proud to tell they have sold 75 million pieces and 75% is to non-noobs. They provide passwordless sudo by default and a self-modifying rpi-update script by default in their OS. So why so complicated with this copy-fail exploit, every script kiddy had and has an easy task of keeping the noobs on a leash for more than a decade.

Multiple options:

- wait for upcoming 26.05 release which will most likely have an updated kernel package including a fix for this

- as suggested use nightly

- use the build framework to build an most up-to-date kernel package set by yourself (its very easy) which then can be installed via dpkg -i

 

However since "dirty frag" just showed up, there is more to fix anyway...

 

Edit: looks like fix for dirty frag hit upstream  earlier today

7 hours ago, akabulous said:

When mentioning a real security issue gets a response this crappy, it doesn't bode well for the future of the project. Igor was at least professional. But go ahead, Bedna, tell me more about why the homepage being updated to include an advisory costs money that I should be sending instead of making bug reports 🙄 pathetic 

 

(I am not part of Armbian other than the community, and have donated money, so I feel no obligation to be "professional")

Ok, if you want to act like a clown, I'll treat you like a clown:

 

Don't click unknown links, don't download unknown scripts or applications and you are fine. You know, use common sense.

 

I'm sorry you feel "wronged" by this free and open source project because it doesn't focus the tiny amount of assets they have to manually remove something that pretty much is a nothing burger (and will be solved in the next update), unless you make yourself vulnerable by infecting yourself with with an RCE malware/virus or give physical access to people you can't trust.

If you think making a text on their website would "protect" people, when this exploit has been mentioned by more or less every single linux outlet in existence, I don't know what to say.

You are not doing this to "protect others", you do it for ego reasons.

 

(Sorry mods, I won't respond more with the risk of starting a war, but if being mentioned in the way op did, I WILL defend myself.)

 

Also, a link about Dirty Frag: https://thehackernews.com/2026/05/linux-kernel-dirty-frag-lpe-exploit.html

Mitigation:

Quote

Until the patches are available, it's advised to blocklist esp4, esp6, and rxrpc modules so they cannot be loaded -

sudo 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; true" 

It's worth mentioning here that Dirty Frag, despite sharing some overlaps with Copy Fail, can be exploited irrespective of whether the Linux kernel's algif_aead module is enabled or not.

 

Edited May 8May 8 by bedna

No risk of "starting a war," as I quite frankly don't give a damn about your opinion. The mitigations the devs have posted are easy to apply, so this is solved as far as I'm concerned. 

You must be really fun at parties, bedna 

On 5/14/2026 at 11:52 AM, akabulous said:

as I quite frankly don't give a damn about your opinion.

yet still giving enough to write a answer. flaming over LPEs (or any vulnerability) does not solve any issues.

I suggest to read the license again to get a clue who's responsible about fixing things in general: https://github.com/armbian/build/blob/5e60c0183d035bfd5179373e1eac284790e08904/LICENSE#L265-L268

 

Both parties also shall read the terms of use again, the very first bullet point in particular. I will not give this hint a second time.

 

fixes will land upstream, stable builds will adapt four times a year. For everyone wants things faster, options were provided.