Skip to content
KitploitKITPLOIT
उपकरणब्लॉग
जमा करें
उपकरणब्लॉग
जमा करें

हैकिंग, पेनटेस्ट और साइबर सुरक्षा उपकरण आपके सुरक्षा शस्त्रागार के लिए!

Kitploit हैकिंग, साइबर सुरक्षा और पेंटेस्टिंग टूल्स की एक निर्देशिका है। कमजोरियों को खोजने, सिस्टम का विश्लेषण करने, परीक्षण को स्वचालित करने और अपनी सुरक्षा को मजबूत करने के लिए नवीनतम प्रोजेक्ट अपडेट खोजें।

··फ़ीड·संपर्क·गोपनीयता·© 2026 Kitploit

टूल निर्देशिका

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
CVE-2025-38352-PoC — CVE-2025-38352 को ट्रिगर करने में सहायक PoC और GDB स्क्रिप्ट | Kitploit
उपकरण/GitHubGitHub/longwasu/cve-2025-38352-poc
मेमोरी फोरेंसिकभेद्यता विश्लेषणशोषणरिवर्स इंजीनियरिंगडीबगर्सपेपर और शोधलर्निंग और शिक्षाबाइनरी शोषण
GitHublongwasu/cve-2025-38352-poc

CVE-2025-38352-PoC

CVE-2025-38352 को ट्रिगर करने में सहायक PoC और GDB स्क्रिप्ट

रिपॉजिटरी देखें
7घं 4मि पहलेअभी तक समीक्षित नहीं

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →
साझा करें

CVE-2025-38352: Linux Kernel POSIX CPU Timer TOCTOU रेस कंडीशन और UAF

CVE-2025-38352 के लिए एक पुनरुत्पादनीय Proof-of-Concept (PoC) और स्वचालित GDB ऑर्केस्ट्रेशन स्क्रिप्ट, जो Linux kernel के POSIX CPU timer सबसिस्टम (kernel/time/posix-cpu-timers.c) में एक Time-of-Check to Time-of-Use (TOCTOU) रेस कंडीशन है जो Use-After-Free (UAF) की ओर ले जाती है।

अस्वीकरण: यह प्रोजेक्ट केवल शैक्षिक, रक्षात्मक और सुरक्षा अनुसंधान उद्देश्यों के लिए है। सभी परीक्षण और पुनरुत्पादन एक पृथक ARM64 QEMU वर्चुअल मशीन में किए गए थे।


🧠 बग कैसे काम करता है

  1. प्रोसेस A चाइल्ड प्रोसेस B बनाता है।

  2. प्रोसेस B एक CPU timer बनाता है और बाहर निकलना शुरू करता है, ज़ॉम्बी स्थिति में प्रवेश करता है। जैसे ही B बाहर निकल रहा होता है, उसके CPU कोर पर एक timer interrupt आता है। kernel timer को प्रोसेस करने के लिए interrupt context में प्रवेश करता है, लेकिन डेडलॉक से बचने के लिए अस्थायी रूप से अपना लॉक (unlock_task_sighand) छोड़ देता है।

  3. ठीक उसी समय दूसरे कोर पर, प्रोसेस A बाहर निकल रहे B को reap करता है, उसके signal handler (sighand = NULL) को साफ़ करता है और उसके PID को unhashing करता है।

  4. B में एक अन्य थ्रेड timer delete (posix_cpu_timer_del) को कॉल करता है। यह अपने PID के माध्यम से टास्क को खोजने और उसके signal handler की जाँच करने का प्रयास करता है, लेकिन उन्हें पहले से ही साफ़ किया हुआ / NULL पाता है। यह गलत समझते हुए कि टास्क पूरी तरह से मृत है और कोई timer संभवतः फायर नहीं हो सकता, यह मान लेता है कि यह सुरक्षित है और timer को मेमोरी से मुक्त कर देता है।

  5. इस बीच, पहले कोर पर timer interrupt handler समाप्त हुए timer को फायर करने के लिए फिर से शुरू होता है। चूँकि timer अभी Step 4 में मुक्त किया गया था, उस तक पहुँचने से Use-After-Free होता है और kernel क्रैश हो जाता है।


🔬 सिंक्रोनाइज़ेशन रणनीति (poc_gdb_script.py)

चूँकि QEMU का GDB stub set non-stop on का समर्थन नहीं करता (एक vCPU को रोकने से सभी vCPUs रुक जाते हैं), सामान्य मल्टी-थ्रेडेड सिंक्रोनाइज़ेशन सादे breakpoints के माध्यम से प्राप्त नहीं किया जा सकता।

यह रिपॉज़िटरी In-Memory Instruction Patching के माध्यम से समस्या का समाधान करती है:

  1. Stage 1 (CPU Barrier):

    • 4 महत्वपूर्ण kernel फ़ंक्शनों पर breakpoints रखे जाते हैं:
      • exit_notify (CPU 2)
      • kernel_wait4 (CPU 0)
      • __arm64_sys_timer_delete (CPU 1)
      • handle_posix_cpu_timers (CPU 2)
    • जैसे ही प्रत्येक vCPU अपने rendezvous point पर पहुँचता है, GDB उसके $pc को ARM64 self-branch opcode 0x14000000 (b . infinite loop) से patch करता है और निष्पादन फिर से शुरू करता है।
    • एक बार जब सभी 4 vCPUs अपने सटीक स्थानों पर pinned हो जाते हैं, GDB मूल निर्देशों को पुनर्स्थापित करता है और निष्पादन Stage 2 को सौंप देता है।
  2. Stage 2 (Sequential Orchestration):

    • GDB scheduler को लॉक करता है (set scheduler-locking on) और प्रत्येक vCPU को क्रमिक रूप से आगे बढ़ाता है:
      • Step 1 (CPU 2): handle_posix_cpu_timers को unlock_task_sighand() से आगे बढ़ाएँ।

🚀 पुनरुत्पादन कैसे करें

1. लक्ष्य Kernel स्रोत डाउनलोड करें

commit 1bf1aa362e6b9573a310fcd14f35bc875b42ba83 पर Android Common Kernel स्रोत ट्री डाउनलोड या क्लोन करें:

root@kitploit:~
# Option A: Download tarball directly
curl -LO https://android.googlesource.com/kernel/common/+archive/1bf1aa362e6b9573a310fcd14f35bc875b42ba83.tar.gz
mkdir -p kernel-cve && tar -xzf 1bf1aa362e6b9573a310fcd14f35bc875b42ba83.tar.gz -C kernel-cve
cd kernel-cve

# Option B: Clone repository
git clone https://android.googlesource.com/kernel/common
cd common
git checkout 1bf1aa362e6b9573a310fcd14f35bc875b42ba83

2. run_posix_cpu_timers() में पैच को revert करें

kernel/time/posix-cpu-timers.c खोलें, फ़ंक्शन run_posix_cpu_timers() (लगभग पंक्ति 1435–1448) का पता लगाएँ, और पैच पंक्तियों को comment out करें:

root@kitploit:~
void run_posix_cpu_timers(void)
{
    struct task_struct *tsk = current;

    lockdep_assert_irqs_disabled();

    /*
     * Ensure that release_task(tsk) can't happen while
     * handle_posix_cpu_timers() is running. Otherwise, a concurrent
     * posix_cpu_timer_del() may fail to lock_task_sighand(tsk) and
     * miss timer->it.cpu.firing != 0.
     */
//  if (tsk->exit_state)
//      return;

3. CONFIG_POSIX_CPU_TIMERS_TASK_WORK को अक्षम करें

नोट: जब CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y होता है, तो CPU timers timer IRQ के बजाय task_work context से निष्पादित होते हैं, जिससे यह रेस कंडीशन बायपास हो जाती है। इसलिए, भेद्यता को पुनरुत्पादित करने के लिए इसे अक्षम किया जाना चाहिए।

चूँकि upstream Kconfig में CONFIG_POSIX_CPU_TIMERS_TASK_WORK में prompt string नहीं है, यह डिफ़ॉल्ट रूप से y होता है और menuconfig में सीधे toggle नहीं किया जा सकता। आप इसे निम्नानुसार उजागर कर सकते हैं:

  1. kernel/time/Kconfig में (लगभग पंक्ति 56), एक prompt string जोड़ें और default बदलें:
    root@kitploit:~
    config POSIX_CPU_TIMERS_TASK_WORK
        bool "POSIX CPU timers task work"
        default n
    
  2. default config जनरेट करें और विकल्प को अक्षम करें:
    root@kitploit:~
    ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make defconfig
    scripts/config --disable POSIX_CPU_TIMERS_TASK_WORK
    ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make olddefconfig
    
  3. सत्यापित करें कि यह .config में अक्षम है:
    root@kitploit:~
    grep POSIX_CPU_TIMERS_TASK_WORK .config
    # Expected output: # CONFIG_POSIX_CPU_TIMERS_TASK_WORK is not set
    

4. Kernel बनाएँ

ARM64 kernel image संकलित करें:

root@kitploit:~
time ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make -j$(nproc) Image

5. Userspace PoC संकलित करें

poc.c को cross-compile करें:

root@kitploit:~
aarch64-linux-gnu-gcc -ggdb3 ./poc.c -o poc

6. GDB Stub के साथ QEMU प्रारंभ करें

अपनी QEMU वर्चुअल मशीन को 4 vCPUs (-smp 4) के साथ लॉन्च करें और GDB stub सक्षम करें (-s flag, port 1234):

root@kitploit:~
qemu-system-aarch64 \
    -M virt \
    -cpu cortex-a57 \
    -smp 4 \
    -m 2G \
    -kernel arch/arm64/boot/Image \
    -append "console=ttyAMA0 root=/dev/vda oops=panic panic_on_warn=1" \
    ... \
    -s

7. GDB अटैच करें और स्क्रिप्ट चलाएँ

अपने host terminal से, GDB को QEMU से अटैच करें और orchestration स्क्रिप्ट लोड करें:

root@kitploit:~
gdb-multiarch vmlinux
pwndbg> target remote :1234
pwndbg> source poc_gdb_script.py
pwndbg> continue

8. भेद्यता को ट्रिगर करें

QEMU guest shell के अंदर, संकलित बाइनरी चलाएँ:

root@kitploit:~
./poc

[!TIP] Timing और Troubleshooting:
यदि लक्ष्य थ्रेड के ज़ॉम्बी स्थिति में पहुँचने से पहले timer समय से पहले फायर हो जाता है, तो GDB लॉग करेगा:

root@kitploit:~
[!] ERROR: handle_posix_cpu_timers fired before exit_state == EXIT_ZOMBIE
  • विकल्प 1: बस ./poc को फिर से चलाएँ और GDB स्क्रिप्ट को कुछ बार source करें।
  • विकल्प 2: poc.c में TIMER_FIRE_MS बढ़ाएँ (उदाहरण के लिए, #define TIMER_FIRE_MS 10 से 20 तक), poc.c को पुनः संकलित करें, और फिर से चलाएँ। यह थ्रेड को timer समाप्त होने से पहले exit_notify() तक पहुँचने और EXIT_ZOMBIE में संक्रमण करने के लिए अतिरिक्त समय देता है।

9. डेमो

https://github.com/user-attachments/assets/11481b5c-25f8-46c3-be3a-7b79a06a4948


📚 संदर्भ

  • Race Against Time in the Kernel Clockwork StreyPaws द्वारा
  • CVE-2025-38352 Root Cause Analysis Faith द्वारा
टूल डाउनलोड करें
  • Step 2 (CPU 0): kernel_wait4 को tsk->sighand = NULL से आगे बढ़ाएँ।
  • Step 3 (CPU 1): timer_delete को release_posix_timer() (जो sigq को मुक्त करता है) कॉल करने के लिए आगे बढ़ाएँ।
  • Step 4 (CPU 2): scheduler locking जारी करें ताकि CPU 2 मुक्त किए गए timer को फायर कर सके $\rightarrow$ क्रैश!