Description
In the Linux kernel, the following vulnerability has been resolved:

apparmor: fix cred UAF caused by begin_current_label_crit_section()

AppArmor's begin_current_label_crit_section() is a scary function called
from lots of LSM hooks (in particular VFS/socket-related ones) that checks
if the label referenced by the current creds is marked FLAG_STALE, and if
so, attempts to use aa_replace_current_label() to replace the creds with an
updated version that uses a new label.

The first problem with this is that it would directly lead to UAF of
`struct cred` if anything in the kernel takes a pointer to the current
creds and accesses these past a security hook invocation that replaces
creds, like so:
```
const struct cred *cred = current_cred();
alloc_file_pseudo(...);
uid_t uid = cred->euid;
```
I don't know if anything in the kernel actually does this, but I think it
is very surprising that this pattern could lead to UAF.

The second problem is that things go wrong when aa_replace_current_label()
runs with overridden credentials. aa_replace_current_label() bails out if
`current_cred() != current_real_cred()` (mirroring the check in
proc_pid_attr_write()), but this check can't actually reliably detect
overridden credentials because the overridden creds can be the same as the
objective creds.

So in approximately the following scenario, things go wrong:

1. task begins with <creds A> (as both objective and subjective creds),
with refcount=2
2. task grabs an extra reference on <creds A> for overriding
3. task calls override_creds(<creds A>), which returns a pointer to the old
subjective creds (<creds A>)
4. task enters AppArmor LSM hook
5. AppArmor checks that objective/subjective creds are equal
6. AppArmor replaces both cred pointers with <creds B> and drops 2 refs on
<creds A>
7. task leaves AppArmor LSM hook
8. task calls revert_creds(<creds A>)
9. now task->cred is <creds A> while task->real_cred is <creds B>, but the
task_struct logically holds two references to <creds B>
10. another task drops the extra reference on <creds A> that was used for
overriding, refcount drops to 0
11. now task->real_cred points to freed creds

At this point, any access to current_cred() will be UAF.

I have a test case where I run aa-disable on a profile while a process
using that profile is blocked on splice() from a FUSE passthrough file into
a full pipe; after the profile update, the pipe becomes empty, splice()
resumes, the credentials go out of sync, and a subsequent getuid() syscall
results in a KASAN UAF splat.

To fix this, instead of directly replacing creds, do it via task_work that
will run at the end of the current syscall. (The point in time at which the
cred replacement happens should have no correctness impact; it is just a
performance optimization to avoid unnecessarily touching the refcount of
the new label.)

Note that AppArmor still performs direct cred replacements in the
sb_pivotroot LSM hook after this change, and that direct cred replacements
can still happen in VFS ->write() callbacks via proc_pid_attr_write().

There are two options for what to do with aa_dup_task_ctx(): Either
explicitly reset new->label_replacement_pending after the entire
aa_task_ctx has been copied, or switch to manually copying members over.
I am switching to manually copying members over because that should make
bugs more obvious.
Published: 2026-09-11
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: Local privilege escalation via kernel use‑after‑free
Action: Patch kernel
AI Analysis

Impact

A use‑after‑free vulnerability exists in the AppArmor LSM hook of the Linux kernel. When the credential label of a running task is replaced during a security check, the kernel may drop references to the old credential structure while the task still holds a pointer to it. Accessing the freed structure can trigger a kernel crash or allow the execution of arbitrary code. This potential for privilege escalation is inferred because the UAF could enable kernel‑level code execution. For a local attacker this could lead to privilege escalation to kernel level.

Affected Systems

The flaw is present in the generic Linux kernel when AppArmor is compiled in, before the patched implementation of begin_current_label_crit_section() and related label‑replacement logic. All versions lacking the provided patch are vulnerable; no specific version range is listed.

Risk and Exploitability

The CVSS score of 7.8 indicates high severity. The EPSS score is less than 1%, reflecting a very low likelihood of exploitation. The vulnerability is not listed in the CISA KEV catalog, so no publicly known exploit exists at the time of this analysis. Attackers would need local access and the ability to trigger AppArmor label replacements; this requirement is inferred from the fact that the vulnerability involves credential manipulation within the kernel context. The likely attack vector is local, through a process that triggers credential replacement. If an exploit were crafted, it could result in privilege escalation.

Generated by OpenCVE AI on September 15, 2026 at 19:06 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update the Linux kernel to a version that includes the AppArmor credential‑replacement logic.
  • Temporarily disable AppArmor for processes that may trigger credential replacements, for example by using aa-disable on the relevant profile while such tasks run.
  • Monitor kernel logs for KASAN or BUG messages and investigate any unexpected crashes promptly.

Generated by OpenCVE AI on September 15, 2026 at 19:06 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DSA Debian DSA DSA-6528-1 linux security update
History

Sun, 13 Sep 2026 06:45:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 5.2, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:H'}

 cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}

Sat, 12 Sep 2026 15:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Sat, 12 Sep 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-825
References
Metrics threat_severity

None

 cvssV3_1

{'score': 5.2, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:H'}

threat_severity

Moderate

Sat, 12 Sep 2026 08:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Fri, 11 Sep 2026 23:45:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: apparmor: fix cred UAF caused by begin_current_label_crit_section() AppArmor's begin_current_label_crit_section() is a scary function called from lots of LSM hooks (in particular VFS/socket-related ones) that checks if the label referenced by the current creds is marked FLAG_STALE, and if so, attempts to use aa_replace_current_label() to replace the creds with an updated version that uses a new label. The first problem with this is that it would directly lead to UAF of `struct cred` if anything in the kernel takes a pointer to the current creds and accesses these past a security hook invocation that replaces creds, like so: ``` const struct cred *cred = current_cred(); alloc_file_pseudo(...); uid_t uid = cred->euid; ``` I don't know if anything in the kernel actually does this, but I think it is very surprising that this pattern could lead to UAF. The second problem is that things go wrong when aa_replace_current_label() runs with overridden credentials. aa_replace_current_label() bails out if `current_cred() != current_real_cred()` (mirroring the check in proc_pid_attr_write()), but this check can't actually reliably detect overridden credentials because the overridden creds can be the same as the objective creds. So in approximately the following scenario, things go wrong: 1. task begins with <creds A> (as both objective and subjective creds), with refcount=2 2. task grabs an extra reference on <creds A> for overriding 3. task calls override_creds(<creds A>), which returns a pointer to the old subjective creds (<creds A>) 4. task enters AppArmor LSM hook 5. AppArmor checks that objective/subjective creds are equal 6. AppArmor replaces both cred pointers with <creds B> and drops 2 refs on <creds A> 7. task leaves AppArmor LSM hook 8. task calls revert_creds(<creds A>) 9. now task->cred is <creds A> while task->real_cred is <creds B>, but the task_struct logically holds two references to <creds B> 10. another task drops the extra reference on <creds A> that was used for overriding, refcount drops to 0 11. now task->real_cred points to freed creds At this point, any access to current_cred() will be UAF. I have a test case where I run aa-disable on a profile while a process using that profile is blocked on splice() from a FUSE passthrough file into a full pipe; after the profile update, the pipe becomes empty, splice() resumes, the credentials go out of sync, and a subsequent getuid() syscall results in a KASAN UAF splat. To fix this, instead of directly replacing creds, do it via task_work that will run at the end of the current syscall. (The point in time at which the cred replacement happens should have no correctness impact; it is just a performance optimization to avoid unnecessarily touching the refcount of the new label.) Note that AppArmor still performs direct cred replacements in the sb_pivotroot LSM hook after this change, and that direct cred replacements can still happen in VFS ->write() callbacks via proc_pid_attr_write(). There are two options for what to do with aa_dup_task_ctx(): Either explicitly reset new->label_replacement_pending after the entire aa_task_ctx has been copied, or switch to manually copying members over. I am switching to manually copying members over because that should make bugs more obvious.
Title apparmor: fix cred UAF caused by begin_current_label_crit_section()
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-13T06:34:06.338Z

Reserved: 2026-09-11T19:38:34.764Z

Link: CVE-2026-89762

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-11T20:20:07.377

Modified: 2026-09-13T07:17:40.570

Link: CVE-2026-89762

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-09-11T19:47:03Z

Links: CVE-2026-89762 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-09-15T19:15:16Z

Weaknesses
  • CWE-825

    Expired Pointer Dereference