CrackArmor: When Linux “Armor” Quietly Cracked

On March 10, 2026, researchers at Qualys published an advisory describing multiple vulnerabilities in AppArmor. If you run Linux servers there is a good chance AppArmor is somewhere in the stack, quietly enforcing confinement rules around processes and containers. 

The advisory is called CrackArmor, which is one of those rare vulnerability names that does not try very hard to be subtle. The armor cracked.

What makes this advisory interesting is not just that AppArmor had bugs. The Linux kernel is huge. Bugs happen.

What makes this one interesting is that the first bug is not some impossibly esoteric micro-architectural ghost hiding behind seven abstractions. It is a deeply awkward access-control failure.

The Real Problem: A Confused Deputy in Policy Management

The core issue Qualys describes is a classic confused-deputy problem. AppArmor exposes pseudo-files for loading, replacing, and removing policies:

/sys/kernel/security/apparmor/.load
/sys/kernel/security/apparmor/.replace
/sys/kernel/security/apparmor/.remove

Those pseudo-files are world-writable with mode 0666. An unprivileged user can open them successfully. The actual permission check happens later, when data is written. 

That sounds harmless for about five seconds.

Then you remember how Unix works.

If an unprivileged user can open the file descriptor first, and then trick a privileged program into doing the actual write through that descriptor, the kernel sees a privileged process performing the write and the policy action goes through. Qualys shows exactly that pattern, using a privileged helper such as su and, more specifically, su -P in pty mode to proxy controlled output into AppArmor’s policy-management files. 

This is not a philosophical problem about how paths map to inodes.

This is a much more ordinary and much more embarrassing problem: a privileged deputy can be tricked into exercising authority on behalf of an unprivileged caller. 

What an Attacker Can Do with AppArmor Policy Control

Once an attacker can load, replace, and remove arbitrary AppArmor profiles, the security consequences get ugly fast.

Qualys shows that an unprivileged local user can remove existing profiles that protect services, load restrictive profiles to cause denial of service, and even bypass Ubuntu’s unprivileged user-namespace restrictions by loading a new arbitrary userns profile. 

In other words, the attacker is not merely slipping around one rule.

They are editing the rulebook.

Enter the Guest Star: sudo, Except This Time It Is Actually in the Plot

Linux privilege escalation stories have a familiar supporting character: sudo.

In CrackArmor, sudo is not just hanging around in the background for flavor. It is central to one of the local privilege escalation chains.

Qualys’ idea was to load new AppArmor profiles that deny specific syscalls to specific privileged programs and intentionally create a fail-open situation. In the Ubuntu Server 24.04.3 plus Postfix example they describe, this lets an unprivileged local user pivot from arbitrary AppArmor profile control into full root privileges. 

That is a lot worse than “AppArmor policy can be bypassed in some corner case.”

That is “unprivileged user to root.”

And Then It Gets Worse: Kernel Memory Corruption Bugs in the CrackArmor Advisory

If the advisory had stopped at the confused-deputy issue, it would already have been bad enough.

It did not stop there.

Qualys also describes multiple kernel-side vulnerabilities reachable through AppArmor’s profile parsing and management paths: uncontrolled recursion leading to kernel stack exhaustion, an out-of-bounds read that discloses 64KB of kernel memory (including KASLR-relevant pointers), a use-after-free, and a double-free. The 64KB disclosure comes from AppArmor’s deterministic finite automaton (DFA) representation where states are stored as 16-bit integers, which constrains the reachable memory window during the out-of-bounds read. 

Qualys says they were able to exploit the use-after-free and double-free into full root privileges on tested systems. The exploitation techniques involved sophisticated kernel primitives including cross-cache attacks, page table manipulation, and FUSE-based race-window widening to reliably trigger the memory corruption paths. 

That is the part that makes this advisory especially nasty.

The first bug gives the attacker control over AppArmor policy operations.

The additional bugs turn that control into a larger exploitation surface inside the kernel itself. 

Why Security Enforcement Mechanisms Become Attack Surface

The deeper lesson from CrackArmor is not “paths are hard,” even though they are.

The real lesson is that once security enforcement lives inside a giant shared kernel, the enforcement machinery itself becomes attack surface.

In this case the irony is particularly sharp. AppArmor is present on the system specifically to reduce attack surface and harden the environment. Yet the very mechanism responsible for loading and managing those protections become a large and privileged attack surface of its own.

Sometimes that attack surface looks glamorous and academic.

Sometimes it looks like world-writable policy-management pseudo-files plus a permission check in the wrong place.

And sometimes it relies on nothing more exotic than basic UNIX behavior: file descriptors opened by one process can be written to by another, and if the privileged process performs the write, the kernel trusts it.

Either way, the result is the same. The thing that was supposed to enforce policy becomes part of the exploit chain. 

The Linux kernel remains one of the most impressive pieces of engineering ever produced.

It is also a place where security mechanisms are not magically outside the blast radius of kernel complexity. CrackArmor is one more reminder of that reality.

FAQ

What is the CrackArmor AppArmor vulnerability? 

CrackArmor is a March 2026 advisory from Qualys disclosing multiple vulnerabilities in Linux AppArmor, including a confused-deputy flaw in policy management and several kernel-side vulnerabilities that can be exploited to achieve full root privilege escalation.

How does the confused-deputy attack work in CrackArmor? 

AppArmor's policy-management pseudo-files are world-writable, allowing an unprivileged user to open a file descriptor before the permission check occurs. AppArmor performs the authorization check during write(), not during open(). 

If a privileged program such as su is then tricked into writing through that descriptor, the kernel trusts the privileged process and executes the policy action, bypassing access controls entirely.

What kernel bugs were disclosed alongside CrackArmor? 

Qualys disclosed four kernel-side vulnerabilities reachable through AppArmor's profile parsing paths: uncontrolled recursion leading to kernel stack exhaustion, an out-of-bounds read disclosing 64KB of kernel memory including KASLR-relevant pointers, a use-after-free vulnerability, and a double-free vulnerability. Qualys confirmed successful exploitation of the use-after-free and double-free into full root privileges.

Can an unprivileged local user achieve root via CrackArmor? 

Yes. Qualys demonstrated multiple independent privilege escalation paths from an unprivileged local user to root. One path relies entirely on userspace behavior, combining the confused-deputy flaw with a fail-open scenario involving sudo and Postfix on Ubuntu Server 24.04.3. Separate paths exploit the kernel memory corruption vulnerabilities reachable through AppArmor profile loading to achieve root privileges.

What does CrackArmor mean for Linux server security? 

CrackArmor illustrates that security enforcement mechanisms residing inside a shared kernel can themselves become attack surface. AppArmor, deployed specifically to reduce attack surface, exposed a privileged exploitation path through its policy-management interface. Any system running Linux with AppArmor enabled — which includes most Ubuntu-based server deployments — should apply vendor patches immediately.