apparmor: fix cred UAF caused by begin_current_label_crit_section()

Description

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.

Timeline

Scores

EPSS (exploitation in 30 days)

0.12% · top 98% of all CVEs (11 Nov 2026)

The list uses the assigner's score when there is one, then CISA's, then NVD's: High 7.8.

Affected products

• Linux · Linux

  • affected c75afcd153f6147d3b094f45a1d87e5df7f4f053 – < 42d0791f8aa90382c22dbe0443712c78d1e9d212
  • affected c75afcd153f6147d3b094f45a1d87e5df7f4f053 – < 089f10b47843a86fa03a8c20799c9353660e5288
  • affected c75afcd153f6147d3b094f45a1d87e5df7f4f053 – < 361488984d668235438faac28635f3632351407f
  • affected c75afcd153f6147d3b094f45a1d87e5df7f4f053 – < 587a6a92b93ec314c583bbf747413af170d42540
  • affected c75afcd153f6147d3b094f45a1d87e5df7f4f053 – < 580f777d6d9fd07fc034bd1aeba5c30fd48871a2
  • affected c75afcd153f6147d3b094f45a1d87e5df7f4f053 – < 3f4ae5fab613dca01d6a2a8210dd832e009fcf47

• Linux · Linux

  • affected 2.6.36
  • unaffected < 2.6.36
  • unaffected 6.1.191 – ≤ 6.1.*
  • unaffected 6.6.160 – ≤ 6.6.*
  • unaffected 6.12.109 – ≤ 6.12.*
  • unaffected 6.18.50 – ≤ 6.18.*
  • unaffected 7.2.4 – ≤ 7.2.*
  • unaffected 7.3 – ≤ *

Sources

The same CVE in the primary databases and aggregators, to check against.

• CVE.org record (opens in a new tab)
• CVE List JSON (GitHub) (opens in a new tab)
• NVD (opens in a new tab)
• FIRST EPSS (opens in a new tab)
• EUVD EUVD-2026-76674 (opens in a new tab)
• OSV.dev (opens in a new tab)
• GitHub Advisories (opens in a new tab)
• CIRCL Vulnerability-Lookup (opens in a new tab)

Badge for a README or a ticket

[![CVE-2026-89762](https://cveledger.app/badge/CVE-2026-89762.svg)](https://cveledger.app/cve/CVE-2026-89762)

Record last updated 30 Oct 2026, 12:32 UTC.