Zapscape-Fix — CVE-2026-64561 KVM कर्नेल हॉटपैच

English | 简体中文

CentOS Stream 8 / RHEL 8 (4.18.0 पूर्ण श्रृंखला कर्नेल) के KVM होस्ट के लिए CVE-2026-64561 (Zapscape) कमजोरी को ठीक करने वाला कर्नेल हॉटपैच:

पैच न लगाने का जोखिम: किरायेदार वर्चुअल मशीन (guest) केवल अपने स्वयं के संचालन के बल पर होस्ट तक एस्केप कर सकती है और होस्ट कर्नेल root अनुमतियों के साथ कोड निष्पादित कर सकती है—जिससे पूरी भौतिक मशीन और उस पर चल रही सभी वर्चुअल मशीनें भेदी जा सकती हैं।

इस परियोजना का पैच: Linux अपस्ट्रीम के आधिकारिक फिक्स (2abd5287f083) पर आधारित backport है, जो कर्नेल livepatch तंत्र के माध्यम से ऑनलाइन प्रभावी होता है:

✅ होस्ट को रीबूट नहीं करना पड़ता　✅ वर्चुअल मशीन को रीबूट नहीं करना पड़ता　✅ किसी भी वर्चुअलाइज़ेशन सुविधा को बंद नहीं करना पड़ता　✅ पूरी प्रक्रिया अदृश्य रहती है

---

विषय-सूची

• प्रभावित दायरा (CPU के अनुसार)
• Kernel-ML (ELRepo mainline कर्नेल) समर्थन
• सिस्टम आवश्यकताएँ
• परिनियोजन चरण
• सत्यापित करें कि पैच प्रभावी है या नहीं
• रोलबैक
• सामान्य प्रश्न
• परियोजना संरचना
• संदर्भ सामग्री
• कॉपीराइट और लाइसेंस

---

प्रभावित दायरा (CPU के अनुसार)

Zapscape की ट्रिगर शर्तें प्लेटफ़ॉर्म के अनुसार भिन्न हैं: AMD के लिए कोई अतिरिक्त हार्डवेयर आवश्यकता नहीं (SVM/NPT समर्थन वाला कोई भी CPU ट्रिगर कर सकता है); Intel के लिए 5-स्तरीय EPT (EPT page-walk length 5, PWL5) का समर्थन अनिवार्य है और होस्ट को इसे L1 तक उजागर करना होगा, अन्यथा root/child उपनाम का निर्माण नहीं हो सकता और यह आक्रमण पथ ट्रिगर नहीं हो सकता।

प्लेटफ़ॉर्म	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 पहली–तीसरी पीढ़ी (Naples 7001 / Rome 7002 / Milan 7003)	✓ हाँ (LA57 की आवश्यकता नहीं)
AMD	EPYC चौथी पीढ़ी (Genoa/Bergamo/Siena 9004/8004)	✓ हाँ

आधार: 5-level paging / 5-level EPT को Intel ने Ice Lake माइक्रोआर्किटेक्चर में पहली बार लागू किया (Wikipedia: Intel 5-level paging; Intel श्वेतपत्र《5-Level Paging and 5-Level EPT》, दस्तावेज़ संख्या 671442); इस रिपॉज़िटरी ने Xeon Platinum 8259CL (Cascade Lake) पर परीक्षण करके पाया कि IA32_VMX_EPT_VPID_CAP (MSR 0x48C) का bit 7 (PWL5) = 0 है, और /proc/cpuinfo में la57 नहीं है—जो पुष्टि करता है कि Cascade Lake और उससे पहले के CPU में 5-स्तरीय EPT नहीं है। AMD का NPT सदैव 4-स्तरीय हार्डवेयर walk रहता है, 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=不支持

⚠️ "ट्रिगर न करने योग्य" ≠ "पूर्णतः सुरक्षित": यह केवल दर्शाता है कि Zapscape का Intel हमला पथ लागू नहीं होता; KVM shadow MMU में अभी भी अन्य जोखिम हो सकते हैं, कृपया आधिकारिक सुरक्षा अपडेट पर ध्यान देना जारी रखें।

---

Kernel-ML (ELRepo mainline कर्नेल) समर्थन

यदि आपके होस्ट मशीन पर किसी अन्य CVE के कारण नए कर्नेल की आवश्यकता है और आपने ELRepo से kernel-ml (mainline कर्नेल) इंस्टॉल किया है, तो 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 + objtool klp सबकमांड), kpatch की आवश्यकता नहीं। यह रिपॉज़िटरी कर्नेल के मूल objtool klp diff + post-link प्रक्रिया का उपयोग करती है, और 7.1.7 में पहले से ठीक किए गए direct_page_fault / paging64_page_fault / paging32_page_fault / ept_page_fault को प्रतिस्थापन निकाय के रूप में लेकर 7.1.3 के लिए livepatch मॉड्यूल उत्पन्न करती है (livepatch/kernel-ml/, विवरण के लिए देखें livepatch/kernel-ml/README.md)। 7.1.3 (स्वयं संकलित, ELRepo 7.1.x स्रोत के समान) पर परीक्षण किया गया: kpatch/objtool द्वारा उत्पन्न मॉड्यूल सफलतापूर्वक लोड हुआ, /sys/kernel/livepatch में सभी 4 फ़ंक्शन प्रतिस्थापित दिखे (enabled=1), transition पूर्ण हुआ, चल रही वर्चुअल मशीनों को कोई प्रभाव नहीं पड़ा।

नोट: 7.1.x में kpatch युग का पुराना klp_reloc प्रारूप हटा दिया गया है, इसके बजाय .klp.rela.* सेक्शन (klp_resolve_symbols द्वारा पार्स) का उपयोग होता है, इसलिए 4.18 के लिए उपयोग किया जाने वाला kpatch 0.9.x टूलचेन 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 即为成功

⚠️ कर्नेल अपग्रेड करने पर पुनः आरंभ करना अनिवार्य है, तभी वह प्रभावी होगा; पुनः आरंभ करने से 4.18 कर्नेल पर पहले से लोड किया गया livepatch अमान्य हो जाएगा (यदि नए कर्नेल में ही फ़िक्स शामिल है तो दोबारा लोड करने की आवश्यकता नहीं है)। पुनः आरंभ करने से पहले कृपया वर्चुअल मशीन के रिकवरी तंत्र की पुष्टि करें (मैजिक क्यूब क्लाउड पैनल अपने प्रबंधन वाले VM को स्वतः शुरू कर देगा)।

---

सिस्टम आवश्यकताएँ