v0idnetwork/cve-2026-46331pedit COW
CVE-2026-46331 (उपनाम “pedit COW”) ट्रैफ़िक-नियंत्रण सबसिस्टम में एक स्थानीय Linux कर्नेल विशेषाधिकार-वृद्धि दोष है। एक विशेषाधिकार-रहित उपयोगकर्ता (विशेषाधिकार-रहित नेटवर्क नेमस्पेस में) act_pedit (पैकेट संपादक) फ़िल्टर को कॉन्फ़िगर करके पेज कैश में आंशिक कॉपी-ऑन-राइट (COW) लेखन ट्रिगर कर सकता है। प्रभावी रूप से, कर्नेल पृष्ठ को निजी चिह्नित किए बिना हमलावर-नियंत्रित डेटा को फ़ाइल की इन-मेमोरी छवि में लिखता है, जिससे उस फ़ाइल की कैश्ड प्रतिलिपि दूषित हो जाती है। महत्वपूर्ण बात यह है कि इस शोषण के लिए केवल CAP_NET_ADMIN की आवश्यकता होती है (जो उपयोगकर्ता नेमस्पेस में प्राप्त किया जा सकता है) और यह डिस्क पर मौजूद फ़ाइल को संशोधित नहीं करता। व्यवहार में, packet_edit_meme नामक एक कार्यशील प्रूफ-ऑफ-कॉन्सेप्ट (PoC) 17 जून, 2026 को प्रकाशित किया गया था, जो दर्शाता है कि रूट शेल प्राप्त करने के लिए setuid बाइनरी (जैसे /bin/su) की पेज-कैश छवि को कैसे अधिलेखित किया जाए। यह भेद्यता tcf_pedit_act() में गलत COW-सीमा गणना से उत्पन्न होती है और इसे अपस्ट्रीम (4 जून, 2026) में प्रति-कुंजी लूप में राइटेबल-क्षेत्र जाँच को स्थानांतरित करके ठीक किया गया है।
act_pedit है। बिना पैच वाले स्थिर रिलीज़ (कई डिस्ट्रो कर्नेल सहित) असुरक्षित हैं।tc pedit फ़िल्टर सेट करता है, और मेमोरी में setuid बाइनरी के ELF एंट्री पॉइंट को शेलकोड से अधिलेखित कर देता है।skb_ensure_writable() को कुंजी लूप के अंदर स्थानांतरित कर दिया)। वर्कअराउंड के रूप में, act_pedit मॉड्यूल को ब्लॉक या अनलोड करें या विशेषाधिकार-रहित उपयोगकर्ता नेमस्पेस को अक्षम करें (जैसे sysctl user.max_user_namespaces=0). शमन के बाद, कैश ड्रॉप करें (echo 3 > /proc/sys/vm/drop_caches) ताकि किसी भी विषाक्त पृष्ठ को हटाया जा सके।यह रिपोर्ट CVE-2026-46331 का विस्तृत तकनीकी विश्लेषण प्रदान करती है: इसका कारण, शोषण, पहचान और उपचार रणनीतियाँ, विक्रेता सलाह, CVE और सार्वजनिक शोषण के संदर्भों के साथ।
परिभाषा: CVE-2026-46331 Linux कर्नेल के ट्रैफ़िक नियंत्रण (net/sched) सबसिस्टम में एक आउट-ऑफ-बाउंड राइट बग है, विशेष रूप से act_pedit (पैकेट संपादक) क्रिया में। फ़ंक्शन tcf_pedit_act() टाइप की गई कुंजियों पर पुनरावृति करने से पहले पैकेट-संपादन कार्यों के लिए एक “कॉपी-ऑन-राइट” सीमा की गणना करता है, एक स्थिर संकेत tcfp_off_max_hint का उपयोग करते हुए। हालाँकि, कुछ कुंजियाँ (जैसे TCP/UDP हेडर संपादन) अपने अंतिम बाइट ऑफ़सेट का निर्धारण केवल रनटाइम पर करती हैं। कोड इन गतिशील ऑफ़सेट के लिए कभी भी राइटेबिलिटी की पुनः जाँच नहीं करता। परिणामस्वरूप, लेखन पूर्व-COW’d क्षेत्र के बाहर हो सकता है: पैकेट लेखन का कुछ भाग कभी निजी नहीं बनाया जाता, जिससे आंशिक COW उत्पन्न होता है। यह त्रुटिपूर्ण लेखन किसी फ़ाइल की साझा पेज-कैश मेमोरी में फैल जाता है (यदि पैकेट बफ़र संयोगवश फ़ाइल पृष्ठों को संदर्भित करते हैं), जिससे कैश्ड फ़ाइल छवि दूषित हो जाती है।
पृष्ठभूमि: Linux पैकेट संपादक (pedit) क्रिया प्रशासकों को कॉन्फ़िगर किए गए tc फ़िल्टर से गुजरते समय पैकेट हेडर (लिंक, नेटवर्क, या ट्रांसपोर्ट परतों) के भीतर स्वेच्छ बाइट्स को फिर से लिखने की अनुमति देती है। यह एक ऑफ़सेट (संभवतः किसी हेडर से जुड़ा हुआ) और एक 32-बिट मान/मास्क निर्दिष्ट करके काम करती है। आंतरिक रूप से, pedit सॉकेट-बफ़र्स (sk_buff) पर संचालित होता है और इसे संशोधित करने से पहले लक्षित पैकेट मेमोरी को राइटेबल बनाना होता है (skb_ensure_writable() के माध्यम से COW शैली में)। आदर्श रूप से, कर्नेल को लेखन से पहले किसी भी साझा पृष्ठ को क्लोन (निजी-प्रतिलिपि) करना चाहिए ताकि अन्यत्र उपयोग की जा रही मेमोरी को बदलने से बचा जा सके।
मूल कारण: tcf_pedit_act() में, कोड गलती से राइटेबल सीमा की गणना केवल एक बार आरंभ में करता है, tcfp_off_max_hint (अधिकतम स्थिर ऑफ़सेट) का उपयोग करके। यह संकेत किसी भी रनटाइम हेडर ऑफ़सेट को शामिल नहीं करता जो पैकेट संसाधित होने पर टाइप की गई कुंजियाँ जोड़ती हैं। TCP या UDP जैसी कुंजियाँ रनटाइम पर IP हेडर की स्थिति के आधार पर ऑफ़सेट की गणना कर सकती हैं (उदाहरण के लिए, यदि कोई पिछली कुंजी नेटवर्क हेडर को स्थानांतरित करती है)। इस प्रकार, प्रति-कुंजी लूप के दौरान, किसी कुंजी का वास्तविक ऑफ़सेट उस सीमा से अधिक हो सकता है जिसे राइटेबल के रूप में पूर्व-आवंटित किया गया था। फिर कोड skb_store_bits() के माध्यम से पैकेट मेमोरी में लिखता है, लेकिन चूँकि पूर्व-COW’d क्षेत्र से परे का पृष्ठ निजी नहीं बनाया गया था, यह लेखन एक ऐसे पृष्ठ को दूषित कर देता है जो अभी भी पेज कैश के साथ साझा है। संक्षेप में, “राइटेबल पैकेट सीमा की गणना बहुत जल्दी करना” एक आउट-ऑफ-बाउंड, क्रॉस-पेज लेखन का कारण बनता है। नकारात्मक ऑफ़सेट (जैसे इनग्रेस पर Ethernet हेडर संपादित करना) भी गलत तरीके से संभाले जाते हैं, और यहाँ तक कि offset_valid() में भी INT_MIN के लिए सुरक्षा का अभाव था, जिससे दोष और बढ़ गया।
ऐसा क्यों होता है: यह बग मूल रूप से कॉपी-ऑन-राइट सीमा गणना में एक तार्किक त्रुटि है। कर्नेल ने मान लिया कि स्थिर अधिकतम ऑफ़सेट (लोड समय पर ज्ञात) सभी संपादनों के लिए पर्याप्त था। जब गतिशील ऑफ़सेट वाली कुंजियाँ वास्तव में लागू की गईं, तो वह COW सीमा को अद्यतन करने में विफल रहा। कतारबद्ध संपादनों की एक श्रृंखला के बाद, अंतिम लेखन पूर्व-जाँच क्षेत्र के बाहर स्थित हो सकता है। चूँकि पैकेट बफ़र मेमोरी-मैप्ड फ़ाइल पृष्ठों को संदर्भित कर सकते हैं (उदाहरण के लिए ज़ीरो-कॉपी तंत्र के माध्यम से), यह “आंशिक COW” लेखन डिस्क पर किसी फ़ाइल के पेज कैश तक पहुँच सकता है। व्यवहार में, पैकेट संपादक क्रिया को sendfile या splice से पृष्ठ प्राप्त हो सकते हैं; इस प्रकार एक एकल पैकेट फ़िल्टर ऑपरेशन अप्रत्यक्ष रूप से हमलावर-चयनित डेटा को फ़ाइल की इन-मेमोरी छवि में लिख सकता है, बिना डिस्क को बदले।
घटक और डेटा प्रवाह: संवेदनशील कोड Linux net/sched सबसिस्टम (act_pedit.c) में स्थित है। जब कोई पैकेट कॉन्फ़िगर किए गए pedit नियम से मेल खाता है, तो tcf_pedit_act() आह्वान किया जाता है। आंतरिक रूप से यह skb_ensure_writable(skb, X) को ठीक एक बार कॉल करता है, जहाँ X = tcfp_off_max_hint है। यह पैकेट के पहले X बाइट्स को निजी (COW’d) बनाता है। फिर, प्रत्येक कुंजी (संपादन ऑपरेशन) पर एक लूप में, यह कुंजी के वास्तविक लेखन ऑफ़सेट की गणना रनटाइम हेडर ऑफ़सेट को कुंजी के निर्दिष्ट ऑफ़सेट में जोड़कर करता है, और पैकेट में एक 32-बिट मान लिखता है। स्यूडोकोड में:```c
u32 off_max = action->tcfp_off_max_hint;
skb_ensure_writable(skb, off_max);
for (i = 0; i < num_keys; i++) {
u32 hdr_off = compute_header_offset(skb, key[i].hdr_type);
u32 write_off = hdr_off + key[i].offset;
skb_store_bits(skb, write_off, &key[i].value, 4);
}
क्योंकि `hdr_off` की गणना केवल प्रत्येक key को संसाधित करते समय की जाती है, प्रारंभिक `skb_ensure_writable()` कॉल इसके लिए जिम्मेदार नहीं थी। यदि `hdr_off + key[i].offset` `off_max` से अधिक हो जाता है, तो कोड मुख्य रैखिक क्षेत्र के बजाय fragments पर `skb_store_bits()` पर वापस आ जाता है, जिसका अर्थ है कि यह एक ऐसे पृष्ठ में लिखता है जिसे private नहीं बनाया गया था। यही विफलता बिंदु है।
**आक्रमण सतह:** केवल आवश्यक इंटरफ़ेस **tc filter** है जिसमें `pedit` क्रिया होती है, जिसके लिए सामान्यतः **CAP_NET_ADMIN** क्षमता की आवश्यकता होती है। हालाँकि, सामान्य उपयोगकर्ता एक निजी नेटवर्क नेमस्पेस (user namespace cloning) के भीतर वास्तविक विशेषाधिकारों के बिना CAP_NET_ADMIN प्राप्त कर सकते हैं। इस प्रकार, एक अनविशेषाधिकार प्राप्त उपयोगकर्ता user+net नेमस्पेस में प्रवेश कर सकता है और loopback पर `tc pedit` नियम बना सकता है। लेखन तब होता है जब एक पैकेट संसाधित होता है (हमलावर आमतौर पर इसे ट्रिगर करने के लिए loopback पर ट्रैफ़िक उत्पन्न करता है)। विश्वास सीमा (user बनाम kernel) पार हो जाती है क्योंकि kernel ने अपने स्वयं के COW सेटअप पर भरोसा किया, लेकिन उपयोगकर्ता द्वारा प्रदान किए गए ऑफ़सेट ने उस धारणा को तोड़ दिया।
**आंतरिक तंत्र:** kernel पक्ष पर, यह भेद्यता **out-of-bounds write** (CWE-787) के रूप में प्रकट होती है। यह kernel मेमोरी को दूषित करती है जो उपयोगकर्ता स्थान (file page cache) में मैप की गई है। विशेष रूप से, यह किसी भी फ़ाइल पृष्ठ की सामग्री को अधिलेखित कर सकती है जो socket buffer में मैप हो जाती है। proof-of-concept में, `/bin/su` को socket buffer में भेजकर mmapped किया जाता है, इसलिए exploit मेमोरी में उसके entry point बाइट्स को बदल देता है। यह डिस्क पर मौजूद फ़ाइल को संशोधित नहीं करता, लेकिन उस बाइनरी का कोई भी बाद में निष्पादन कैश से poisoned छवि को पढ़ता है। ब्लॉग विश्लेषण नोट करता है:
> “क्योंकि skb sendfile के माध्यम से खींचे गए zero-copy पृष्ठों को संदर्भित कर सकता है, वह out-of-bounds write वास्तविक फ़ाइल का समर्थन करने वाली साझा page-cache मेमोरी में पहुँच सकता है। kernel का मानना है कि उसने पैकेट मेमोरी को संशोधित करने के लिए सुरक्षित बना दिया है; वास्तव में, बाद में लिखने की क्रिया उस क्षेत्र के बाहर पहुँचती है जिसे उसने वास्तव में निजी किया था।”
**विश्वास सीमाएँ:** kernel ने गलत तरीके से मान लिया कि `skb_ensure_writable()` (fast-path COW) बाद के सभी लेखनों के लिए सुरक्षा की गारंटी देगा। उसने प्रत्येक key के लिए पुनः जाँच नहीं की। उपयोगकर्ता केवल पैकेट फ़िल्टर कॉन्फ़िगरेशन और पैकेट सामग्री को नियंत्रित करता है; kernel ने इसे (नेटवर्क नेमस्पेस के माध्यम से) अनुमति दी। एक बार जब उस विश्वास का उल्लंघन हुआ, तो लेखन फ़ाइल-समर्थित मेमोरी में बच निकला जिसे संरक्षित किया जाना चाहिए था।
## मूल कारण विश्लेषण
मूल कारण **pedit क्रिया में गलत COW-रेंज गणना** है। कोड के संदर्भ में, एक एकल `skb_ensure_writable()` को `tcfp_off_max_hint` पर आधारित लंबाई के साथ बुलाया गया था, फिर लूप के अंदर वास्तविक ऑफ़सेट इससे अधिक हो सकते थे। एक छोटा पैच (मई 2026) इसे `skb_ensure_writable()` को *लूप के अंदर* ले जाकर, सही ऑफ़सेट ज्ञात होने के बाद, और नकारात्मक ऑफ़सेट के लिए जाँच और विशेष हैंडलिंग जोड़कर ठीक करता है। दूसरे शब्दों में:
- **दोषपूर्ण कोड:** ```c
skb_ensure_writable(skb, action->tcfp_off_max_hint);
for each key:
// compute offset (hdr_off + key_offset)
skb_store_bits(skb, write_off, ...);
No translatable content was provided in this chunk. The input section is empty (only contains "- Fixed code:" with no content following it). Please provide the actual Markdown text for chunk 5 of 19 so I can translate it from English to Hindi. ```c for each key: // compute offset (hdr_off + key_offset) skb_ensure_writable(skb, write_off + 3); skb_store_bits(skb, write_off, ...);
इसके अतिरिक्त, फिक्स यह सुनिश्चित करता है कि नेगेटिव ऑफ़सेट (Ethernet हेडर संपादन) के लिए यह हेडरूम पर `skb_cow()` का उपयोग करता है, और `INT_MIN` मामलों के विरुद्ध सुरक्षा करता है। कमिट संदेश (stack.watch सारांश) कहता है: *“Fix by moving skb_ensure_writable() inside the per-key loop where the actual write offset is known, and add overflow checking on the offset arithmetic.”*
इस प्रकार, **यह क्यों मौजूद है**: कोड समीक्षा या डिज़ाइन के दौरान, प्रति-कुंजी (per-key) पुनर्गणना को अनदेखा कर दिया गया था। स्टैटिक हिंट ऑप्टिमाइज़ेशन ने प्रति कुंजी पुनर्मूल्यांकन की आवश्यकता को दरकिनार कर दिया। यह एक दुर्भावनापूर्ण चूक के बजाय एक ईमानदार बग प्रतीत होता है, लेकिन इसका प्रभाव गंभीर है क्योंकि यह COW धारणा का उल्लंघन करता है। जैसा कि TuxCare नोट करता है, यह बग एक नियमित "डेटा भ्रष्टाचार" फिक्स के रूप में मर्ज किया गया था, बिना तत्काल सुरक्षा संदर्भ के।
## खोज प्रक्रिया
यह भेद्यता कर्नेल कमिट **8b796475fd78** (मई 2022) द्वारा पेश की गई थी और 2026 की शुरुआत तक अनजान बनी रही। सूत्रों के अनुसार, फिक्स (कमिट **899ee91156e5**, 31 मई 2026) को netdev मेलिंग सूची में एक सामान्य डेटा-भ्रष्टाचार पैच के रूप में प्रस्तुत किया गया था। कर्नेल अनुरक्षकों ने 4 जून 2026 को फिक्स (net-7.1-rc7) मर्ज किया। केवल 16 जून 2026 को CVE-2026-46331 को औपचारिक रूप से निर्दिष्ट किया गया (पैच सामने आने के लगभग दो सप्ताह बाद)। एक पूर्ण रूप से सशस्त्र सार्वजनिक एक्सप्लॉइट 17 जून 2026 को सामने आया (the *packet_edit_meme* PoC)।
व्यवहार में, अनुक्रम इस प्रकार था:
- **फिक्स प्रस्तुत (मेलिंग सूची):** 17 मई 2026 (Zhang Cen पैच)
- **फिक्स अपस्ट्रीम मर्ज:** 4 जून 2026 (net-7.1-rc7)
- **CVE निर्धारण:** 16 जून 2026 (CNA ने CVE-2026-46331 दर्ज किया)
- **सार्वजनिक PoC:** 17 जून 2026 (packet_edit_meme)
- **पैच रोलआउट:** जून 2026 के अंत में अधिकांश डिस्ट्रोस में (Red Hat, Debian, Ubuntu, आदि)
खुले पैच से कई पक्षों ने बग पर ध्यान दिया। उदाहरण के लिए, Massimiliano Oldani (साइबर सुरक्षा शोधकर्ता) ने कुछ ही समय बाद एक विस्तृत विवरण और एक्सप्लॉइट प्रकाशित किया, यह ध्यान देते हुए कि *“CVE निर्धारण के 24 घंटों के भीतर GitHub पर packet_edit_meme नामक एक सार्वजनिक, कार्यशील proof-of-concept एक्सप्लॉइट दिखाई दिया”*। CloudLinux, TuxCare, और SentinelOne ने PoC सार्वजनिक होने और CVE निर्दिष्ट होने के बाद विश्लेषण प्रकाशित किए। Debian सुरक्षा ट्रैकर और PT DBugs ने भी इस मुद्दे और उपलब्ध सलाहों का सारांश दिया (संदर्भ देखें)।
## हमले का परिदृश्य
एक यथार्थवादी हमले के लिए न्यूनतम पूर्व-शर्तें आवश्यक हैं:
- **हमलावर की क्षमताएँ:** लक्ष्य मशीन पर एक स्थानीय अन-प्रिविलेज्ड उपयोगकर्ता। उपयोगकर्ता को नेटवर्क नेमस्पेस के साथ एक नया उपयोगकर्ता नेमस्पेस बनाने में सक्षम होना चाहिए (`unshare(CLONE_NEWUSER|CLONE_NEWNET)` के माध्यम से), जो वास्तविक रूट विशेषाधिकारों के बिना उस नेमस्पेस के अंदर CAP_NET_ADMIN प्रदान करता है। अन-प्रिविलेज्ड उपयोगकर्ता नेमस्पेस कई कर्नेलों (जैसे RHEL, Debian) पर डिफ़ॉल्ट रूप से सक्षम होते हैं और Ubuntu पर `aa-exec` वर्कअराउंड के साथ पुनः सक्षम किए जा सकते हैं।
- **लक्ष्य की स्थितियाँ:** लक्ष्य एक भेद्य Linux कर्नेल (लगभग 5.18–7.1-rc6) चला रहा होना चाहिए जिसमें `act_pedit` मॉड्यूल उपलब्ध हो। यदि `act_pedit` बिल्ट-इन है या पहले से लोड है, तो यह तुरंत शोषणीय है। यदि यह एक मॉड्यूल है, तो `tc pedit` नियम कॉन्फ़िगर होने पर यह स्वतः लोड हो जाता है। लक्ष्य पर अपस्ट्रीम पैच लागू नहीं होना चाहिए। विशेष रूप से, हमलावर के लिए किसी भी फ़ाइल पर लिखने की पहुँच होना आवश्यक *नहीं* है; एक्सप्लॉइट पैकेट फ़िल्टर के माध्यम से लिखकर काम करता है।
- **हमले की श्रृंखला:**
1. **CAP_NET_ADMIN प्राप्त करें:** हमलावर एक नया उपयोगकर्ता+नेट नेमस्पेस बनाने के लिए `unshare --map-root-user --net --pid bash` जैसा कुछ चलाता है। यह उस नेमस्पेस में CAP_NET_ADMIN प्रदान करता है (उपयोगकर्ता अंदर रूट से मैप किया जाता है)।
2. **नेटवर्किंग सेट करें:** हमलावर लूपबैक इंटरफ़ेस को ऊपर लाता है (`ifconfig lo up`) और वैकल्पिक रूप से एक लिसनर स्पॉन करता है (जैसे `nc -l 127.0.0.1 9999`)। यह TC क्रियाओं के लिए उपयोग करने हेतु एक पैकेट प्रवाह प्रदान करता है।
3. **TC pedit क्रिया कॉन्फ़िगर करें:** `tc` कमांड या netlink का उपयोग करके, हमलावर `lo` पर एक qdisc और फ़िल्टर बनाता है जो सभी पैकेटों से मेल खाता है (जैसे `match u32 0 0`) और विशेष रूप से तैयार कुंजियों के साथ एक `pedit` क्रिया जोड़ता है। प्रत्येक कुंजी में एक डायनेमिक हेडर प्रकार (जैसे L4 ऑफ़सेट के लिए IP हेडर) और एक ऑफ़सेट होता है जिसे इस प्रकार चुना जाता है कि वास्तविक लेखन स्थिति (हेडर प्रारंभ + ऑफ़सेट) उस सीमा के ठीक बाहर हो जो `skb_ensure_writable()` कवर करता है।
4. **ट्रैफ़िक उत्पन्न करें:** हमलावर फ़िल्टर को ट्रिगर करने के लिए डेटा भेजता है (उदाहरण के लिए, `echo '' > /dev/udp/127.0.0.1/53` के माध्यम से)। कर्नेल `tcf_pedit_act()` को कॉल करता है, एक COW रेंज आवंटित करता है, फिर कुंजियों को पुनरावृत्त करता है। कम से कम एक कुंजी का लेखन पूर्व-COW’d क्षेत्र के बाहर पड़ता है, जिससे लेखन साझा pagecache में चला जाता है।
5. **पेज-कैश विषाक्तीकरण:** समानांतर में, हमलावर ने सॉकेट में एक लक्ष्य फ़ाइल (आमतौर पर एक setuid बाइनरी) खोली है। उदाहरण के लिए, प्रकाशित PoC `sendfile` या इसी तरह के माध्यम से `/bin/su` को सॉकेट में mmap करता है, जिससे पैकेट बफर उस फ़ाइल के पृष्ठों को संदर्भित करता है। फिर आउट-ऑफ-बाउंड लेखन `/bin/su` की मेमोरी में मौजूद प्रति को भ्रष्ट कर देता है (विशेष रूप से ELF एंट्री पॉइंट को)।
6. **विशेषाधिकार वृद्धि:** एक्सप्लॉइट अपना पेलोड लिखने के बाद, हमलावर (या मूल नेमस्पेस में पैरेंट प्रक्रिया) विषाक्त बाइनरी (`/bin/su`) को निष्पादित करता है। चूँकि कर्नेल ने अनजाने में शेलकोड इंजेक्ट किया है जो `setgid(0); setuid(0); execve("/bin/sh")` करता है, `su` चलाने से एक रूट शेल गिर जाता है। डिस्क पर फ़ाइल कभी परिवर्तित नहीं हुई थी, इसलिए कोई भी ऑन-डिस्क फ़ाइल अखंडता उपकरण परिवर्तन नहीं दिखाएगा।
**प्रभाव:** सफल होने पर, हमलावर को स्थानीय रूप से पूर्ण रूट विशेषाधिकार प्राप्त होते हैं। एक्सप्लॉइट एक ही कमांड में किया जा सकता है और यह नियतात्मक (deterministic) है। इसके अतिरिक्त, मनमानी फ़ाइल-समर्थित पृष्ठों का भ्रष्टाचार सेवा-अस्वीकार (सिस्टम क्रैश) का कारण बन सकता है यदि इसका भिन्न उपयोग किया जाए। प्रकाशित PoC ने विशेष रूप से `/bin/su` के एंट्रीपॉइंट को शेलकोड के साथ अधिलेखित किया, लेकिन कोई भी फ़ाइल जिसे हमलावर मैप कर सकता है, लक्षित की जा सकती है। श्रृंखला को किसी विशेष समय या रेस की आवश्यकता नहीं होती है और इसे कई डिस्ट्रोस (RHEL, Ubuntu, Debian, आदि) पर प्रदर्शित किया गया है।
## प्रूफ ऑफ कॉन्सेप्ट (PoC)
एक सार्वजनिक एक्सप्लॉइट, *packet_edit_meme*, GitHub (sgkdev/packet_edit_meme) पर उपलब्ध है और `/bin/su` को लक्षित करता है। हम विनाशकारी पेलोड के बिना इसके आवश्यक तर्क का वर्णन करते हैं:```c
/* Pseudocode outline of the exploit (simplified) */
int main() {
/* 1. Identify a setuid binary (su) and its ELF entry offset */
int fd = open("/bin/su", O_RDONLY);
long entry = elf_entry_offset(fd);
if (entry < 0) abort();
printf("Target %s (UID=%d), entry offset 0x%lx\n", "/bin/su", getuid(), entry);
/* 2. Unshare user+net namespace to get CAP_NET_ADMIN locally */
if (unshare(CLONE_NEWUSER | CLONE_NEWNET) < 0) abort();
/* Map UID/GID to root (handled via /proc/self/uid_map, /gid_map) */
// (omit details: write "0 <uid> 1" to /proc/self/uid_map and gid_map, and deny setgroups)
/* 3. Setup environment: bring up loopback and listener */
if (system("ip link set lo up") < 0) abort();
if (system("nc -l 127.0.0.1 9999 &") < 0) abort();
/* 4. Configure a tc pedit action via netlink (simplified) */
// Assume 'pedit_write' sends a packet-edit command to the kernel.
// The key offsets below are chosen such that they exceed the initial COW range.
char shellcode[/*size=48*/] = {
// (assembly for setgid(0); setuid(0); execve("/bin/sh").., padded to 36 or 48 bytes)
};
size_t total = sizeof(shellcode), sent = 0;
while (sent < total) {
int chunk = min(PEDIT_MAX_WRITE, total - sent);
/* Issue TC pedit action to write next chunk */
if (pedit_write(fd, entry + sent, &shellcode[sent], chunk) != 0) {
fprintf(stderr, "pedit_write failed\n");
exit(1);
}
sent += chunk;
}
/* 5. Trigger execution of su (in original namespace) */
execl("/bin/su", "su", NULL); // This will run the poisoned binary as root
return 0;
}
यह स्यूडोकोड प्रवाह को दर्शाता है: /bin/su खोलें, CAP_NET_ADMIN प्राप्त करने के लिए नेमस्पेस अनशेयर करें, लूपबैक और TC pedit नियम कॉन्फ़िगर करें, फिर लक्ष्य के पेज कैश को अधिलेखित करने के लिए pedit_write(fd, offset, data, len) फ़ंक्शन को कॉल करें (वास्तविक PoC में यह पर्दे के पीछे netlink कॉल का उपयोग करता है)। अंत में, बाइनरी निष्पादित की जाती है, जिससे रूट शेल उत्पन्न होता है।
वास्तविक PoC अधिक जटिल है (UID/GID मैप, नेटवर्क सुनना, और syscall-स्तरीय शेलकोड बाइट्स को संभालना), लेकिन मूल अवधारणा उपरोक्त के समान है। हम जोर देते हैं कि इस एक्सप्लॉइट को न चलाएं सिवाय एक सुरक्षित परीक्षण वातावरण के, और किसी वास्तविक सिस्टम को लक्षित न करें। उपरोक्त केवल प्रदर्शन हेतु है।
नोट: यदि कोई सार्वजनिक सुरक्षित-उपयोग PoC मौजूद नहीं होता, तो हम स्पष्ट रूप से ऐसा कहते। इस मामले में, PoC सार्वजनिक है, और हम इसे अवधारणात्मक रूप से वर्णित करते हैं। हमने संक्षिप्तता और सुरक्षा के लिए कच्चे शेलकोड बाइट्स और वास्तविक netlink विवरण को छोड़ दिया है।
प्रवेश बिंदु: हमलावर को पहले CAP_NET_ADMIN प्राप्त करना होगा। आमतौर पर, इसका अर्थ है एक अविशेषाधिकार प्राप्त प्रक्रिया से यूज़र+नेटवर्क नेमस्पेस (unshare) बनाना, जो नेमस्पेस-स्थानीय CAP_NET_ADMIN प्रदान करता है।
प्रारंभिक पहुँच: इस नेमस्पेस के भीतर, हमलावर ट्रैफ़िक कंट्रोल कॉन्फ़िगर करने के लिए सामान्य टूल (ip, tc) का उपयोग कर सकता है। कर्नेल का act_pedit कोड पथ अब पैकेटों के लिए पहुँच योग्य है।
ट्रिगर: हमलावर लूपबैक इंटरफ़ेस पर tc filter ... action pedit सेट करता है। यह फ़िल्टर पैकेटों से मेल खाता है (जैसे 0-मैच) और हेडर प्रकार (IP, TCP) और ऑफ़सेट के साथ एक या अधिक टाइप की गई कुंजियाँ निर्दिष्ट करता है। ऑफ़सेट इस प्रकार चुने जाते हैं कि कर्नेल लूप के अंदर हेडर बेस की गणना करने के बाद, अंतिम लेखन ऑफ़सेट प्रारंभिक COW सीमा से अधिक हो।
शोषण: जब फ़िल्टर से मेल खाता पैकेट संसाधित होता है, कर्नेल tcf_pedit_act() को कॉल करता है। यह एक अपर्याप्त skb_ensure_writable() करता है और फिर कुंजियों को पुनरावृत्त करता है। कम से कम एक कुंजी के लिए, लेखन उस पेज पर पहुँचता है जो निजी प्रति में क्लोन नहीं किया गया था। यह साझा पेज कैश में आउट-ऑफ-बाउंड लेखन का कारण बनता है। यदि सॉकेट बफर को किसी फ़ाइल के पेजों को संदर्भित करने के लिए तैयार किया गया था (sendfile/splice के माध्यम से), वह लेखन उन फ़ाइल पेजों को भ्रष्ट कर देता है।
शोषण के बाद: हमलावर का शेलकोड लक्ष्य बाइनरी के पेजकैश में लिखा जा चुका है (जैसे /bin/su)। हमलावर (मूल नेमस्पेस में) फिर निष्पादित करता है। कर्नेल मेमोरी में मौजूद इमेज (इंजेक्ट किए गए पेलोड के साथ) पढ़ता है और शेलकोड चलाता है, जिससे हमलावर को रूट शेल मिलता है। इस बिंदु पर, पूर्ण सिस्टम समझौता हो चुका होता है।
यह प्रवाह आरेखात्मक रूप से सारांशित है:```mermaid
flowchart LR
A[Attacker (unprivileged user)] --> B[Unshare into user+net namespace
(gains CAP_NET_ADMIN)]
B --> C[Configure TC pedit filter on lo]
C --> D{Packet processing by kernel}
D --> E[act_pedit computes wrong COW range]
E --> F[skb_store_bits writes beyond COW'd region]
F --> G[Page cache of target file is corrupted]
G --> H[Attacker executes poisoned setuid binary]
H --> I[Root shell obtained]
## समझौता संकेतक (IoCs)
- **अनपेक्षित पेज-कैश लेखन:** सिस्टम फ़ाइलें (विशेष रूप से एक्ज़ीक्यूटेबल) जो डिस्क पर बिना बदलाव के मेमोरी में परिवर्तन दिखाती हैं (जैसे हैशिंग टूल या इंटीग्रिटी मॉनिटर मेमोरी में बेमेल देखेंगे)।
- **मॉड्यूल लोड:** `act_pedit` मॉड्यूल उन सिस्टमों पर `lsmod` में अप्रत्याशित रूप से दिखाई देता है जो सामान्यतः tc pedit का उपयोग नहीं करते। (जैसे वेब सर्वरों पर `lsmod | grep act_pedit` का गैर-रिक्त होना।)
- **`tc` उपयोग:** असामान्य `tc` कमांड या अन-प्रिविलेज्ड प्रक्रियाओं से netlink संदेश। ऑडिटिंग लॉग में गैर-root प्रक्रिया को `CAP_NET_ADMIN` प्रदान किया गया दिख सकता है।
- **नेटवर्क लिसन:** लूपबैक पोर्ट पर एक लिसनर (क्योंकि exploit पैकेट प्रोसेसिंग को बाध्य करने के लिए एक सॉकेट बाइंड करता है)। उदाहरण के लिए, `netstat -tulnp` 127.0.0.1 पर `nc` या कस्टम लिसनर दिखाना एक संकेत हो सकता है।
- **कर्नेल लॉग:** Oops या चेतावनी जिसमें `tcf_pedit_act`, `skb_ensure_writable`, या लूपबैक पर भारी ट्रैफिक के दौरान सॉफ्ट लॉकअप या tc प्रोसेसिंग में त्रुटियाँ शामिल हों। (ये असामान्य होंगे और भ्रष्टाचार के संकेतक होंगे।)
- **छोड़े गए विशेषाधिकार लॉग:** Linux ऑडिट लॉग (`auditd`) जो प्रोग्रामों को userns के माध्यम से CAP_NET_ADMIN प्राप्त करते हुए या `/proc/[pid]/uid_map` में लिखते हुए दिखाते हैं।
उदाहरण के लिए, एक IOA **पेज कैश में दूषित फ़ाइलें** है: एक ट्राइएज चेकलिस्ट में मेमोरी में फ़ाइल सामग्री बनाम डिस्क को सत्यापित करना शामिल हो सकता है, विशेष रूप से भारी tc गतिविधि के बाद setuid बाइनरीज़ के लिए। दूसरा **नया नेमस्पेस निर्माण** है: `unshare(CLONE_NEWUSER|CLONE_NEWNET)` के कॉल की निगरानी को फ़्लैग किया जा सकता है। संक्षेप में, रक्षकों को *इनमें से किसी भी* पर नज़र रखनी चाहिए: `act_pedit` उपयोग, userns उपयोग, और RAM में एक्ज़ीक्यूटेबल्स के अचानक संशोधन।
## पहचान (Detection)
शोषण प्रयासों का पता लगाने के लिए:
- **SIEM/लॉग विश्लेषण:** `tc` कॉन्फ़िगरेशन या netlink संदेशों पर अलर्ट करें जो `act_pedit` फ़िल्टर जोड़ते हैं। उदाहरण के लिए, Sigma नियम `TCA_ACT_KIND: pedit` या समान वाली घटनाओं की तलाश कर सकते हैं। गैर-root प्रक्रियाओं से `capset CAP_NET_ADMIN` या `/proc/*/uid_map` में लिखने के लिए ऑडिट लॉग की निगरानी करें।
- **IDS/IPS:** विशिष्ट सिग्नेचर होने की संभावना कम है (स्थानीय शोषण के लिए कोई नेटवर्क सिग्नेचर नहीं), लेकिन ह्यूरिस्टिक्स: होस्ट इंटीग्रिटी अलर्ट के साथ समवर्ती रूप से लूपबैक पर अनपेक्षित TCP/UDP पैकेट वाला ट्रैफिक। यदि इंस्ट्रुमेंटेशन संभव हो तो विशिष्ट पैकेट संपादनों का पता लगाना संभव है।
- **EDR:** उन प्रक्रियाओं पर नज़र रखें जो `/bin/su` (या अन्य संवेदनशील बाइनरीज़) पढ़ रही हैं और नेमस्पेस/unshare syscalls के साथ तालमेल में अचानक उन्हें निष्पादित कर रही हैं। किसी भी प्रक्रिया पर अलर्ट करें जो setuid बाइनरी खोलती है और userns बनाती है।
- **WAF/नेटवर्क डिवाइस:** लागू नहीं (स्थानीय हमला)।
- **फ़ाइल इंटीग्रिटी मॉनिटरिंग:** महत्वपूर्ण बाइनरीज़ की मेमोरी में छवि की तुलना उनके डिस्क पर चेकसम से करें। यदि विसंगतियाँ होती हैं (और कोई अपडेट नहीं), तो अलर्ट ट्रिगर करें। (जैसा कि CloudLinux नोट करता है, समझौते के बाद कैश ड्रॉप करना केवल रोकथाम है; वास्तविक निवारण के लिए होस्ट के पुनर्निर्माण की आवश्यकता होती है।)
- **कर्नेल इंटीग्रिटी टूल्स:** यह सुनिश्चित करने के लिए Linux Security Modules या eBPF का उपयोग करें कि केवल कुछ प्रक्रियाएँ TC फ़िल्टर संलग्न कर सकें, या कि `skb_ensure_writable()` को धोखा नहीं दिया जा सके (हालाँकि कोई ज्ञात अंतर्निहित जाँच मौजूद नहीं है)।
संक्षेप में, रक्षकों को उपयोगकर्ता नेमस्पेस उपयोग, `tc` कमांड और मॉड्यूल लोड को लॉग और ऑडिट करना चाहिए। एक प्रमुख दृष्टिकोण: **अविश्वसनीय उपयोगकर्ताओं द्वारा `tc pedit` के किसी भी आह्वान को अस्वीकार या लॉग करें**। समझौता किए गए होस्ट पर, जाँच करें कि क्या `/etc/modprobe.d/disable-act_pedit.conf` लागू किया गया है (इसे पहले से लागू किया जाना चाहिए)।
## शमन (Mitigation)
**पैच लागू करें:** प्राथमिक समाधान कर्नेल अपडेट है। सभी प्रमुख डिस्ट्रीब्यूशन ने जून 2026 में अपडेट जारी किए हैं। पैच किए गए कर्नेल (Linux 7.1.0 या बाद का, या डिस्ट्रो बैकपोर्ट्स) में अपग्रेड करना निश्चित समाधान है।
**कॉन्फ़िगरेशन परिवर्तन:** यदि पैचिंग तुरंत संभव नहीं है, तो शमन लागू करें:
- **`act_pedit` अक्षम करें:** यदि आपके वर्कलोड को `tc pedit` की आवश्यकता नहीं है, तो मॉड्यूल को ब्लैकलिस्ट करें। उदाहरण के लिए: ```
echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.conf
lsmod | grep -w act_pedit && sudo rmmod act_pedit
यह सुनिश्चित करता है कि कार्रवाई लोड नहीं की जा सकती। (यह CloudLinux और TuxCare द्वारा अनुशंसित है।) उन होस्टों पर लागू न करें जो वैध रूप से tc pedit का उपयोग करते हैं।
Ubuntu 22.04+ पर: ``` sudo sysctl -w kernel.unprivileged_userns_clone=0 echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-pedit-cow.conf
यह गैर-विशेषाधिकार प्राप्त उपयोगकर्ताओं को CAP_NET_ADMIN प्राप्त करने के लिए आवश्यक user namespace बनाने से रोकता है। नोट: namespace अक्षम करने से rootless containers और कुछ sandboxed अनुप्रयोग काम करना बंद कर सकते हैं।
- **पेज कैश हटाएँ (रोकथाम):** यदि आपको संदेह है कि एक्सप्लॉइट निष्पादित हुआ, तो binaries की in-memory प्रतियाँ दूषित हो सकती हैं। उन्हें बाहर निकालने के लिए तुरंत कैश हटाएँ: ```
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"
यह पृष्ठों को डिस्क से पुनः लोड करने के लिए बाध्य करता है। सावधानी: यदि किसी हमलावर के पास पहले से ही रूट विशेषाधिकार हैं, तो कैश हटाने से उनके द्वारा स्थापित कोई भी स्थिरता (persistence) नहीं हटेगी। ऐसे होस्ट को समझौता किया हुआ मानें।
न्यूनतम विशेषाधिकार (Least Privilege): ऑडिट करें और प्रतिबंधित करें कि tc का उपयोग कौन कर सकता है। एक्सप्लॉइट को केवल CAP_NET_ADMIN की आवश्यकता है; सुनिश्चित करें कि केवल विश्वसनीय एडमिन के पास यह क्षमता हो। क्षमता अनुदान सीमित करने के लिए RBAC या कंटेनरीकरण का उपयोग करें।
नेटवर्क नियंत्रण: यद्यपि यह सीधे नेटवर्केबल नहीं है, सुनिश्चित करें कि लूपबैक उपयोग की निगरानी की जाए। 127.0.0.1 को फ़ायरवॉल करना अव्यावहारिक है, लेकिन सुनिश्चित करें कि TC संचालन के लिए केवल लोकलहोस्ट ट्रैफ़िक का उपयोग हो।
विक्रेता सलाह (Vendor Advisories): अपने OS के लिए आधिकारिक सलाह देखें। Red Hat के पास RHEL 8/9/10 के लिए RHSA-2026:27354 (और संबंधित) है, Debian के पास DSA-6355-1 है, Ubuntu का CVE पृष्ठ फिक्स्ड कर्नेल सूचीबद्ध करता है, आदि। (संदर्भ देखें।)
दीर्घकालिक उपचार में यह सुनिश्चित करना शामिल है कि सभी प्रभावित सिस्टम अपडेटेड कर्नेल पर चलें। फिक्स वाले कर्नेल पैकेज स्थापित किए जाने चाहिए और सिस्टम को रिबूट किया जाना चाहिए। उन कंटेनरों या सिस्टमों के लिए जो रिबूट नहीं कर सकते, लाइवपैच समाधानों (जैसे KernelCare) पर विचार करें, जिन्होंने पैच तैयार किए हैं।
इसके अलावा, सिस्टम डिज़ाइन को यह मान लेना चाहिए कि यूज़र-स्पेस से सुलभ कर्नेल इंटरफ़ेस समय के साथ बदल सकते हैं। CAP_NET_ADMIN को प्रतिबंधित करना और tc उपयोग को फ़िल्टर करना इस बग से परे भी अच्छे अभ्यास हैं।
यदि समझौता हुआ है, तो सिस्टम को फिर से बनाएँ। यह भेद्यता केवल पेज कैश को दूषित करती है, लेकिन रूट विशेषाधिकार वाला हमलावर अन्य दुर्भावनापूर्ण कार्य भी कर सकता है; फोरेंसिक सत्यापन आवश्यक है। एक्सप्लॉइट के बाद फ़ाइल-अखंडता स्कैन पर भरोसा न करें, क्योंकि जैसा कि उल्लेख किया गया है, PoC डिस्क पर मौजूद फ़ाइलों को अक्षुण्ण छोड़ देता है। रिबूट करना और पैच लगाना सुरक्षित उपचार मार्ग है।
इन कारकों को देखते हुए, एक विशिष्ट CVSS v3.1 वेक्टर है AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H, जिसका बेस स्कोर 6.0 (Medium) है। ध्यान दें कि CVSS यह नहीं दर्शाता कि यह भेद्यता रूट तक विशेषाधिकार वृद्धि प्रदान करती है, जो व्यवहार में गंभीर है। (कुछ स्रोतों ने समान बग के लिए CVSSv4 की गणना की है; उदाहरण के लिए, PT DBugs CVSSv4 पर 8.5 सूचीबद्ध करता है।)
गंभीरता को अक्सर विक्रेताओं द्वारा Important/Critical के रूप में दर किया जाता है। इस CVE के लिए Red Hat की सलाह इसे Important लेबल करती है, और AWS इसे Medium (CVSS 6.0) चिह्नित करता है। किसी भी स्थिति में, क्योंकि रूट प्राप्त होता है, व्यावहारिक जोखिम बहु-उपयोगकर्ता या साझा सिस्टम पर सबसे अधिक होता है।
यह भेद्यता पेज-कैश विषाक्तता (page-cache poisoning) बग के परिवार से संबंधित है। अन्य उल्लेखनीय CVE में शामिल हैं:
splice() COW सीमाओं से परे पेज कैश में लिख सकता था। यह फ़ाइलों को मेमोरी में (डिस्क परिवर्तन के बिना) अधिलेखित करने की भी अनुमति देता था।/proc/self/mem कॉपी-ऑन-राइट में एक पुरानी खामी, जो केवल-पढ़ने के मैपिंग में स्थानीय लेखन की अनुमति देती थी।इनमें से प्रत्येक में कर्नेल फास्ट-पाथ ऐसी मेमोरी में लिखता है जिसे वह विशेष रूप से अपना मानता था, परंतु वह वास्तव में उसकी नहीं थी। CVE-2026-46331 इस मायने में अद्वितीय है कि यह net/sched pedit action में होता है और विशेषाधिकार प्रतिबंधों को बायपास करने के लिए यूज़र नेमस्पेस का लाभ उठाता है। DirtyPipe या Dirty COW के विपरीत, किसी सहायक विशेषाधिकार प्राप्त प्रक्रिया (जैसे दुर्व्यवहार करने वाला सिस्टम) की आवश्यकता नहीं होती – एक अकेला सामान्य (unprivileged) उपयोगकर्ता इसे ट्रिगर कर सकता है।
सभी संदर्भ प्रतिष्ठित स्रोतों से हैं (विक्रेता सलाह, प्रकाशित विश्लेषण, CVE/NVD प्रविष्टियाँ)।
act_pedit में, लिखने की क्षमता की गणना बहुत जल्दी करने से पेज-कैश भ्रष्टाचार संभव हुआ।/bin/suप्रभाव: हमलावर को रूट विशेषाधिकार प्राप्त होते हैं। गोपनीय डेटा अधिलेखित किया जा सकता है लेकिन सीधे लीक नहीं होता। अखंडता पूरी तरह से टूट जाती है (हमलावर किसी भी फ़ाइल की मेमोरी इमेज बदल सकता है)। उपलब्धता भी प्रभावित हो सकती है (महत्वपूर्ण पेजों को गलत लिखने से प्रक्रियाएँ या सिस्टम क्रैश हो सकते हैं)। CVSS मेट्रिक्स: समग्र रूप से मध्यम (CVSS 3.1=6.0), लेकिन वास्तविक प्रभाव गंभीर स्थानीय रूट है।