CVE-2026-89762

Status: UPDATED  |  Advisory ID: CVE-2026-89762

Key Details

Affected Products, Subsystems & Sectors

What to Know

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. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References