AlmaLinux और Rocky Linux पर CVE-2026-98432 के लिए kpatch livepatch

日本語

Livepatch मॉड्यूल जो चल रहे AlmaLinux या Rocky Linux 8, 9 या 10 होस्ट (x86_64) पर रीबूट के बिना CVE-2026-98432 को ठीक करते हैं। जिन कर्नेल में CVE-2026-99999 का फ़िक्स भी नहीं है, वहाँ यही मॉड्यूल उसे भी ठीक कर देता है, इसलिए होस्ट को एक ही मॉड्यूल चाहिए, चाहे उसके कर्नेल में इन दोनों में से कोई भी अनुपस्थित हो।

स्थिति (2026-11-02): प्रत्येक मॉड्यूल बनाया और लोड-टेस्ट किया जा चुका है; अभी तक कोई भी जारी नहीं हुआ है, इसलिए लागू करने के लिए कुछ नहीं है। इसके बाद रिलीज़, और प्रत्येक जारी मॉड्यूल पर एक-पंक्ति कमांड का परीक्षण आता है; तब तक scripts/livepatch.sh की तालिका में कोई मॉड्यूल नहीं है और यह हर कर्नेल को अस्वीकार करता है।

कर्नेल

684 कर्नेल: AlmaLinux के 380 और Rocky Linux के 304, 8.3 से 10.2 तक, tools/kernels.tsv में सूचीबद्ध। यह उन सभी कर्नेल हैं जिनके SRPM और debuginfo वितरण के मिरर (vault सहित) पर उपलब्ध हैं, केवल x86_64, सिवाय Rocky के 5.14.0-611.41.1.el9_7 के, जिसका debuginfo किसी भी मिरर पर नहीं है। इसमें Rocky का एकमात्र 8.3 कर्नेल, 4.18.0-240.22.1.el8 भी शामिल है, जिसे पिछले Rocky रिपॉज़िटरी में शामिल नहीं किया गया था, और वे कर्नेल भी जो दोनों वितरणों ने पिछली रिपॉज़िटरी के बाद जारी किए, 4.18.0-553.180.1.el8_10 (AlmaLinux), 5.14.0-687.61.1.el9_8 और 6.12.0-211.69.1.el10_2 तक। AlmaLinux 10 का x86_64_v2 वेरिएंट शामिल नहीं है।

684 में से 666 में CVE-2026-99999 का फ़िक्स भी नहीं है, और उनके मॉड्यूल में दोनों शामिल हैं। शेष 18 में यह पहले से मौजूद है (AlmaLinux 4.18.0-553.177.1.el8_10 और Rocky 553.178.1.el8_10 से, तथा दोनों पर 5.14.0-687.59.1.el9_8 और 6.12.0-211.67.1.el10_2 से), और उनके मॉड्यूल में केवल CVE-2026-98432 का परिवर्तन शामिल है।

क्या परीक्षण किया गया

प्रत्येक मॉड्यूल CI में बनाया गया और scripts/livepatch.sh के साथ VM में उसके शिप्ड कर्नेल पर लागू किया गया (tools/loadtest.sh), 2026-10-31, प्रति वितरण और माइनर एक रन, कुल 40 रन; सभी 684 ने RESULT: PASS प्रिंट किया। प्रत्येक में:

• inet_sock_destruct और tcp_v4_reqsk_destructor को vmlinux के पैच किए गए फ़ंक्शन के रूप में सूचीबद्ध किया गया है।
• IP विकल्प सेट वाले सॉकेट से लूपबैक पर 2,000 TCP कनेक्शन, और रॉ सॉकेट से IP विकल्प ले जाने वाले 2,000 बेयर SYN, बिना किसी त्रुटि और बिना किसी कर्नेल चेतावनी के चलाए गए (tools/tcpopt.py)। यह उन दोनों फ़्री को चलाता है जिन्हें फ़िक्स विकल्पों की उपस्थिति में बदलता है; IP विकल्पों के बिना वे केवल NULL को फ़्री करते हैं।
• जहाँ मॉड्यूल में CVE-2026-99999 का भाग शामिल है, वह vmlinux, nfnetlink_queue और xt_CHECKSUM पर (तथा 9 और 10 पर nf_conntrack_bridge पर) प्रभावी होता है। 8 और 9 पर (511 कर्नेल, और Rocky का 8.3) एक तैयार किया गया फ़्रेम शिप्ड कर्नेल द्वारा फ़्रैगमेंट किया गया और मॉड्यूल लागू होने पर ड्रॉप कर दिया गया। 10 पर (154 कर्नेल) फ़्रेम को ख़राबी तक पहुँचने से पहले ही अस्वीकार कर दिया जाता है, इसलिए वह जाँच वहाँ किसी भी तरह से कुछ नहीं बताती।
• 665 कर्नेल के पास पिछली रिपॉज़िटरी से एक मॉड्यूल था। उसे पहले लोड किया गया, और नए मॉड्यूल ने उसे प्रतिस्थापित किया: पिछला पैच अक्षम हो गया और उसका मॉड्यूल अनलोड हो गया।
• इसके बाद मॉड्यूल को अक्षम और हटा दिया गया।

परीक्षण नहीं किया गया: रेस स्वयं। शिप्ड कर्नेल पर CVE-2026-98432 को और मॉड्यूल के साथ उसकी अनुपस्थिति को दर्शाने के लिए KASAN और चाइल्ड की रिलीज़ के साथ पुनःप्रेषित SYN के एक कृत्रिम इंटरलीविंग की आवश्यकता होती है; इन VMs में यह माँग पर नहीं होता। न ही किसी मॉड्यूल का परीक्षण Secure Boot चालू रखकर किया गया (यह अहस्ताक्षरित है और अस्वीकार कर दिया जाएगा), या kpatch.service द्वारा बूट पर लोड करके।

पोर्ट कैसे बनाए जाते हैं

tools/mkdiffs.sh किसी माइनर के प्रत्येक कर्नेल SRPM को पोर्ट करता है। यह पहले SRPM के अपने पैच को उसके tarball पर लागू करता है, जैसा %prep करता है (tools/prep.py): AlmaLinux इस तरह अपने स्वयं के फ़िक्स ले जाता है, उनमें 4.18.0-553.177.1.el8_10 में CVE-2026-99999 का भी, और 10.2 का 6.12.0-211.69.1, Red Hat का 211.56.1 tarball प्लस 466 पैच है, इसलिए बिना पैच वाले tarball के विरुद्ध बनाया गया पोर्ट उस चीज़ को छोड़ देगा जो कर्नेल में मौजूद है। फिर बदली गई पंक्तियों को tools/ref/ के विरुद्ध जाँचा जाता है: CVE-2026-98432 की पंक्तियाँ upstream की पंक्तियों के बराबर होनी चाहिए, CVE-2026-99999 की 8 या 9 के लिए AlmaLinux के पैच या 10 के लिए upstream के पैच के बराबर होनी चाहिए, या जहाँ कर्नेल में वह फ़िक्स मौजूद है वहाँ अनुपस्थित होनी चाहिए। सभी 684 मेल खाए। tools/port.py तब भी रुक जाता है यदि ट्री का kfree_rcu() किसी NULL पॉइंटर को नहीं छोड़ेगा, जैसा कि दोनों पॉइंटर आमतौर पर होते हैं।

8 और 9 को kpatch-build से बनाया गया है, 10 को kernel के अपने klp-build से; दोनों replace patches बनाते हैं, जिस तरह से एक module किसी पहले वाले से कार्यभार संभालता है।

CVE-2026-98432

upstream fix torvalds/linux e3f33b0a1d89 है, "ipv4: free inet_opt and ireq_opt after an RCU grace period"। जब किसी SYN में IP options होते हैं, तो listener उन्हें request socket (ireq_opt) पर रखता है और बिना copy किए child socket (inet_opt) को सौंप देता है। उसी request के लिए retransmitted SYN का उत्तर किसी अन्य CPU पर SYN-ACK से दिया जा सकता है, जो उन options को RCU के अंतर्गत पढ़ता है, जबकि child बंद हो चुका होता है और inet_sock_destruct() उन्हें सादे kfree() से मुक्त कर देता है: एक use after free। Request socket migration में भी tcp_v4_reqsk_destructor() में वही समस्या है। fix दोनों को kfree_rcu() से मुक्त करता है।

किसी भी distribution ने fix जारी नहीं किया है: 2026-10-27 को AlmaLinux और Rocky Linux 8, 9 और 10 के नवीनतम kernels ने अपने changelogs में CVE का नाम नहीं लिया, और 4.18.0-305.3.1.el8_4, 4.18.0-553.179.1.el8_10, 5.14.0-687.61.1.el9_8 और 6.12.0-211.68.1.el10_2 के sources अभी भी दोनों pointers को kfree() से मुक्त करते हैं।

CVE-2026-99999

पहले ठीक किया गया, प्रत्येक distribution के लिए अलग-अलग, nsrg-fmlorg/kpatch-alma-cve-2026-99999 और nsrg-fmlorg/kpatch-rocky-cve-2026-99999 द्वारा। दोनों distributions अब उस fix वाले kernels जारी करते हैं, 4.18.0-553.177.1.el8_10 (AlmaLinux) या 553.178.1.el8_10 (Rocky), 5.14.0-687.59.1.el9_8 और 6.12.0-211.67.1.el10_2 से आगे। जहाँ किसी kernel में यह नहीं है, वहाँ इस repository का module पहले वालों के समान परिवर्तन रखता है, और पहले से लोड किए गए किसी module को प्रतिस्थापित करता है (ऊपर उल्लिखित उन सभी 665 kernels पर परीक्षण किया गया जिनमें कोई module था)।

Layout