Is secureblue linux [ secureblue.dev ] also vulnerable by these three recent linux vulnerabilities - Copy Fail, Copy Fail 2 and Dirty Frag?
Not anymore
But IG itâs still vulnerable to Dirty Frag and Copy Fail 2 (IG they are one CVE with multiple name) since itâs embargo was broken ahead of the scheduled May 12 coordinated disclosure.
But like my real question is whatâs even the point of secureblue? I thought secureblue was the one to protect us from such stuff. But itâs also vulnerable to the CVEâs just like ever other distro.
So how is it more secure than those distros?
Whatâs the point using secureblue compared to something like Ubuntu (non-LTS releases included) or Fedora Workstation / Silverblue or Universal Blueâs Bluefin?
No piece of software is 100% vulnerability free, and if someone tells you that they are either lying to you or ignorant.
From SecureBlue website:
secureblue is a security-focused desktop and server Linux operating system.
⌠Fedora is one of the few Linux distributions that ships with SELinux and associated tooling built-in and enabled by default. This makes it advantageous as a starting point for building a secure desktop system. However, the security architecture of desktop Linux is broadly and significantly lacking. The goal of secureblue is to build a maximally secure Linux operating system by proactively increasing defenses against the exploitation of both known and unknown vulnerabilities, while avoiding sacrificing usability for most use cases where possible. For more details, see the features list.
secureblue is for those whose first priority is using Linux, and second priority is security. secureblue does not claim to be the most secure option available on the desktop.
Emphasis mine.
SecureBlue is a great project, but at the end of the day it still relies on the Linux Kernel, and with that comes the burden of Linux Kernel exploits such as CopyFail and DirtyFrag.
Considering that these exploits had gone unnoticed for ~7 years it would be hard for the the secureblue devs to mitigate such vulnerabilities in a reasonable manor.
Of course I am not an OS developer and you may be better off discussing these concerns directly with the developers of secure blue (respectfully of course).
SecureBlue does some great work securing the Linux desktop beyond just protection from Kernel exploits (see their site for a full list of features), so one should not write it off simply because it is vulnerable to Linux Kernel exploits like every other Linux distro.
5 Likes
secureblue is for those whose first priority is using Linux, and second priority is security. secureblue does not claim to be the most secure option available on the desktop. We are limited in that regard by the current state of desktop Linux standardization, tooling, and upstream security development. What we aim for instead is to be the most secure option for those who already intend to use Linux. As such, if security is your first priority, secureblue may not be the best option for you.
[1]secureblue.dev
If you want more security go with MacOS, ChromeOS, iOS, iPadOS, or best of all, GrapheneOS. GrapheneOS is probably the most secure implementation of the Linux Kernel.
GrapheneOS isnât vulnerable to the 3 recently disclosed Linux kernel vulnerabilities named Copy Fail, Copy Fail 2 and Dirty Frag. Current Android Open Source Project SELinux policies block exploiting all 3 bugs. Standard AOSP GKI kernel configuration also has 2/3 of the vulnerable features disabled.
https://xcancel.com/GrapheneOS/status/2052546809248059435#m
Footnotes âŠď¸
2 Likes
No distro is immune to kernel CVEs. The real point of secureblue is to make exploitation harder, not to magically prevent every future kernel bug.
5 Likes
As I said, not anymore. Mitigations are already merged to the live branch.
1 Like
I 100% agree with you, I even reacted 
. And I also do know about how secureblue is made for users who want linux, and linux does very much lack in security compared to something like macOS and even windows.
And yes itâs only fair for the project to ship a usable distro while balancing security. They can only harden so much.
But my aim was to also get a response from the secureblue developer about the same. I would really like to know his thoughts. Was this something that could have been prevented for secureblue by hardening it or not?
2 Likes
Yes I do use GrapheneOS as my primary mobile operating system. Itâs just not ready for being used as a desktop operating system for my use-case. And itâs not a GrapheneOS issue TBH, even PixelOS / PixelUI doesnât have full fledged desktop view as of now, itâs still WIP.
1 Like
As far as I know, it hasnât been patched yet.
âBecause the embargo has currently been broken, no patch or CVE exists. After consultation with the maintainers on linux-distros@vs.openwall.org and at their request, this Dirty Frag document is being published,â Kim said.
Update May 08, 09:58 EDT: Dirty Frag is now tracked as CVE-2026-43284.
1 Like
They fixed it really fast.
Read their features list. You can get to a similar security level or beyond by configuring your own distro, with enough effort and knowledge.
They can only do as much, since Linux desktop security is just an abysmal and their free time to work on secureblue is limited. I am sure they try to reduce kernel attack surface, but since they need to cover many use cases itâs not easy to find a black- or whitelist of modules, which works for every user and is still effective.
1 Like
How many times do I have to repeat myself? They donât need to patch the kernel to mitigate it.
Valid fair points.
Can you please provide a source? Similar to how I provided one to explain how itâs ( CVE-2026-43284 (Dirty Frag â ESP Component) ) still unpatched.
Edit: Itâs not about arguing or something, but simply about getting facts right.
Did you even look into their Github repo? Or their public dev channel on Discord? Either would have been enough to validate it, instead of repeating your own statements.
No, you provided a source which did not mention secureblue at all.
1 Like
You, might be able to get a response from the secureblue dev here if you ping them once, and again be respectful.
Though I donât know if the secureblue dev has be active on this forum recently. There are also other contact methods for the secureblue developer on the website namely Bluesky and Discord.
Also this might not be relevant to you, but I figured I might as well link it. In the below topic the secureblue dev was very active in answering questions. I wouldnât recommend asking this question there, but that topic thread may answer some other questions you had about secureblue.
1 Like
7 Likes
A) I donât have Discord to join their public dev channel.
B) Yes I did search their github issue and pr with the term CVE-2026-43284 and 43284, but their was no search result. You can check out for yourself.
https://github.com/secureblue/secureblue/pulls?q=is%3Apr+43284
Issues ¡ secureblue/secureblue ¡ GitHub
C) I also searched âcopy failâ in both pr and issues which shows,
[FEAT] Remove access to AF_ALG by default ¡ Issue #2180 ¡ secureblue/secureblue ¡ GitHub ,
which is related to copy fail and not copy fail 2 and dirty frag.
D) I also searched for âdirty fragâ which again shows no results.
Pull requests ¡ secureblue/secureblue ¡ GitHub
Issues ¡ secureblue/secureblue ¡ GitHub
E) I also checked their Mastodon which redirects to Bluesky and it also doesnât mention anything. I assumed for such a popular topic they would post something, like GrapheneOS but their was nothing.
F) Yes, the source doesnât mention secureblue but thatâs because secureblue is a very niche distro but since itâs based on Fedora and Fedora hasnât released any patch, it would make sense to assume secureblue also havenât been patched.
Ahh thanks my friend, should have searched for âdirtyfragâ instead of âdirty fragâ lol.