---
id: CVE-2026-89762
title: 'apparmor: fix cred UAF caused by begin_current_label_crit_section()'
summary: |-
  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…
severity: high
cvss: 7.8
cvssVector: 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'
cvssSource: cna
cwe:
  - CWE-825
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= c75afcd153f6147d3b094f45a1d87e5df7f4f053 <
    089f10b47843a86fa03a8c20799c9353660e5288
  - >-
    Linux >= c75afcd153f6147d3b094f45a1d87e5df7f4f053 <
    361488984d668235438faac28635f3632351407f
  - >-
    Linux >= c75afcd153f6147d3b094f45a1d87e5df7f4f053 <
    587a6a92b93ec314c583bbf747413af170d42540
  - >-
    Linux >= c75afcd153f6147d3b094f45a1d87e5df7f4f053 <
    580f777d6d9fd07fc034bd1aeba5c30fd48871a2
  - >-
    Linux >= c75afcd153f6147d3b094f45a1d87e5df7f4f053 <
    3f4ae5fab613dca01d6a2a8210dd832e009fcf47
  - Linux 2.6.36
published: '2026-09-11'
updated: '2026-10-21'
sourceUpdated: '2026-10-21T12:48:39.169Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-89762'
references:
  - url: 'https://git.kernel.org/stable/c/089f10b47843a86fa03a8c20799c9353660e5288'
  - url: 'https://git.kernel.org/stable/c/361488984d668235438faac28635f3632351407f'
  - url: 'https://git.kernel.org/stable/c/587a6a92b93ec314c583bbf747413af170d42540'
  - url: 'https://git.kernel.org/stable/c/580f777d6d9fd07fc034bd1aeba5c30fd48871a2'
  - url: 'https://git.kernel.org/stable/c/3f4ae5fab613dca01d6a2a8210dd832e009fcf47'
  - url: >-
      https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-89762.json
  - url: 'https://access.redhat.com/security/cve/CVE-2026-89762'
  - url: 'https://bugzilla.redhat.com/show_bug.cgi?id=2532435'
  - url: 'https://www.cve.org/CVERecord?id=CVE-2026-89762'
  - url: 'https://nvd.nist.gov/vuln/detail/CVE-2026-89762'
  - url: >-
      https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2026/CVE-2026-89762.mbox
tags:
  - cve.org
  - csaf
  - vex
  - red-hat
  - score-dispute
epss: 0.00123
epssPercentile: 0.02047
scores:
  cna: 7.8
  vendor: 5.5
ingestedAt: '2026-09-14T15:23:07.472Z'
---

## Overview

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.

## Affected

- `Linux >= c75afcd153f6147d3b094f45a1d87e5df7f4f053 < 089f10b47843a86fa03a8c20799c9353660e5288`
- `Linux >= c75afcd153f6147d3b094f45a1d87e5df7f4f053 < 361488984d668235438faac28635f3632351407f`
- `Linux >= c75afcd153f6147d3b094f45a1d87e5df7f4f053 < 587a6a92b93ec314c583bbf747413af170d42540`
- `Linux >= c75afcd153f6147d3b094f45a1d87e5df7f4f053 < 580f777d6d9fd07fc034bd1aeba5c30fd48871a2`
- `Linux >= c75afcd153f6147d3b094f45a1d87e5df7f4f053 < 3f4ae5fab613dca01d6a2a8210dd832e009fcf47`
- `Linux 2.6.36`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.

## Vendor advisories

- **Red Hat VEX** · Moderate · updated 2026-09-15 · [vex](https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-89762.json)