Zapscape-Fix — تصحيح ساخن لنواة KVM لـ CVE-2026-64561

English | 简体中文

تصحيح ساخن للنواة (kernel livepatch) لمضيفي KVM على CentOS Stream 8 / RHEL 8 (سلسلة النواة 4.18.0 بالكامل) لمعالجة ثغرة CVE-2026-64561 (Zapscape):

خطر عدم التصحيح: يمكن للجهاز الظاهري المستأجر (guest) الهروب إلى المضيف بمجرد عملياته الخاصة، وتنفيذ تعليمات برمجية بصلاحيات root على نواة المضيف — مما يخترق الجهاز الفيزيائي بالكامل وجميع الأجهزة الافتراضية عليه.

تصحيح هذا المشروع: مبني على backport للإصلاح الرسمي من Linux upstream (2abd5287f083)، ويصبح ساري المفعول عبر الإنترنت من خلال آلية livepatch في النواة:

✅ دون إعادة تشغيل المضيف　✅ دون إعادة تشغيل الأجهزة الافتراضية　✅ دون تعطيل أي ميزة افتراضية　✅ دون أي انقطاع محسوس طوال العملية

النطاق المتأثر (حسب CPU)

تختلف شروط تفعيل Zapscape حسب المنصة: لا توجد أي متطلبات عتادية إضافية على AMD (يمكن تفعيلها على أي CPU يدعم SVM/NPT)؛ أما Intel فيجب أن يدعم 5-level EPT (EPT page-walk length 5، PWL5) وأن يعرضه المضيف إلى L1، وإلا فلا يمكن بناء alias الجذر/الابن، ولا يمكن تفعيل مسار الهجوم هذا.

المنصة	سلسلة CPU	قابل للتفعيل (يحتاج تصحيحًا)
Intel	Xeon Scalable الجيل الأول — Skylake-SP (4100/5100/6100/8100)	✗ لا
Intel	Xeon Scalable الجيل الثاني — Cascade Lake (4200/5200/6200/8200)	✗ لا (بما في ذلك 8259CL المختبر في هذا المستودع)
Intel	Xeon Scalable الجيل الثالث — Ice Lake-SP (4300/5300/6300/8300)	✓ نعم
Intel	Xeon Scalable الجيل الرابع — Sapphire Rapids (8400)	✓ نعم
Intel	Xeon Scalable الجيل الخامس — Emerald Rapids (8500)	✓ نعم
Intel	أخرى (Xeon E، Cooper Lake 83xxH وغيرها من الطرازات الطرفية)	حسب الاختبار الفعلي
AMD	EPYC الأجيال 1–3 (Naples 7001 / Rome 7002 / Milan 7003)	✓ نعم (لا حاجة إلى LA57 ولا يتطلبها)
AMD	EPYC الجيل الرابع (Genoa/Bergamo/Siena 9004/8004)	✓ نعم

الأساس: نفّذت Intel 5-level paging / 5-level EPT لأول مرة في معمارية Ice Lake (Wikipedia: Intel 5-level paging؛ ورقة Intel البيضاء «5-Level Paging and 5-Level EPT»، رقم الوثيقة 671442)؛ وقد اختبر هذا المستودع على Xeon Platinum 8259CL (Cascade Lake) البت 7 (PWL5) في IA32_VMX_EPT_VPID_CAP (MSR 0x48C) = 0، ولا يوجد la57 في /proc/cpuinfo — مما يؤكد أن Cascade Lake وما قبله لا يملك 5-level EPT. أما NPT في AMD فهو دائمًا walk عتادي من 4 مستويات، ولا يحتاج Zapscape إلى قدرة 5 مستويات، لذا يمكن تفعيله على جميع أجيال AMD.

⚠️ جدول الأجيال للإرشاد فقط، والاختبار الفعلي هو المرجع (قد تعطّل مزودات السحابة/البرامج الثابتة ميزات معينة). أمر واحد لتأكيد ما إذا كان مضيف Intel لديك يحتاج إلى تصحيح:

# 方法一（简单）：检查 LA57（5-level paging）
grep -m1 flags /proc/cpuinfo | grep -o la57 && echo "有 LA57 → 需打补丁" || echo "无 LA57 → 大概率无需"

# 方法二（直接，Intel 专用）：读取 EPT 能力 MSR 0x48C 的 bit 7（PWL5）
dnf install -y msr-tools && modprobe msr
V=$(rdmsr -p0 0x48c); echo "EPT PWL5 支持: $(( (0x$V >> 7) & 1 ))"   # 1=支持（需打补丁） 0=不支持

⚠️ "غير قابل للاستغلال" ≠ "آمن تمامًا": يعني فقط أن مسار هجوم Intel في Zapscape غير صالح؛ قد تظل وحدة إدارة الذاكرة الظلية (shadow MMU) في KVM عرضة لمخاطر أخرى، لذا يُرجى متابعة تحديثات الأمان الرسمية.

دعم Kernel-ML (نواة ELRepo mainline)

إذا قمت بتثبيت kernel-ml (نواة mainline) من ELRepo لأن مضيفك يحتاج إلى نواة جديدة بسبب ثغرات CVE أخرى، فإن حالة إصلاح Zapscape تعتمد على الإصدار:

إصدار kernel-ml	حالة Zapscape	الإجراء
7.1.3 / 7.1.4	❌ غير مُصلح (تم التحقق من الشيفرة المصدرية)	الترقية إلى 7.1.7، أو استخدام kernel-ml livepatch من هذا المستودع (تم اختباره فعليًا)
7.1.5 / 7.1.6	✅ مُصلح (تم دمج 2abd5287f083 من المنبع)	لا حاجة لأي إجراء
7.1.7	✅ مُصلح (تم التحقق من الشيفرة المصدرية)	لا حاجة لأي إجراء

الطريقة الموصى بها: ترقية kernel-ml إلى أحدث إصدار حالي (7.1.7)، حيث تُحل الثغرة مع إصلاحات المنبع، دون الحاجة إلى livepatch.
الترقيع الساخن لـ 7.1.3/7.1.4 (تم اختباره فعليًا): تأتي نواة mainline مع سلسلة أدوات KLP كاملة (CONFIG_LIVEPATCH=y + CONFIG_KLP_BUILD=y + الأمر الفرعي klp في objtool)، دون الحاجة إلى kpatch. يستخدم هذا المستودع تدفق objtool klp diff + post-link الأصلي في النواة، مع الدوال المُصلحة في 7.1.7 وهي direct_page_fault / paging64_page_fault / paging32_page_fault / ept_page_fault كبدائل، لتوليد وحدة livepatch لـ 7.1.3 (livepatch/kernel-ml/، راجع livepatch/kernel-ml/README.md). تم اختباره فعليًا على 7.1.3 (مُجمّع ذاتيًا، متوافق مع شيفرة ELRepo 7.1.x المصدرية): تم تحميل الوحدة المولدة بواسطة kpatch/objtool بنجاح، ويُظهر /sys/kernel/livepatch استبدال جميع الدوال الأربع (enabled=1)، واكتمال transition، دون أي تأثير على الأجهزة الافتراضية قيد التشغيل.

ملاحظة: أزال 7.1.x التنسيق القديم klp_reloc من عصر kpatch، واستخدم بدلاً من ذلك مقاطع .klp.rela.* (يُحللها klp_resolve_symbols)، لذلك فإن سلسلة أدوات kpatch 0.9.x المستخدمة مع 4.18 غير قابلة للاستخدام على 7.1.x؛ يعتمد حل kernel-ml في هذا المستودع بالكامل على سلسلة أدوات KLP الأصلية في النواة.

تثبيت kernel-ml في البر الرئيسي للصين (مرآة ELRepo المحلية)

المصدر الرسمي لـ ELRepo (elrepo.org) يعاني من ضعف الاتصال داخل الصين (حوالي 15 kB/s فعليًا). يُرجى استخدام المرآة المحلية (4 MB/s+ فعليًا):

# 安装 elrepo-release（一次）
dnf install -y https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpm

# 把 elrepo-kernel 源切换到清华 TUNA 镜像（中科大 USTC 同样可用：
#   https://mirrors.ustc.edu.cn/elrepo/kernel/el8/$basearch/）
awk '
/^\[elrepo-kernel\]/ {ink=1}
/^\[/ && !/^\[elrepo-kernel\]/ {ink=0}
ink && /^baseurl=/ { print "baseurl=https://mirrors.tuna.tsinghua.edu.cn/elrepo/kernel/el8/$basearch/"; next }
ink && /^[[:space:]]/ { next }
ink && /^mirrorlist=/ { print "#" $0; next }
{ print }
' /etc/yum.repos.d/elrepo.repo > /etc/yum.repos.d/elrepo.repo.new && \
mv /etc/yum.repos.d/elrepo.repo.new /etc/yum.repos.d/elrepo.repo

# 安装最新 mainline 内核（含 kernel-ml-devel，kpatch 构建也需要它）
dnf --enablerepo=elrepo-kernel install -y kernel-ml kernel-ml-devel

# 确认新内核成为默认启动项
grubby --default-kernel
# 输出 /boot/vmlinuz-7.1.7-1.el8.elrepo.x86_64 即为成功

⚠️ ترقية النواة تتطلب إعادة التشغيل لتصبح سارية المفعول؛ إعادة التشغيل تُبطل livepatch المحمّل مسبقًا على النواة 4.18 (إذا كانت النواة الجديدة تتضمن الإصلاح مدمجًا فلا حاجة لإعادة التحميل). قبل إعادة التشغيل، تأكد من آلية استعادة الأجهزة الافتراضية (لوحة Magic Cube Cloud تقوم تلقائيًا بإعادة تشغيل الأجهزة الافتراضية التي تديرها).

متطلبات النظام

البند	المتطلبات
نظام التشغيل	CentOS Stream 8 / RHEL 8 (بما في ذلك جميع الفروع من 8.0 إلى 8.10)
منصة المحاكاة الافتراضية	智简魔方魔方云 KVM加强版 (idcsmart Cloud KVM) — تم التحقق منها عمليًا
النواة	أي إصدار فرعي من `4.18.0-*` (تمت تغطية جميع أشكال الشيفرة من `4.18.0-80` إلى `4.18.0-553`)
الصلاحيات	root
التبعيات	gcc، make، git، patch، elfutils، openssl-devel، bc، bison، flex، dwarves، kpatch، kernel-devel (بنفس إصدار النواة قيد التشغيل)، حزمة RPM لشيفرة النواة المصدرية
الوقت	يستغرق البناء الأول حوالي 20–40 دقيقة (حسب عدد أنوية المعالج)

يجب أن تدعم النواة livepatch (CONFIG_LIVEPATCH=y، مفعّل افتراضيًا في RHEL 8 / Stream 8)، وسيتم التحقق من ذلك أولًا في الخطوة 0 من النشر.

خطوات النشر

الخطوة 0: التأكد من دعم النواة لـ livepatch

grep CONFIG_LIVEPATCH /boot/config-$(uname -r)

يجب أن يكون الناتج CONFIG_LIVEPATCH=y، وإلا فلن يكون هذا النواة قابلاً للترقيع الساخن.

Zapscape-Fix

الأكثر شعبية