{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-89762 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-89762 is a high-severity use after free vulnerability in Linux, published on 11 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-89762 and fix it if it is affected.\n\nWhat it is: CVE-2026-89762 is a high-severity use after free vulnerability in Linux, published on 11 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-89762 in the wild and no public exploit code.\n\nAffected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-89762/ (Markdown: https://insights.sbomify.com/CVE-2026-89762/index.md)","id":"CVE-2026-89762","markdown":"https://insights.sbomify.com/CVE-2026-89762/index.md","name":"CVE-2026-89762","record":{"aliases":["AZL-100791","BELL-CVE-2026-89762","DEBIAN-CVE-2026-89762","GHSA-p69h-p269-mrvc","UBUNTU-CVE-2026-89762"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["code_execution","privilege_escalation"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"A use-after-free vulnerability in the Linux kernel's AppArmor module allows attackers to potentially execute code or escalate privileges via credential handling flaws.","user_interaction":"not_required","vuln_class":"use_after_free"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":7.8,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"cwes":[],"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-\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.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"apparmor: fix cred UAF caused by begin_current_label_crit_section()","id":"CVE-2026-89762","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"use_after_free","year":"2026"},"n_packages":0,"n_references":5,"next":{"headline":"KEYS: trusted: Fix TPM teardown ordering","id":"CVE-2026-89763"},"packages":[],"prev":{"headline":"apparmor: fix out-of-bounds write when null terminating a label vec","id":"CVE-2026-89761"},"products":["Linux"],"published":"2026-09-11","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-21","vendors":["Linux"]},"summary":"A use-after-free vulnerability in the Linux kernel's AppArmor module allows attackers to potentially execute code or escalate privileges via credential handling flaws.","url":"https://insights.sbomify.com/CVE-2026-89762/"}