From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 23B85563287 for ; Fri, 11 Sep 2026 20:06:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789157184; cv=none; b=GqsyaXtJD2LIs1iAtpZ4EnYbz5zDcGU1dIb/qjcH2Q0XPPc4cGoqEpHsOx3oMtnGbdzMwPiUvQeDAYpSgmbZbLU1wmenNzMfglqYYQKua0Sfk/sYiTWFHTYMy5V2lQVbuWQyYmdRRoEPEwsBopNLVmpO5XCJPRXyd5akjY/pqg4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789157184; c=relaxed/simple; bh=Q1QVTQ4oFr9K8ZviMvQ9KZ42uKFlGaiw0NIF1wcStTs=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=VH2L3h93SoX4D+I5+gWqh7gQhXlvS1C3EWreXH3ZMGvjelJREfA59Ioada0pqx18urxcSNAh/2YtJgiwV/vxrtC/5B8r7KoA6Sed9WFHpkPG98smZAX9MIhpAfDyWeh3mjN8z1ZuqZBfC0sJ9GB7vE8IhTY4Fd+U8bW6slBfp74= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=JOLfEPIS; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="JOLfEPIS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 639D01F000FF; Fri, 11 Sep 2026 20:06:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1789157178; bh=mxLnA9hJKGTmQs6hhZRwRFm0KEPjE03FBx5wAVdqUg8=; h=From:To:Cc:Subject:Date:Reply-To; b=JOLfEPISKaoerzTzjuU2QYIH1fpH3FVyi2/8Sk/Osi+Vppfg8LnyLhZX6DY0SDLfZ LF7TcfC6PkUTR6uoRb40QI11RzdmyxP9WbUB1zhl4JykA1tGL0vnPdBFhbIJM6gZXA UB/df3wFkl+m8gXP4EzD+KjFOg9Pbui9oUKfJRTU= From: Greg Kroah-Hartman To: linux-cve-announce@vger.kernel.org Cc: Greg Kroah-Hartman Subject: CVE-2026-89762: apparmor: fix cred UAF caused by begin_current_label_crit_section() Date: Fri, 11 Sep 2026 21:47:31 +0200 Message-ID: <2026091109-CVE-2026-89762-4aa8@gregkh> X-Mailer: git-send-email 2.55.0 Reply-To: , Precedence: bulk X-Mailing-List: linux-cve-announce@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=5623; i=gregkh@linuxfoundation.org; h=from:subject:message-id; bh=1xPqdN80DBWj/Z3xTaIgFp4Zyg3hPYRMsjsZIAiSbBE=; b=owGbwMvMwCRo6H6F97bub03G02pJDFlLIid2C/wolUjjN9cQPS/87UL3h/OzS1XcN/zbcT7ds f7A7qLjHbEsDIJMDLJiiixftvEc3V9xSNHL0PY0zBxWJpAhDFycAjARR0aGubJ/a/38xP+JhLE+ 6bHLiHp8/OiMCIYFJ0Pe8z67/vR9b8oB75OTQksbCw94AAA= X-Developer-Key: i=gregkh@linuxfoundation.org; a=openpgp; fpr=F4B60CC5BF78C2214A313DCB3147D40DDB2DFB29 Content-Transfer-Encoding: 8bit From: Greg Kroah-Hartman 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 (as both objective and subjective creds), with refcount=2 2. task grabs an extra reference on for overriding 3. task calls override_creds(), which returns a pointer to the old subjective creds () 4. task enters AppArmor LSM hook 5. AppArmor checks that objective/subjective creds are equal 6. AppArmor replaces both cred pointers with and drops 2 refs on 7. task leaves AppArmor LSM hook 8. task calls revert_creds() 9. now task->cred is while task->real_cred is , but the task_struct logically holds two references to 10. another task drops the extra reference on 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. The Linux kernel CVE team has assigned CVE-2026-89762 to this issue. Affected and fixed versions =========================== Issue introduced in 2.6.36 with commit c75afcd153f6147d3b094f45a1d87e5df7f4f053 and fixed in 6.12.109 with commit 361488984d668235438faac28635f3632351407f Issue introduced in 2.6.36 with commit c75afcd153f6147d3b094f45a1d87e5df7f4f053 and fixed in 6.18.50 with commit 587a6a92b93ec314c583bbf747413af170d42540 Issue introduced in 2.6.36 with commit c75afcd153f6147d3b094f45a1d87e5df7f4f053 and fixed in 7.2.4 with commit 580f777d6d9fd07fc034bd1aeba5c30fd48871a2 Issue introduced in 2.6.36 with commit c75afcd153f6147d3b094f45a1d87e5df7f4f053 and fixed in 7.3-rc1 with commit 3f4ae5fab613dca01d6a2a8210dd832e009fcf47 Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2026-89762 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: security/apparmor/include/cred.h security/apparmor/include/task.h security/apparmor/task.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/361488984d668235438faac28635f3632351407f https://git.kernel.org/stable/c/587a6a92b93ec314c583bbf747413af170d42540 https://git.kernel.org/stable/c/580f777d6d9fd07fc034bd1aeba5c30fd48871a2 https://git.kernel.org/stable/c/3f4ae5fab613dca01d6a2a8210dd832e009fcf47