{"api_version":"1","generated_at":"2026-09-11T23:53:30+00:00","cve":"CVE-2026-89762","urls":{"html":"https://cve.report/CVE-2026-89762","api":"https://cve.report/api/cve/CVE-2026-89762.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-89762","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-89762"},"summary":{"title":"apparmor: fix cred UAF caused by begin_current_label_crit_section()","description":"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->euid;\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 <creds A> (as both objective and subjective creds),\n   with refcount=2\n2. task grabs an extra reference on <creds A> for overriding\n3. task calls override_creds(<creds A>), which returns a pointer to the old\n   subjective creds (<creds A>)\n4. task enters AppArmor LSM hook\n5. AppArmor checks that objective/subjective creds are equal\n6. AppArmor replaces both cred pointers with <creds B> and drops 2 refs on\n   <creds A>\n7. task leaves AppArmor LSM hook\n8. task calls revert_creds(<creds A>)\n9. now task->cred is <creds A> while task->real_cred is <creds B>, but the\n   task_struct logically holds two references to <creds B>\n10. another task drops the extra reference on <creds A> that was used for\n    overriding, refcount drops to 0\n11. now task->real_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 ->write() callbacks via proc_pid_attr_write().\n\nThere are two options for what to do with aa_dup_task_ctx(): Either\nexplicitly reset new->label_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.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-09-11 20:20:07","updated_at":"2026-09-11 20:20:07"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/587a6a92b93ec314c583bbf747413af170d42540","name":"https://git.kernel.org/stable/c/587a6a92b93ec314c583bbf747413af170d42540","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/3f4ae5fab613dca01d6a2a8210dd832e009fcf47","name":"https://git.kernel.org/stable/c/3f4ae5fab613dca01d6a2a8210dd832e009fcf47","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/580f777d6d9fd07fc034bd1aeba5c30fd48871a2","name":"https://git.kernel.org/stable/c/580f777d6d9fd07fc034bd1aeba5c30fd48871a2","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/361488984d668235438faac28635f3632351407f","name":"https://git.kernel.org/stable/c/361488984d668235438faac28635f3632351407f","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-89762","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-89762","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected c75afcd153f6147d3b094f45a1d87e5df7f4f053 361488984d668235438faac28635f3632351407f git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected c75afcd153f6147d3b094f45a1d87e5df7f4f053 587a6a92b93ec314c583bbf747413af170d42540 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected c75afcd153f6147d3b094f45a1d87e5df7f4f053 580f777d6d9fd07fc034bd1aeba5c30fd48871a2 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected c75afcd153f6147d3b094f45a1d87e5df7f4f053 3f4ae5fab613dca01d6a2a8210dd832e009fcf47 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 2.6.36","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 2.6.36 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.109 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.50 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.4 7.2.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3-rc1 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["security/apparmor/include/cred.h","security/apparmor/include/task.h","security/apparmor/task.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"361488984d668235438faac28635f3632351407f","status":"affected","version":"c75afcd153f6147d3b094f45a1d87e5df7f4f053","versionType":"git"},{"lessThan":"587a6a92b93ec314c583bbf747413af170d42540","status":"affected","version":"c75afcd153f6147d3b094f45a1d87e5df7f4f053","versionType":"git"},{"lessThan":"580f777d6d9fd07fc034bd1aeba5c30fd48871a2","status":"affected","version":"c75afcd153f6147d3b094f45a1d87e5df7f4f053","versionType":"git"},{"lessThan":"3f4ae5fab613dca01d6a2a8210dd832e009fcf47","status":"affected","version":"c75afcd153f6147d3b094f45a1d87e5df7f4f053","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["security/apparmor/include/cred.h","security/apparmor/include/task.h","security/apparmor/task.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"2.6.36"},{"lessThan":"2.6.36","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.12.*","status":"unaffected","version":"6.12.109","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.50","versionType":"semver"},{"lessThanOrEqual":"7.2.*","status":"unaffected","version":"7.2.4","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.3-rc1","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.12.109","versionStartIncluding":"2.6.36","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.50","versionStartIncluding":"2.6.36","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2.4","versionStartIncluding":"2.6.36","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3-rc1","versionStartIncluding":"2.6.36","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"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->euid;\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 <creds A> (as both objective and subjective creds),\n   with refcount=2\n2. task grabs an extra reference on <creds A> for overriding\n3. task calls override_creds(<creds A>), which returns a pointer to the old\n   subjective creds (<creds A>)\n4. task enters AppArmor LSM hook\n5. AppArmor checks that objective/subjective creds are equal\n6. AppArmor replaces both cred pointers with <creds B> and drops 2 refs on\n   <creds A>\n7. task leaves AppArmor LSM hook\n8. task calls revert_creds(<creds A>)\n9. now task->cred is <creds A> while task->real_cred is <creds B>, but the\n   task_struct logically holds two references to <creds B>\n10. another task drops the extra reference on <creds A> that was used for\n    overriding, refcount drops to 0\n11. now task->real_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 ->write() callbacks via proc_pid_attr_write().\n\nThere are two options for what to do with aa_dup_task_ctx(): Either\nexplicitly reset new->label_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."}],"providerMetadata":{"dateUpdated":"2026-09-11T19:47:03.601Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/361488984d668235438faac28635f3632351407f"},{"url":"https://git.kernel.org/stable/c/587a6a92b93ec314c583bbf747413af170d42540"},{"url":"https://git.kernel.org/stable/c/580f777d6d9fd07fc034bd1aeba5c30fd48871a2"},{"url":"https://git.kernel.org/stable/c/3f4ae5fab613dca01d6a2a8210dd832e009fcf47"}],"title":"apparmor: fix cred UAF caused by begin_current_label_crit_section()","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-89762","datePublished":"2026-09-11T19:47:03.601Z","dateReserved":"2026-09-11T19:38:34.764Z","dateUpdated":"2026-09-11T19:47:03.601Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-09-11 20:20:07","lastModifiedDate":"2026-09-11 20:20:07","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"89762","Ordinal":"1","Title":"apparmor: fix cred UAF caused by begin_current_label_crit_sectio","CVE":"CVE-2026-89762","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"89762","Ordinal":"1","NoteData":"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->euid;\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 <creds A> (as both objective and subjective creds),\n   with refcount=2\n2. task grabs an extra reference on <creds A> for overriding\n3. task calls override_creds(<creds A>), which returns a pointer to the old\n   subjective creds (<creds A>)\n4. task enters AppArmor LSM hook\n5. AppArmor checks that objective/subjective creds are equal\n6. AppArmor replaces both cred pointers with <creds B> and drops 2 refs on\n   <creds A>\n7. task leaves AppArmor LSM hook\n8. task calls revert_creds(<creds A>)\n9. now task->cred is <creds A> while task->real_cred is <creds B>, but the\n   task_struct logically holds two references to <creds B>\n10. another task drops the extra reference on <creds A> that was used for\n    overriding, refcount drops to 0\n11. now task->real_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 ->write() callbacks via proc_pid_attr_write().\n\nThere are two options for what to do with aa_dup_task_ctx(): Either\nexplicitly reset new->label_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.","Type":"Description","Title":"apparmor: fix cred UAF caused by begin_current_label_crit_sectio"}]}}}