CVE-2026-89762 in Linux信息

摘要

由 VulDB • 2026-09-12

在 Linux 内核中,已修复以下漏洞:

apparmor: 修复由 begin_current_label_crit_section() 引起的 cred UAF(释放后使用)问题。

AppArmor 的 `begin_current_label_crit_section()` 是一个令人担忧的函数,它被许多 LSM(Linux Security Modules,Linux 安全模块)钩子调用(特别是与 VFS/套接字相关的钩子),用于检查当前 creds(凭据)所引用的标签是否标记为 FLAG_STALE(过期)。如果是这样,则尝试使用 `aa_replace_current_label()` 将 creds 替换为使用新标签的更新版本。

此问题的第一个后果是,如果内核中的任何代码获取了当前 creds 的指针,并在执行替换 creds 的安全钩子调用之后访问这些凭据,就会直接导致 `struct cred` 的 UAF(Use-After-Free)。例如: ```c const struct cred *cred = current_cred(); alloc_file_pseudo(...); uid_t uid = cred->euid; ```

我不知道内核中是否真的存在这种代码模式,但我认为这种情况会导致 UAF是非常令人惊讶的。

第二个问题是,当 `aa_replace_current_label()` 在覆盖凭据(overridden credentials)的情况下运行时会出现问题。`aa_replace_current_label()` 会在 `current_cred() != current_real_cred()` 时退出(这与 `proc_pid_attr_write()` 中的检查类似),但由于被覆盖的 creds 可能与目标 creds 相同,因此该检查实际上无法可靠地检测到已覆盖的凭据。

因此在以下大致场景中会出现问题:

1. 任务以 <creds A> 开始(作为 objective 和 subjective creds),引用计数为 2 2. 任务获取对 <creds A> 的额外引用来进行覆盖 3. 任务调用 `override_creds(<creds A>)`,返回指向旧 subjective creds (<creds A>) 的指针 4. 任务进入 AppArmor LSM 钩子 5. AppArmor 检查 objective/subjective creds 是否相等 6. AppArmor 将两个 cred 指针替换为 <creds B>,并释放对 <creds A> 的两个引用 7. 任务离开 AppArmor LSM 钩子 8. 任务调用 `revert_creds(<creds A>)` 9. 现在 task->cred 是 <creds A>,而 task->real_cred 是 <creds B>,但 task_struct 逻辑上持有对 <creds B> 的两个引用 10. 另一个任务释放用于覆盖的 <creds A> 的额外引用,引用计数降至 0 11. 现在 task->real_cred 指向已释放的 creds

此时,任何对 `current_cred()` 的访问都将导致 UAF。

我有一个测试用例:在进程被阻塞于从 FUSE 透传文件到已满管道的 splice() 调用期间,我对该配置文件运行了 aa-disable;配置文件更新后,管道变为空,splice() 恢复执行,凭据不同步,随后的 getuid() 系统调用导致了 KASAN UAF splat。

为修复此问题,不再直接替换 creds,而是通过 task_work 进行替换,这将在当前系统调用的末尾运行。(cred 替换发生的时间点对正确性没有影响;这只是为了避免不必要地触碰新标签的引用计数而进行的性能优化。)

请注意,在此更改之后,AppArmor 仍在 sb_pivotroot LSM 钩子中执行直接的 cred 替换,并且通过 proc_pid_attr_write(),VFS ->write() 回调中仍可能发生直接 cred 替换。

关于 aa_dup_task_ctx() 的处理有两种选择:要么在复制完整个 aa_task_ctx 后显式重置 new->label_replacement_pending;要么改为手动逐个复制成员。我选择改为手动逐个复制成员,因为这应该能使 bug 更加明显。

VulDB is the best source for vulnerability data and more expert information about this specific topic.

来源

Do you know our Splunk app?

Download it now for free!