{"id":"CVE-2026-89762","summary":"apparmor: fix cred UAF caused by begin_current_label_crit_section()","details":"In the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix cred UAF caused by begin_current_label_crit_section()\n\nAppArmor's begin_current_label_crit_section() is a scary function called\nfrom lots of LSM hooks (in particular VFS/socket-related ones) that checks\nif the label referenced by the current creds is marked FLAG_STALE, and if\nso, attempts to use aa_replace_current_label() to replace the creds with an\nupdated version that uses a new label.\n\nThe first problem with this is that it would directly lead to UAF of\n`struct cred` if anything in the kernel takes a pointer to the current\ncreds and accesses these past a security hook invocation that replaces\ncreds, like so:\n```\nconst struct cred *cred = current_cred();\nalloc_file_pseudo(...);\nuid_t uid = cred-\u003eeuid;\n```\nI don't know if anything in the kernel actually does this, but I think it\nis very surprising that this pattern could lead to UAF.\n\nThe second problem is that things go wrong when aa_replace_current_label()\nruns with overridden credentials. aa_replace_current_label() bails out if\n`current_cred() != current_real_cred()` (mirroring the check in\nproc_pid_attr_write()), but this check can't actually reliably detect\noverridden credentials because the overridden creds can be the same as the\nobjective creds.\n\nSo in approximately the following scenario, things go wrong:\n\n1. task begins with \u003ccreds A\u003e (as both objective and subjective creds),\n   with refcount=2\n2. task grabs an extra reference on \u003ccreds A\u003e for overriding\n3. task calls override_creds(\u003ccreds A\u003e), which returns a pointer to the old\n   subjective creds (\u003ccreds A\u003e)\n4. task enters AppArmor LSM hook\n5. AppArmor checks that objective/subjective creds are equal\n6. AppArmor replaces both cred pointers with \u003ccreds B\u003e and drops 2 refs on\n   \u003ccreds A\u003e\n7. task leaves AppArmor LSM hook\n8. task calls revert_creds(\u003ccreds A\u003e)\n9. now task-\u003ecred is \u003ccreds A\u003e while task-\u003ereal_cred is \u003ccreds B\u003e, but the\n   task_struct logically holds two references to \u003ccreds B\u003e\n10. another task drops the extra reference on \u003ccreds A\u003e that was used for\n    overriding, refcount drops to 0\n11. now task-\u003ereal_cred points to freed creds\n\nAt this point, any access to current_cred() will be UAF.\n\nI have a test case where I run aa-disable on a profile while a process\nusing that profile is blocked on splice() from a FUSE passthrough file into\na full pipe; after the profile update, the pipe becomes empty, splice()\nresumes, the credentials go out of sync, and a subsequent getuid() syscall\nresults in a KASAN UAF splat.\n\nTo fix this, instead of directly replacing creds, do it via task_work that\nwill run at the end of the current syscall. (The point in time at which the\ncred replacement happens should have no correctness impact; it is just a\nperformance optimization to avoid unnecessarily touching the refcount of\nthe new label.)\n\nNote that AppArmor still performs direct cred replacements in the\nsb_pivotroot LSM hook after this change, and that direct cred replacements\ncan still happen in VFS -\u003ewrite() callbacks via proc_pid_attr_write().\n\nThere are two options for what to do with aa_dup_task_ctx(): Either\nexplicitly reset new-\u003elabel_replacement_pending after the entire\naa_task_ctx has been copied, or switch to manually copying members over.\nI am switching to manually copying members over because that should make\nbugs more obvious.","modified":"2026-09-13T03:47:20.648376823Z","published":"2026-09-11T19:47:03.601Z","database_specific":{"osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/89xxx/CVE-2026-89762.json","cna_assigner":"Linux"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/361488984d668235438faac28635f3632351407f"},{"type":"WEB","url":"https://git.kernel.org/stable/c/3f4ae5fab613dca01d6a2a8210dd832e009fcf47"},{"type":"WEB","url":"https://git.kernel.org/stable/c/580f777d6d9fd07fc034bd1aeba5c30fd48871a2"},{"type":"WEB","url":"https://git.kernel.org/stable/c/587a6a92b93ec314c583bbf747413af170d42540"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/89xxx/CVE-2026-89762.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89762"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"c75afcd153f6147d3b094f45a1d87e5df7f4f053"},{"fixed":"361488984d668235438faac28635f3632351407f"},{"fixed":"587a6a92b93ec314c583bbf747413af170d42540"},{"fixed":"580f777d6d9fd07fc034bd1aeba5c30fd48871a2"},{"fixed":"3f4ae5fab613dca01d6a2a8210dd832e009fcf47"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-89762.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.6.36"},{"fixed":"6.12.109"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.13.0"},{"fixed":"6.18.50"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.19.0"},{"fixed":"7.2.4"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-89762.json"}}],"schema_version":"1.9.0"}