CVE-2026-64560 — टूलचेन + बहु-लक्ष्य पोर्टिंग

CVE-2026-64560 Linux कर्नेल posix-cpu-timers का use-after-free है (स्थानीय अनप्रिविलेज्ड रेस, CVSS 3.1 = 7.8; 6.6.118 में अप्रचारित, 6.6.147 में ही ठीक हुआ)। इस रिपॉज़िटरी में दो चीज़ें हैं: अपस्ट्रीम की उस टूलचेन को, जिसे केवल ढेरों Python स्क्रिप्ट से चलाया जा सकता था, एकल स्टैटिक Go बाइनरी बनाना, और अपस्ट्रीम में न मौजूद realme RMX5010 (A16 / SM8750) लक्ष्य को जोड़ना।

[!WARNING] यह प्रायोगिक कर्नेल exploit कोड है। यह डिवाइस को रीबूट कर सकता है, कर्नेल स्थिति को बिगाड़ सकता है या डेटा हानि कर सकता है। इसका उपयोग केवल उन डिवाइस पर करें जो आपके स्वामित्व में हैं या जिनके लिए आपको स्पष्ट अनुमति है। पहले बैकअप लें।

लक्ष्य

तैयार आर्टिफ़ैक्ट सीधे लें

Go इंस्टॉल करने की ज़रूरत नहीं, Python इंस्टॉल करने की ज़रूरत नहीं:

• Release: v* टैग लगाने पर स्वतः प्रकाशित, जिसमें हर प्लेटफ़ॉर्म के टूल + हर लक्ष्य के पेलोड + SHA256SUMS.txt शामिल
• Actions artifacts: main पर हर push पर बनते हैं
  • cve64560-<os>-<arch>: linux/amd64, linux/arm64, android/arm64, darwin/arm64, windows/amd64
  • payloads: हर profile के aarch64 स्टैटिक पेलोड (rmx5010-a16-…, op13-…, हर एक अपनी अलग डायरेक्टरी में लिखता है, अब एक-दूसरे को ओवरराइट नहीं करते)

android/arm64 वाला सीधे adb push करके /data/local/tmp में फ़ोन पर चलाया जा सकता है।

खुद बिल्ड करें

go build -o cve64560 ./gotool                 # टूल (शुद्ध Go, कोई निर्भरता नहीं)
./cve64560 build --profile profiles/rmx5010/rmx5010-40850e5ff6a5.json   # पेलोड (cc चाहिए)

कमांड लाइन की पूरी सूची, --dry-run खाली रन, profile कैसे निकाला जाता है, देखें docs/GOTOOL.md।

टूलचेन Go में क्यों है

पुरानी प्रक्रिया के लिए python3 + tools/*.py + ढेरों shell चाहिए था: टेस्ट मशीन पर python नहीं है, फ़ोन पर तो और भी असंभव। अब एक स्टैटिक बाइनरी पूरे kallsyms → derive → render → patch → build → campaign फ़्लो को कवर करती है, क्रॉस-कंपाइल करके कहीं भी चलाई जा सकती है।

Python कार्यान्वयन हटाया नहीं गया है: यह tools/ में संदर्भ कार्यान्वयन और CI क्रॉस-चेक बेसलाइन के रूप में रहता है, CI हर profile के लिए Go और Python दोनों चलाता है फिर diff -r करता है, बाइट-दर-बाइट मेल न खाने पर लाल हो जाता है।

CI क्या करता है (.github/workflows/build.yml)

डायरेक्टरी

gotool/           Go टूलचेन (एक कमांड एक फ़ाइल)
profiles/         लक्ष्य profile (हर लक्ष्य के लिए एक JSON, रेंडरिंग का एकमात्र स्रोत)
src/              अपस्ट्रीम टेम्पलेट + रेंडर किया गया डिवाइस सोर्स
tools/            अपस्ट्रीम Python संदर्भ कार्यान्वयन + musl/bionic संगतता परत + CI स्क्रिप्ट
scripts/          अपस्ट्रीम के कैंपेन/मापन स्क्रिप्ट (Go संस्करण देखें gotool/cmd_campaign.go)
targets/          हर लक्ष्य के कर्नेल सिंबल/ऑफ़सेट रिकॉर्ड
symbols/          दो शिपिंग profile की कर्नेल सिंबल तालिकाएँ (बाकी लक्ष्यों की व्युत्पन्न डेटा हैं)
docs/GOTOOL.md    Go टूलचेन दस्तावेज़

सुरक्षा सीमाएँ

रिपॉज़िटरी में फ़र्मवेयर इमेज, डिवाइस कुंजियाँ या डिवाइस विशिष्ट पहचानकर्ता शामिल नहीं हैं। जिन चरणों को दोहराने के लिए विक्रेता कर्नेल इमेज चाहिए (सिंबल निकालना, profile पुश करना) उनके मूल इमेज साथ हैं, रिपॉज़िटरी में नहीं जाते।

एकमात्र अपवाद उन दो शिपिंग profile की कर्नेल सिंबल तालिकाएँ हैं (symbols/symbols_*.json, प्रत्येक लगभग 9 MB): build को तालिका न मिले तो सीधे विफल हो जाता है (ऐसा पेलोड नहीं बनाता जिसके कॉन्स्टेंट सत्यापित न हों), और CI के पास कर्नेल Image नहीं है, तालिका दोबारा नहीं बना सकता। इनमें केवल सिंबल नाम और पते हैं, इमेज स्वयं नहीं।

पेलोड अस्थायी root है: रीबूट पर अमान्य हो जाता है, डिस्क पर नहीं लिखता, पार्टीशन नहीं बदलता।