CVE-2026-89762: apparmor: fix cred UAF caused by begin_current_label_crit_section()

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

apparmor: fix cred UAF caused by begincurrentlabelcritsection()

AppArmor's begincurrentlabelcritsection() 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 FLAGSTALE, and if so, attempts to use aareplacecurrentlabel() 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 = currentcred(); allocfilepseudo(...); uidt 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 aareplacecurrentlabel() runs with overridden credentials. aareplacecurrentlabel() bails out if currentcred() != currentrealcred() (mirroring the check in procpidattrwrite()), 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 overridecreds(<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 revertcreds(<creds A>) 9. now task->cred is <creds A> while task->realcred is <creds B>, but the taskstruct 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->realcred points to freed creds

At this point, any access to currentcred() 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 taskwork 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 sbpivotroot LSM hook after this change, and that direct cred replacements can still happen in VFS ->write() callbacks via procpidattrwrite().

There are two options for what to do with aaduptaskctx(): Either explicitly reset new->labelreplacementpending after the entire aataskctx 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.