CVE-2026-43499 (GhostLock) — HUAWEI MatePad Pro 11 GOT-W29 अनुसंधान

HUAWEI MatePad Pro 11 GOT-W29 (Qualcomm kona / Snapdragon 870, HarmonyOS 4.x, kernel 4.19.157-perf+) पर CVE-2026-43499 (Linux rtmutex/futex-PI UAF, "GhostLock") विशेषाधिकार वृद्धि का अनुसंधान रिकॉर्ड।

डिवाइस

भेद्यता

CVE-2026-43499: kernel/locking/rtmutex.c का remove_waiter() rt_mutex_start_proxy_lock() रोलबैक पथ में waiter->task के बजाय current से सफ़ाई करता है, जिससे हैंगिंग pi_blocked_on (स्टैक UAF) उत्पन्न होता है। प्रभावित: 2.6.39 ~ 7.1 (यह कर्नेल प्रभावित दायरे में है)। अपस्ट्रीम फिक्स: commit 3bfdc63936dd।

इस डिवाइस पर पुष्टि: सोर्स कोड rtmutex.c:1110-1112, डीकंपाइल किया गया boot.elf, और वास्तविक डिवाइस पर ट्रिगर — सभी सत्यापित।

सत्यापित उपलब्धियाँ (डिवाइस पर वास्तविक परीक्षण)

1. KASLR लीक — perf_event_open के माध्यम से ✅

shell (uid 2000) के अंतर्गत perf_event_paranoid=-1, perf_event_open(PERF_SAMPLE_IP, exclude_user=1) कर्नेल टेक्स्ट एड्रेस क्लस्टर का सैंपल लेता है; ज्ञात सिंबल ऑफ़सेट से संरेखित करके slide प्राप्त होती है।

samples=27651 kernel_ips=1685 lo=0xffffff948728176c hi=0xffffff9488ebfc7c
KASLR slide=0x147f200000    (40/40 IP 映射进内核文本区验证)
runtime _stext=0xffffff9487280800

टूल: tools/perf_kaslr.c। चलाने की शर्तें: shell (Shizuku rish), बिना seccomp इंटरसेप्ट के।

2. EDEADLK ट्रिगर ✅

PI चक्र बनाकर FUTEX_CMP_REQUEUE_PI से -EDEADLK लौटवाया जाता है, रोलबैक remove_waiter बग को ट्रिगर करता है।

मुख्य व्यवस्था: requeue लक्ष्य futex को requeue किया जा रहा waiter पकड़े हुए है (futex2 = waiter_tid) → task_blocks_on_rt_mutex में owner == task → -EDEADLK।

[M] CMP_REQUEUE_PI ret=-1 errno=35 (EDEADLK!)
[W] WAIT_REQUEUE_PI ret=-1 errno=110 (ETIMEDOUT)  ← waiter 返回
[M] waiter_returned=1                              ← 留下悬空 pi_blocked_on

टूल: tools/edeadlk_probe.c (variant 8+2+1 = 11, या 27)।

3. राइट प्रिमिटिव तंत्र (समझा गया)

rt_mutex_adjust_prio_chain step[7] fake waiter पर rb_erase (सिंगल लेफ्ट-चाइल्ड पथ) करता है: *(tree_left) = tree_pc (value→target) + __rb_change_child इंक्रीमेंटल राइट। target.h में सभी ऑफ़सेट boot.elf डिसअसेंबली से मापे गए हैं।

4. पूर्ण ऑफ़सेट (target/)

देखें target/got_w29_target.h। मुख्य बिंदु:

• task_struct: cred=0x988, prio=0x184, pi_blocked_on=0xa90, usage=0x68, mm=0x728
• rt_mutex_waiter (HW_FUTEX_PI): tree@0x0, pi_tree@0x18, task@0x30, lock@0x38, major@0x40, prio@0x48, deadline@0x50
• PAGE_OFFSET=0xffffffc000000000, PHYS_OFFSET=0x80000000 (kona), KIMAGE_TEXT_BASE=0xffffff8008080000

ब्लॉकर्स और फिक्स (2026-08-10 अपडेट)

असली मूल कारण: EDEADLK ट्रिगर गलत सबपाथ से जाता है (overlay से पहले)

boot.elf डिसअसेंबली task_blocks_on_rt_mutex की पुष्टि करती है: इस डिवाइस के कर्नेल में 0x3808-0x3868 पर समय से पहले owner==task जाँच है (cmp owner,task; b.eq -> -EDEADLK), जो task->pi_blocked_on लिखे जाने (0x38d4 str x21,[x20,#0xa90]) से पहले रिटर्न करती है। GOT-W29 का पुराना ट्रिगर waiter को futex2=waiter_tid (self-own) स्वयं पकड़ने देता है → ठीक उस समय से पहले जाँच पर हिट होता है → pi_blocked_on कभी सेट नहीं होता → कोई हैंगिंग पॉइंटर नहीं। डिवाइस पर अवलोकन (कोई क्रैश नहीं + boot_id अपरिवर्तित) पूरी तरह से "कोई हैंगिंग नहीं" के अनुरूप है — overlay प्लेसमेंट गलत निदान था।

सही ट्रिगर (smt878u संदर्भ, लागू किया जा चुका): PI चक्र — owner FUTEX_LOCK_PI(target) से requeue लक्ष्य पकड़ता है; waiter chain futex पकड़ता है; owner फिर chain पर ब्लॉक होता है (चक्र: waiter→target→owner→chain→waiter)। requeue के समय श्रृंखला चलने पर rt_mutex_owner(chain)==top_task जाँच होती है (rtmutex step[6]) → -EDEADLK → रोलबैक में remove_waiter requeuer के current से गलत व्यक्ति को साफ़ करता है → waiter का pi_blocked_on हैंगिंग रह जाता है। owner को प्रायोरिटी घटानी होगी (nice=10) ताकि boost के बाद prio, owner_waiter->prio से भिन्न हो, अन्यथा rt_mutex_waiter_equal समय से पहले बाहर निकल जाता है।

Overlay फिक्स (लागू किया गया)

shift=12 पर fake waiter के words 6-7 (task/lock) res_in[3..4] (कर्नेल-द्वारा-शून्य क्षेत्र) में पड़ते हैं। do_select सेमेंटिक्स का उपयोग: res_in[i] = in[i] & POLLIN-ready। SLIDE_INIT_TASK / fake_lock को in[3]/in[4] में लिखें, और संबंधित fd को सभी "डेटा-युक्त pipe रीड एंड" पर dup2 करें (हमेशा EPOLLIN-ready) → res_in[3]=init_task, res_in[4]=fake_lock सटीक रूप से एन्कोड होते हैं। words 3-5 (pi_tree) और 8-10 शून्य हो सकते हैं (ownerless-lock पथ pi_tree का उपयोग नहीं करता; prio/deadline कर्नेल द्वारा step[7] में अधिलेखित किए जाते हैं)। pselect ready fd के कारण तुरंत रिटर्न करता है → waiter यूज़र-स्पेस बिज़ी-वेट करता है (सिग्नल निषेध, शून्य syscall — ताकि कर्नेल स्टैक पुन: उपयोग fake waiter को मिटा न सके) जब तक consumer ट्रिगर पूरा न कर ले। 11-word HW_FUTEX_PI टेबल, दोहरी fd क्लास, पैरेंट प्रोसेस वेट टाइमआउट — सभी लागू किए जा चुके हैं (git diff)।

शेष गौण समस्याएँ (डिज़ाइन agent द्वारा चिह्नित, overlay को ब्लॉक नहीं करतीं)

• boot_id लीक मान स्थिर direct-map उपनाम है (*(boot_id)=DM(loggers[0][1])), stext=leaked-p0_alias_image_offset(NFULNL_LOGGER) का DM(_stext) से off-by है; root चरण में यदि पूरी तरह physmap (DM स्पेस) से जाएँ तो आत्म-संगत है, अन्यथा perf_event_open के रनटाइम slide का उपयोग करना होगा (rish के अंतर्गत उपलब्ध)।
• राइट आकृति: smt878u pi_tree (dequeue_pi) से जाता है, GOT-W29 ownerless पथ केवल tree (rt_mutex_dequeue) का उपयोग करता है — इस फिक्स में tree आकृति का उपयोग किया गया है (tree_pc=LOGGERS, tree_left=BOOT_ID)।

वास्तविक डिवाइस सत्यापन (rish आवश्यक)

1. tools/cycle_probe (कंपाइल किया हुआ): सस्ता सत्यापन कि cycle EDEADLK ट्रिगर करता है; EDEADLK के बाद waiter पर sched_setattr यदि consumer oops ट्रिगर करे = हैंगिंग मौजूद है + overlay लैंड हुआ।
2. पूर्ण exploit: build_tools/deploy_test.sh से डिप्लॉय करें, slide-kaslr-ok या consumer oops देखें।
3. गौण ब्लॉकर: लीक अंकगणित को perf slide से कैलिब्रेट करें।

निर्देशिका

tools/      验证工具（perf KASLR, EDEADLK 探针, overlay 测试, kaslr.json）
target/     全部实测偏移
exploit/    移植的 slide.c（含 EDEADLK 触发改动）

आभार

• अपस्ट्रीम PoC: x-spy/CVE-2026-43499-popsicle, soralis0912/CVE-2026-43499-aristotle, JoinChang/ghostlock-oneplus, Wtrwx/smt878u-ionstack-poc (GPL-3.0)
• CVE: NVD, Red Hat RHSB-2026-010