CVE-2026-64111

What it actually does

This is a local Linux kernel race condition in the LSM self-attribute path. The kernel failed to hold cred_guard_mutex while processing lsm_set_self_attr(), creating a time-of-check/time-of-use window around SELinux and AppArmor checks that determine whether a process being ptraced is allowed to change its security label, domain, or profile attributes. A local low-privileged attacker who can execute code on the host may be able to race ptrace state and LSM attribute changes to bypass intended SELinux/AppArmor transition restrictions, potentially gaining unauthorized read/write access permitted to a different security context. The CVSS vector indicates local access, low attack complexity, low privileges, no user interaction, and high confidentiality and integrity impact, with no direct availability impact.

Why it matters to the business

If exploited, this flaw can weaken Linux mandatory access controls that organizations rely on to isolate services, contain compromised workloads, and enforce least privilege. A successful attacker could potentially escape or bypass SELinux/AppArmor confinement boundaries and access or modify data that should be protected by policy. Because exploitation requires local code execution and the vulnerability is not listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, internet-scale exploitation risk appears low; however, impact can be significant on multi-user systems, shared hosting, container platforms, hardened servers, and systems where SELinux or AppArmor is a core security control.

How an attack unfolds

An attacker first obtains the ability to run code as a low-privileged local user or inside a constrained workload on a vulnerable Linux kernel. They then create or manipulate a process relationship involving ptrace while simultaneously invoking the LSM self-attribute interface to request a SELinux/AppArmor context or profile transition. Because lsm_set_self_attr() did not take the same credential guard mutex used by the older /proc attribute-write path, the attacker attempts to win a race between the ptrace-state validation and the security attribute update. If the race succeeds, the LSM decision may be made against stale or inconsistent process state, allowing a transition that should have been denied. The attacker can then use the newly obtained or improperly changed security context to access files, IPC objects, sockets, or service resources that were previously blocked by SELinux/AppArmor policy.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for holding cred_guard_mutex during lsm_set_self_attr(). If using a distribution kernel, apply the vendor security update rather than relying only on upstream version numbers, because distributions commonly backport kernel fixes. No fixed product versions were provided in the input, so consult the relevant Linux distribution advisories for the corrected kernel package. After updating, reboot into the fixed kernel and verify the running kernel is the patched version. As interim mitigation, reduce local attack surface: restrict untrusted shell access, limit container escape opportunities, apply seccomp profiles that deny or tightly control newer LSM attribute syscalls where operationally feasible, restrict ptrace with kernel.yama.ptrace_scope where applicable, keep SELinux/AppArmor in enforcing mode, and monitor for unusual security-context transition activity. Do not disable SELinux or AppArmor as a mitigation; doing so removes the control affected by the bypass.

How to confirm the fix worked

Confirm exposure by identifying Linux systems running kernels that contain the vulnerable lsm_set_self_attr() implementation and have not received the vendor backport for this fix. Validate remediation by checking the running kernel package version against the distribution’s security advisory, confirming the system has rebooted into the patched kernel, and verifying the patch or equivalent backport is present in the kernel source/package changelog. On hosts where SELinux or AppArmor is used, perform regression testing for expected label/profile transitions and ptrace restrictions. If syscall-level telemetry is available, confirm whether lsm_set_self_attr() usage is either absent, expected, or constrained by policy. Vulnerability scanners should be configured to evaluate the running kernel, not only installed-but-inactive kernel packages.

Typical attack path

1. Gain local code execution on a vulnerable Linux host as a low-privileged user or within a confined process.
2. Confirm that SELinux or AppArmor is enabled and that the process is subject to meaningful confinement or transition rules.
3. Set up a ptrace relationship or rapidly change ptrace-observable state around the target process.
4. Repeatedly invoke lsm_set_self_attr() to request a security label, domain, or profile attribute change while racing the ptrace checks.
5. Win the race so the kernel permits a transition that SELinux/AppArmor policy should have rejected.
6. Use the resulting security context or profile state to read sensitive data, modify protected files, interact with restricted services, or move laterally within the host’s privilege boundaries.

How to detect it

Evidence of exploitation is likely to be subtle because the flaw abuses a kernel race rather than leaving a unique file or network artifact. Focus on behavioral evidence from auditd, SELinux AVC logs, AppArmor logs, EDR/eBPF telemetry, syscall tracing, process accounting, and kernel messages. Hunt for unusual or repeated lsm_set_self_attr() invocations, rapid security label/profile changes, unexpected SELinux domain transitions, AppArmor profile changes from processes that do not normally transition, and ptrace activity involving confined processes. Review audit events around the same timestamp for processes that changed context and then accessed files, sockets, IPC objects, or service credentials normally denied to their original context. Investigate local exploit-like behavior such as tight syscall loops, short-lived helper processes, ptrace attach/detach bursts, abnormal use of debugging interfaces, and confined workloads spawning processes with unexpected labels. Absence of AVC/AppArmor denials does not rule out exploitation, because a successful race may result in permitted access under the wrong context.

• lsm_set_self_attr
• ptrace
• PTRACE_ATTACH
• PTRACE_TRACEME
• /proc/self/attr/current
• /proc/self/attr/exec
• /proc/self/attr/apparmor/current
• avc: denied
• apparmor="DENIED"

What your security team should do

• Prioritize patching systems where SELinux or AppArmor is a key isolation boundary, including container hosts, bastion systems, multi-user Linux servers, shared CI runners, and high-value application servers.
• Apply vendor kernel security updates and reboot promptly; track reboot completion because kernel fixes are ineffective until the patched kernel is running.
• Review local-user and workload-execution exposure: remove unnecessary shell access, tighten sudo boundaries, and reduce opportunities for untrusted code execution.
• Enable or maintain SELinux/AppArmor enforcing mode and review policies for unnecessary transition permissions, but do not rely on policy tuning alone as a complete fix.
• Consider temporary syscall controls, seccomp filtering, or endpoint monitoring for lsm_set_self_attr() where supported and where compatibility impact is understood.
• Increase monitoring for anomalous ptrace activity, unexpected SELinux/AppArmor domain or profile transitions, and confined processes accessing resources outside their normal policy boundary.
• Because the issue is not currently KEV-listed, has low EPSS, and has no known exploit maturity in the provided data, handle as important local privilege/confinement-bypass risk rather than an active mass-exploitation emergency unless new threat intelligence emerges.