Join Our Newsletter
Receive our latest blog posts directly to your inbox!
Four serious Linux kernel vulnerabilities emerged between late April and May 2026, sending security teams across the industry scrambling for patches. This post examines why Becrypt OS 4.0.5 devices were never exposed to the standard exploit chains and how Becrypt OS 4.0.6 was released as a direct response to further reduce attack surface.
Executive Summary
Between late April and May 2026, four serious Linux kernel vulnerabilities — Copyfail ( CVE-2026-31431 ), DirtyFrag, Fragnesia, and CVE-2026-46333 — emerged in quick succession. All four carry serious privilege-escalation or credential-disclosure potential. Becrypt OS 4.0.5 devices were not exposed to the standard, published exploit chains in any of these cases. This was not luck: it was the direct consequence of the architectural and security principles built into the OS from day one. Becrypt OS 4.0.6 was subsequently released to address the deeper vulnerability in CVE-2026-31431 identified by the team, and patches for the remaining vulnerabilities have been deployed as part of standard update practice.
The NCSC warned in early 2026 that organisations should brace for a vulnerability patch wave — a surge of disclosures addressing years of accumulated technical debt in foundational software, Linux chief among them. That wave arrived in May. Within a single week, three distinct kernel vulnerabilities were disclosed with working exploit code published openly on GitHub. The combination created a pressurised environment for defenders everywhere.
For teams running Becrypt OS, however, the picture was rather different. The Becrypt OS security model is built around a small set of tightly enforced guiding principles: Secure by Default , No Unauthorised Execution of Binary Code , Code and Configuration Integrity , No Unauthorised Persistence , and Unprivileged User . As we will show below, each of these four vulnerabilities ran headlong into one or more of those principles before an attacker could get anywhere useful.
Secure by Default No Unauthorised Execution Code & Config Integrity No Unauthorised Persistence Unprivileged User Minimal Package Footprint Minimal Privileged Binaries
The following reconstruction is drawn from internal team communications during the disclosure period.
29 April 2026
1 May 2026 — Friday
6 May 2026 — Wednesday
11 May 2026 — Morning
11 May 2026 — 09:44
11 May 2026 — 11:09
12 May 2026 — 10:01
15 May 2026 — 12:10
15 May 2026 — 13:59 – 14:20
19 May 2026 — 15:46
22 May 2026 — 14:12
26 May 2026 — 16:58
27 May 2026 — 12:54
Copyfail ( CVE-2026-31431 )
algif_aead Page-Cache Write ( CVE-2026-31431 ) · Privilege Escalation · Linux Kernel
• su has no setuid bit ( CVE-2026-31431 )
• Minimal Privileged Binaries
• OverlayFS noexec RAM Write Layer
• No Unauthorised Persistence
• Kernel patch in Becrypt OS 4.0.6
CVE-2026-31431 : the published exploit’s escalation stage requires su to have the setuid bit — which Becrypt OS does not grant.
CVE-2026-31431 — The Original Copyfail
CVE-2026-31431 is a logic bug in the kernel’s algif_aead cryptographic module, part of the AF_ALG userspace crypto API. An unprivileged local user can trigger a controlled 4-byte write into the page cache of any readable file — including system binaries — and chain this into root privilege escalation. The vulnerability affects all Linux kernels since 2017 and carries a CVSS score of 7.8 (High).
The published proof-of-concept exploit was tested against Becrypt OS on 1 May 2026 and failed immediately . The escalation stage calls su to complete the privilege elevation, which requires su to hold the setuid bit. On Becrypt OS, it does not. The Becrypt OS Minimal
Privileged Binaries principle — enforcing nosuid across application-context mounts and keeping the list of privileged binaries to the absolute minimum — stopped the published exploit chain cold, without any kernel patch or additional configuration required.
On 6 May, the team went further: the exploit was adapted to run as a Python script, bypassing the su dependency. This version succeeded against Becrypt OS, establishing that the vulnerability is real and exploitable under a specific threat model. This triggered the internal emergency patching window.
Why launching Python is not straightforward on Becrypt OS
Python is present in the OS, but reaching it requires overcoming several compounding barriers. The application whitelist means only policy-registered applications can execute — an attacker must find a way to invoke the Python interpreter outside of the approved application set. There is no filesystem viewer or file manager on the device, so files cannot be browsed or opened through the UI. The user interface presents no option to open or run scripts directly ; an attacker would need to escape the controlled application environment before they could even reach a Python prompt. These are not kernel-level controls, but they substantially raise the bar for exploitation — this is an attack that requires specific knowledge of the OS internals and the ability to break out of the UI layer.
The kernel fix was included in the HWE kernel update 6.17.0-29.29~24.04.1 and shipped in Becrypt OS 4.0.6 (RC 22 May, GA 26 May; Becrypt OS+ RC 27 May) — well within the 30-day emergency patching window triggered on 6 May.
DirtyFrag
IP Fragmentation Heap Corruption · Privilege Escalation · Linux Kernel
• DM-Verity Read-Only System Partition
• OverlayFS RAM-Only Write Layer
• AppArmor MAC Policies
• Unprivileged User (nosuid)
Standard exploit requires write access to the system partition and persistent filesystem modification. Both are structurally impossible on Becrypt OS without additional prerequisites.
DirtyFrag exploits a heap corruption vulnerability in the Linux kernel’s IP fragment reassembly path. A crafted stream of forged, fragmented packets can trigger out-of-bounds writes in kernel memory, which a local attacker can then leverage for privilege escalation. The published proof-of-concept targets the standard Linux filesystem layout, expecting to write modified data to persistent storage as part of the exploit chain.
On Becrypt OS, the attack runs immediately into the read-only system partition , enforced at the block layer by DM-Verity . DM-Verity computes a SHA-256 hash for every disk block and stores these in a Merkle tree whose root hash is baked into the signed initramfs at build time. Any attempt to write to — or tamper with — a system block triggers an I/O error before the write completes.
Fig. 1 — Becrypt OS 4.0.6 Security Management Doc, p.4: OverlayFS + DM-Verity architecture
Above the read-only layer, the OverlayFS architecture presents applications with what appears to be a writable filesystem. In reality, all writes land in a compressed RAM disk (zram) that is mounted with noexec :
/dev/zram1 /.media/overlay-rw ext4 rw,noexec,noatime,discard,nobarrier 0 0
This single mount flag is critical: even if an attacker succeeds in writing a malicious file to the overlay layer, the kernel will refuse to execute it. Any data written during a session is discarded entirely on shutdown — the exploit cannot achieve persistence.
Fig. 2 — Becrypt OS 4.0.6 Security Management Doc, p.6: All writes go to RAM, never to permanent storage
Additionally, the AppArmor mandatory access control framework (mandated under the No Unauthorised Execution of Binary Code principle) confines processes to explicitly permitted operations. The tv user — the unprivileged runtime user under which all applications execute — has no path to gain root privileges outside of a tightly defined set of permitted actions. The nosuid mount flag is enforced across all filesystem mounts in application contexts.
Deployed Mitigation (12 May 2026)
The esp6 and rxrpc kernel modules were blacklisted, removing attack surface that Becrypt OS does not require. While ESP support is needed for IPsec VPNs on IPv4 (esp4), the IPv6 variant and RxRPC are not used and can be safely disabled.
printf ‘install esp6 /bin/false install rxrpc /bin/false ‘ > /etc/modprobe.d/bc-dirtyfrag.conf
Live Exploit Validation — 19 May 2026
The team compiled and ran the published exp.c exploit against a live device as the unprivileged tv user to understand exactly how far the attack progresses. Three distinct test runs produced a clear picture.
Without mitigations — RxRPC path: The exploit loaded the rxrpc module, opened /etc/passwd , mapped it into memory, and ran all three kernel trigger stages, successfully modifying the root entry in the page cache. Then it hit the Becrypt OS wall:
$ exp –verbose –corrupt-only [su] uid_map: Operation not permitted [su] corruption stage failed (status=0x100) … [!!!] HIT — root entry now has empty passwd field, uid=0, gid=0 # Page cache modified — but escalation blocked. su has no setuid bit.
The page cache write succeeded in kernel memory, but privilege escalation was blocked immediately. Becrypt OS enforces nosuid on all mounts and the tv user has no path to root — the Unprivileged User principle doing exactly what it was designed to do.
With the RxRPC module blacklisted: The exploit failed earlier, during its initial setup phase, before reaching the kernel trigger stages. The module blacklist is effective defence-in-depth — it stops the attack sooner.
With –force-esp and the blacklist removed: Even forcing the ESP4 network path and removing the modprobe blacklist entirely, the exploit still failed at the same place:
$ exp –force-esp –verbose –corrupt-only [su] uid_map: Operation not permitted [su] corruption stage failed (status=0x100) dirtyfrag: failed (rc=1)
This confirmed that the module blacklist causes the exploit to fail sooner , but the fundamental blocker is the nosuid enforcement and the unprivileged user architecture . Critically, this also means the esp4 module — required for IPsec VPNs — can safely remain loaded without exposing a usable DirtyFrag escalation path on Becrypt OS.
Fragnesia
Kernel Module Exploit via Unknown Binary · Privilege Escalation · Linux Kernel
• Application Whitelisting (fs-verity)
• No Unauthorised Binary Execution
• AppArmor Profiles
• memfd_create Monitoring & Kill
Fragnesia requires delivering and executing an unknown exploit binary. Becrypt OS does not permit any binary to run unless it is signed and registered in policy — full stop.
Fragnesia is perhaps the most instructive of the three vulnerabilities from a Becrypt OS architecture perspective, because the mitigation requires zero kernel configuration changes. The published exploit requires an attacker to deliver and run a purpose-built binary on the target system. On Becrypt OS, that step is simply not possible.
The No Unauthorised Execution of Binary Code principle is one of the cornerstones of Paradox/Becrypt OS design. It is implemented through several interlocking mechanisms:
Fig. 3 — Becrypt OS 4.0.6 Security Management Doc, p.3: fs-verity detects and removes corrupted or unauthorised apps automatically
fs-verity Application Integrity
Every application on Becrypt OS is checked at runtime using the Linux fs-verity feature. If any application file is found to be missing, the wrong size, or cryptographically inconsistent with its registered policy, Becrypt OS deletes it and re-downloads the authorised version from the BEM management server. An unknown binary — one that has never been registered in policy — has no path to execution whatsoever. It will simply never be launched.
AppArmor Confinement
Every permitted application runs inside an AppArmor profile that restricts what system resources it can access. Even if a process somehow obtained a reference to an unwhitelisted binary, the AppArmor profile would prevent execution. Application namespaces provide an additional layer of isolation between applications and between applications and the system.
memfd_create Monitoring and Kill
One well-known technique for circumventing filesystem-level execution controls is to use the memfd_create syscall to create an anonymous in-memory file and execute code directly from RAM. Becrypt OS detects any attempt to use memfd_create from a scripting language such as Python or Bash, immediately terminates the responsible process, reports the event to the BEM management console, and shuts the device down within two seconds — eliminating the threat and erasing any transient exploit state.
Fig. 4 — Becrypt OS 4.0.6 Security Management Doc, p.8: Kernel audit logging detects and kills suspicious processes including memfd_create abuse
The combined effect is that Fragnesia’s exploit binary cannot be introduced, cannot be executed from the filesystem, and cannot be executed from memory. There is no execution surface. The vulnerability exists in the kernel, but the attack chain terminates before it can begin.
CVE-2026-46333 — ssh-keysign-pwn
ptrace __ptrace_may_access() Logic Flaw · Credential Disclosure / Privilege Escalation · Disclosed 15 May 2026
• No Root User (tv user only)
• ptrace_scope = 3 (production)
• TPM-backed Keyring (encrypted key storage)
• Unprivileged User Principle
The standard exploit requires root-accessible binaries to trigger the race condition. Becrypt OS has no root user in the conventional sense. The device private key is TPM-encrypted and inaccessible to the tv user. A ptrace_scope hardening was deployed as additional defence-in-depth.
Discovered by Qualys Threat Research Unit and disclosed on 15 May 2026, CVE-2026-46333 exploits a logic flaw in the kernel’s __ptrace_may_access() function. It opens a narrow race window where a privileged process dropping its credentials remains reachable via ptrace-family operations, allowing an unprivileged user to read root-owned files (SSH keys, /etc/shadow ) or execute arbitrary commands as root. The bug has been present in mainline kernels since November 2016.
The team’s analysis was immediate and methodical. The published chage_pwn exploit vector was dismissed outright: there is no root user on a Becrypt OS device in the conventional Linux sense. The more targeted concern was whether a modified version of sshkeysign_pwn.c could be used to extract the Becrypt OS device private key stored on the config partition.
The exploit works by replacing the static PATHS[] array — normally pointing at ssh-keysign binaries — with paths to any binary that runs with sudo and touches the target file. The team concluded that for this attack to succeed against the device key, an attacker would need to identify a sudo-enabled binary that accesses the config partition in the course of its normal operation. Becrypt OS’s strict Unprivileged User principle and minimal package footprint make this attack surface extremely small.
ptrace_scope Hardening
The team evaluated the kernel.yama.ptrace_scope sysctl as a direct mitigation. Setting it to 3 (no process may use ptrace) eliminates the race condition entirely. Since ptrace is a debugging facility not used by any Becrypt OS production component, there is minimal operational impact. Testing confirmed:
Findings from testing
ptrace_scope=3 is clean on release builds. ptrace_scope=2 (admin-only) would break the System Information applet. ptrace_scope=3 also breaks address sanitizer on debug builds — this is expected and acceptable for a release-only control.
# CVE-2026-46333 — disable ptrace entirely on production builds kernel.yama.ptrace_scope = 3
This setting was deployed to production Becrypt OS devices. Debug builds retain the default ptrace behaviour to preserve developer tooling.
+44 (0) 845 8382050
+44 (0) 345 8382070
Receive our latest blog posts directly to your inbox!