Xen 管理程序客户机逃逸（CVE-2026-102703、CVE-2026-102704）

TL;DR

• Xen 的 grant copy 操作中的两个验证缺陷，让恶意的客户机可以读写属于其他域（包括控制域 Dom0）的内存。Xen Project 于 2026 年 11 月 3 日发布了公告 XSA-523。
• 自 4.6 起的所有 Xen 版本都受影响，4.5 及更早版本不受影响。没有已知的缓解措施。
• 公告没有给出 CVSS 评分。尚无利用报告，且截至 2026 年 11 月 4 日，两个 CVE 均未列入美国网络安全和基础设施安全局（CISA）的已知被利用漏洞（KEV）目录。
• 将 4.17 到 unstable 的 XSA-523 补丁应用到您稳定分支的最新提交，或安装平台供应商的更新。目前还没有任何已发布的 Xen tarball 携带这些补丁。参见“如何修复？”。

您是否受影响？

以下条件全部成立时，您处于暴露之中：

• 您运行 Xen 管理程序，版本为 4.6 或任何更高版本。公告指出自 4.6 起的所有版本都存在漏洞，4.5 及更早版本没有。
• 您的部署运行不可信的客户机。任何操作 grant table 的客户机都可以发出存在漏洞的复制操作。
• 您尚未应用 XSA-523 补丁。公告的解决方案是这组补丁；截至 2026 年 11 月 4 日，没有任何已发布的 Xen tarball 携带它。

这里客户机本身就是攻击者，而不是网络攻击者的受害者。内存被恶意邻居读写的客户机看不到任何迹象。

XCP-ng 是 Xen Project 旗下的平台，其文档称它围绕 Xen 管理程序构建。检查您的主机实际运行的内容：

# On the host (dom0): the running Xen version
xl info | grep '^xen_version'

# In a Linux guest: confirms the hypervisor type (prints "Xen" under Xen)
cat /sys/hypervisor/type 2>/dev/null

# In a Linux guest: the hypervisor version the guest was told
cat /sys/hypervisor/version/major 2>/dev/null
cat /sys/hypervisor/version/minor 2>/dev/null

版本号能说明主机是否处于受影响范围，而自 4.6 起的所有版本都在其中。它无法说明 XSA-523 补丁是否已应用，因为没有任何发布版本包含这些补丁。请改为查看供应商的公告或软件包更新日志中的 XSA-523。

在托管云上，客户机看到的版本可能落后于主机的补丁状态。如果您在其上运行不可信的客户机，请向您的提供商询问主机的 XSA-523 状态。

如何修复？

1. 如果您从稳定分支构建 Xen，请先将分支更新到最新提交，然后应用 XSA-523 补丁。重新构建 Xen，并用打过补丁的管理程序重启主机。公告指出这些补丁是为稳定分支准备的，可能无法干净地应用于发布版 tarball。
2. 如果您运行的是平台供应商或发行版打包的 Xen，请在供应商更新发布时应用它，然后重启主机。截至 2026 年 11 月 4 日，没有任何已发布的 Xen tarball 携带该修复。
3. 仅在恢复计划需要时重新创建客户机。应用管理程序补丁可以阻止未来的攻击；它不会告诉您之前是否发生过攻击。

不存在配置类的临时方案。公告写道：“There is no known mitigation”（没有已知的缓解措施）。

根本原因是什么？

grant copy 超级调用允许客户机在 grant 引用和机器帧号之间复制数据。出于性能考虑，提交 d28f42f2703e（“grant-table: defer releasing pages acquired in a grant copy”）让 Xen 缓存前一个批次元素已验证的描述。该提交首次随 Xen 4.6.0 发布，与公告的受影响版本范围一致。

一批 grant copy 操作通常作用于同一源页或目标页中的相邻地址范围。当下一个元素看起来等价时会复用缓存。按照公告的描述，两个漏洞都是这种复用的条件有误。

CVE-2026-102703 是缓存有效性检查。在 gnttab_copy_buf_valid() 中，p 是新元素的源或目标，b 是缓存的缓冲区。has_gref 表示新元素是否使用 grant 引用（GREF）。易受攻击的代码位于打补丁前 xen-unstable 的 xen/common/grant_table.c 第 3082 至 3091 行：

static bool gnttab_copy_buf_valid(
    const struct gnttab_copy_ptr *p, const struct gnttab_copy_buf *b,
    bool has_gref)
{
    if ( !b->virt )
        return 0;
    if ( has_gref )
        return b->have_grant && p->u.ref == b->ptr.u.ref;
    return p->u.gmfn == b->ptr.u.gmfn;
}

->have_grant 字段记录缓存的条目是否来自 grant 引用。代码只在 grant 引用路径上检查它，且在比较 GREF 之前。机器帧路径比较 p->u.gmfn == b->ptr.u.gmfn，却没有检查缓存的条目是否也是帧条目。

补丁说明给出了后果：来自较早批次元素的（很可能无效的）GREF 可能被误认为（可能有效的）机器帧号（MFN）。

CVE-2026-102704 是权限检查。按帧号（而非按 grant 引用）复制，只允许在操作调用者自身的内存时进行。打补丁前，由同一文件第 2939 至 2946 行的 gnttab_copy_lock_domain() 强制执行这一点：

static int gnttab_copy_lock_domain(domid_t domid, bool is_gref,
                                   struct gnttab_copy_buf *buf)
{
    /* Only DOMID_SELF may reference via frame. */
    if ( domid != DOMID_SELF && !is_gref )
        return GNTST_permission_denied;

    buf->domain = rcu_lock_domain_by_any_id(domid);

gnttab_copy_one() 只有在第 3140 至 3150 行重新锁定域时才会执行这项检查。这里 op 是批次的当前元素，src 和 dest 是缓存的源缓冲区和目标缓冲区：

    if ( !src->domain || op->source.domid != src->ptr.domid ||
         !dest->domain || op->dest.domid != dest->ptr.domid )
    {
        gnttab_copy_release_buf(src);
        gnttab_copy_release_buf(dest);
        gnttab_copy_unlock_domains(src, dest);

        rc = gnttab_copy_lock_domains(op, src, dest);
        if ( rc < 0 )
            goto out;
    }

与前一个元素指定相同域的元素会跳过这段代码。于是它的按帧号复制从不与 DOMID_SELF 比对。

如何被利用？

对于 CVE-2026-102703：

1. 恶意客户机发出一个 GNTTABOP_copy 批次。靠前的元素按 grant 引用复制，因此缓存持有一个已验证的 grant 条目。
2. 同一批次中靠后的元素按机器帧号复制，因此 Xen 将其帧号与缓存的条目比较。
3. 该比较不检查缓存的条目是否为帧条目。较早的 grant 引用被当作帧号，Xen 复用缓存的缓冲区。
4. 复制随后读写客户机无法合法寻址的内存，它属于其他域，包括 Dom0。

对于 CVE-2026-102704：

1. 恶意客户机发出一个复制批次。靠前的元素按 grant 引用指定一个外部域，通过了检查，Xen 锁定该域。
2. 靠后的元素指定同一个域，但按帧号复制。gnttab_copy_one() 跳过域锁定步骤，因此“只有 DOMID_SELF 才能按帧引用”的检查从未运行。
3. 客户机直接用机器帧号寻址另一个域的内存，无需 grant。

这两条路径都不需要特殊的客户机配置，只需要一个正常工作的 grant table。没有公开的概念验证，补丁本身记录了可达的行为。

攻击如何展开？

一批 grant copy 操作复用了已缓存的状态，而两项逐元素检查中任一项的缺失都让客户机得以寻址另一个域的内存。

攻击者能做什么？

用公告的话说，恶意客户机可以读写属于其他域（包括 Dom0）的任意内存。这是信息源支持的最强表述。

实际上，这种访问可能泄露另一个客户机内存中的秘密，或修改另一个客户机的代码和数据。没有公开来源演示过这样的攻击。公告没有给出 CVSS 评分，也没有报告任何实际滥用。

攻击者需要控制未打补丁主机上的一个客户机。只运行可信客户机的主机，只有在其中某个客户机先被攻陷时才会暴露。

修复为什么有效？

CVE-2026-102703 的补丁在新元素的寻址模式与缓存不同时拒绝复用缓存：

 static bool gnttab_copy_buf_valid(
     const struct gnttab_copy_ptr *p, const struct gnttab_copy_buf *b,
     bool has_gref)
 {
-    if ( !b->virt )
+    if ( !b->virt || b->have_grant != has_gref )
         return 0;
     if ( has_gref )
-        return b->have_grant && p->u.ref == b->ptr.u.ref;
+        return p->u.ref == b->ptr.u.ref;
     return p->u.gmfn == b->ptr.u.gmfn;
 }

grant 引用不再可能被拿来与机器帧号比较或混淆。该检查对报告的漏洞是完整的：只有在寻址模式匹配时才会查询缓存。

CVE-2026-102704 的补丁从 gnttab_copy_lock_domain() 中删除 DOMID_SELF 检查，并将其加入 gnttab_copy_claim_buf()：

         buf->ptr.u.ref = ptr->u.ref;
         buf->have_grant = 1;
     }
+    /* Only DOMID_SELF may reference via frame. */
+    else if ( ptr->domid != DOMID_SELF )
+        return GNTST_permission_denied;
     else
     {
         rc = get_paged_frame(ptr->u.gmfn, &buf->mfn, &buf->page,

只要元素无法复用缓存的缓冲区，gnttab_copy_claim_buf() 就会运行。因此，权限检查不再依赖于域锁定步骤是否运行。

应用两个补丁后，批次的每个元素在复用任何内容之前都要经过两道防线：

如何检查是否被入侵？

没有发布任何指标。公告没有描述检测特征，而跨域内存读写不会留下受害客户机可见的痕迹。

在主机上，攻击就是一个发出普通 grant copy 超级调用的客户机，在日志中看起来像正常的 grant table 活动。在应用补丁之前运行过不可信客户机的主机，应将租户秘密视为可能已暴露，并询问其 Xen 供应商关于检测支持的情况。

时间线

• 2015-01-29：提交 d28f42f2703e 将 grant copy 缓存加入 Xen 代码树。
• 2015-10-07：Xen Project 为 Xen 4.6.0 打上标签，这是首个包含该提交的版本。
• 2026-11-03：Xen Project 于 12:00 UTC 公开发布 XSA-523 版本 2，附带 Xen 4.17 到 unstable 的补丁和两个 CVE 编号。

FAQ

这会影响 KVM、Hyper-V 或 VMware 主机吗？

不会。这些漏洞位于 Xen 的 grant table 代码中，是该管理程序特有的。运行其他管理程序的主机不受影响。

CVE 记录发布了吗？

没有。截至 2026 年 11 月 4 日，CVE 数据库中没有 CVE-2026-102703 或 CVE-2026-102704 的记录。公告给出了这两个编号，因此在记录发布之前请参考公告。

谁发现了这个漏洞？

根据公告的署名，Anthropic 使用 Claude 发现了它，Ada Logics 的 Stephan Lipp 验证了这一发现。CodeAnt AI Security Research 团队独立报告了它。修复补丁带有“Assisted-by: Claude”行。公告没有给出首次报告的日期。

我运行的是已结束生命周期的分支，4.16 或更早。我该怎么办？

Xen Project 不为这些分支提供补丁。迁移到受维护的分支（4.17 或更高），并在其上应用 XSA-523 补丁。

我的云提供商运行 Xen。我需要做什么吗？

您无法从客户机修补提供商的主机。请向提供商询问其 XSA-523 状态，并在其确认补丁之前，将租户间秘密视为其责任。

在租户利用之前找到并修补您的 Xen 主机

为不可信客户机运行 Xen 的主机正是这里的暴露面，而攻击者是同一主机上的租户，不是互联网上的扫描器。Ostorlab 的攻击面发现会盘点您暴露在互联网上的服务器和管理接口，为您提供一份需要检查 XSA-523 状态的 Xen 主机初步清单。只能从内部网络访问的主机需要您自己盘点。

参考资料

• Xen Security Advisory 523 版本 2，“arbitrary read/write via grant copy”，2026-11-03 公开发布：https://xenbits.xenproject.org/xsa/advisory-523.html（2026 年 11 月 4 日查阅）
• XSA-523 补丁 1，“gnttab: complete checking in gnttab_copy_buf_valid()”，CVE-2026-102703：https://xenbits.xenproject.org/xsa/xsa523-1.patch（2026 年 11 月 4 日查阅）
• XSA-523 补丁 2，“gnttab: move 'only local domain may copy by frame' check”，CVE-2026-102704：https://xenbits.xenproject.org/xsa/xsa523-2.patch（2026 年 11 月 4 日查阅）
• OSS Security 邮件列表上 XSA-523 版本 2 的副本：https://www.openwall.com/lists/oss-security/2026/11/03/6（2026 年 11 月 4 日查阅）
• Xen 源代码，XSA-523 补丁之前的 xen/common/grant_table.c（提交 c89185286cbe）：https://github.com/xen-project/xen/blob/c89185286cbe74f584e2ddca9bfa6654a8600502/xen/common/grant_table.c（2026 年 11 月 4 日查阅）
• Xen 提交 d28f42f2703e，“grant-table: defer releasing pages acquired in a grant copy”，2015-01-29：https://github.com/xen-project/xen/commit/d28f42f2703e483116bafd2b0b76a32af67d83ad（2026 年 11 月 4 日查阅）
• Xen 4.6.0 发布标签，RELEASE-4.6.0，2015-10-07：https://github.com/xen-project/xen/releases/tag/RELEASE-4.6.0（2026 年 11 月 4 日查阅）
• Xen Project，XCP-ng 项目页面：https://xenproject.org/projects/xcp-ng/（2026 年 11 月 4 日查阅）
• XCP-ng 文档，“XCP-ng contains multiple components, built around the Xen Hypervisor”：https://docs.xcp-ng.org/（2026 年 11 月 4 日查阅）
• CISA 的 Known Exploited Vulnerabilities 目录，JSON 数据源，检索了两个 CVE 编号：https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json（2026 年 11 月 4 日查阅）