CVE-2026-89762

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

apparmor: fix cred UAF caused by begin_current_label_crit_section()

AppArmors 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:

1
2
3

const struct cred *cred = current_cred();
alloc_file_pseudo(...);
uid_t uid = cred->euid;

I dont 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 cant 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 (as both objective and subjective creds), with refcount=2
2. task grabs an extra reference on for overriding
3. task calls override_creds(), which returns a pointer to the old subjective creds ()
4. task enters AppArmor LSM hook
5. AppArmor checks that objective/subjective creds are equal
6. AppArmor replaces both cred pointers with and drops 2 refs on
7. task leaves AppArmor LSM hook
8. task calls revert_creds()
9. now task->cred is while task->real_cred is , but the task_struct logically holds two references to
10. another task drops the extra reference on 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 Software

References

• https://git.kernel.org/stable/c/361488984d668235438faac28635f3632351407f
• https://git.kernel.org/stable/c/3f4ae5fab613dca01d6a2a8210dd832e009fcf47
• https://git.kernel.org/stable/c/580f777d6d9fd07fc034bd1aeba5c30fd48871a2
• https://git.kernel.org/stable/c/587a6a92b93ec314c583bbf747413af170d42540