CVE-2026-89762

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:

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.