CVE-2026-43499 Failure Log: MT6985 Adaptation Attempt

Conclusion: Spent 68M tokens, no root obtained.
Reason: KernelSnitch timing attack is unreliable on MTK Dimensity 9200, and CONFIG_PANIC_ON_OOPS=y leaves no room for trial and error.
This article documents the complete troubleshooting process for future reference.

---

Background

Item	Value
Device	vivo PD2241 (Dimensity 9200 / MT6985), Android 15
Firmware	PD2241_A_15.2.10.2.W10.V000L1
Kernel	5.15.178-android13-8-gfb31f5bdd612-dirty
Bootloader	Locked (ro.boot.flash.locked=1)
SELinux	Enforcing
panic_on_oops	Enabled → any kernel OOPS = instant reboot
Exploit	CyberMeowfia — CVE-2026-43499 (IonStack)
Source tree	android_15.0_kernel_MT6985 (5.15.178) — does not match device version (source is android15 GKI, device runs android13 GKI)

---

What Was Done

1. Source Analysis → Extracting Struct Offsets

Extracted from arch/arm64/include/asm/memory.h + include/linux/fs.h + android/abi_gki_aarch64.xml:

• Memory layout: KIMAGE_TEXT_BASE = 0xffffffc008000000, VA_BITS=39, DIRECT_MAP=256GB
• task_struct: 36864 bits, fully parsed (ABI XML layout-offset-in-bits)
• file_operations: no iopoll (android13 GKI), IOCTL=0x48, open=0x68
• cred: atomic_t usage = 4 bytes, uid=0x04
• struct page: 64 bytes, slab_cache=0x18

Key finding: Source is android15 GKI, device is android13 GKI — task_struct offsets differ by 0x40~0x88 bytes, cannot blindly copy from source.

2. Firmware Unpacking → Extracting Symbols

OTA zip (8.3GB)
  → payload.bin (8.2GB)
    → payload_dumper → boot.img (96MB, v4 header)
      → LZ4 decompress → Image (50MB ARM64)
        → kallsyms-finder → 187810 symbols

Extracted symbols from two firmware versions (15.2.7.6 / 15.2.10.2) — the same symbol differs by 10KB~200KB between versions, must use the correct version.

3. Disassembly Verification → capstone Confirms Key Offsets

# In rt_mutex_adjust_pi:
LDR x21, [x19, #0x8b0]  → pi_blocked_on = 0x8b0 (android15 value, not frankel)

This confirmed the task_struct layout is the android15 branch, not frankel's android13.

4. Compilation → Passes

NDK r29, make PROJECT=android_15.0_kernel_MT6985 → preload.so (150KB).

5. Execution → Repeated Crashes

[+] preload starting pid=25414
[+] p0 profile ... all symbols loaded correctly
[-] KernelSnitch mm_struct leak failed     ← sometimes absent (occasional success)
[+] slide child context route=pselect      ← slide KASLR leak child process started
[kernel panic]                                ← rt_mutex_adjust_prio_chain+0x1b0

Crash instruction (capstone):

ldar w8, [x27]    ; x27 = waiter->lock (loaded from [x28, #0x38])
                  ; x27 value is garbage → no page table mapping → translation fault
                  ; → die() → panic → reboot

---

Why It Failed

Root Cause 1: KernelSnitch Unreliable on MTK

KernelSnitch is the entry point of the entire exploit — it leaks the mm_struct address through timing differences in the futex hash bucket:

1. Collision detection succeeds — 5 collisions found at low threshold
2. Bruteforce matching almost always fails — the core problem is:

MT6985 has CONFIG_KASAN_HW_TAGS=y → kernel tags slab allocations with MTE tags
mm_struct pointers carry KASAN tags → futex_hash computed on tagged pointer

But bruteforce scans the direct map (untagged addresses) → computed hash doesn't match
Even with MTE tag iteration (0-14, 15 total), on VA_BITS=39 systems
tag bits (bit56-59) overlap with sign-extension bits → some tag combinations produce invalid addresses → missed detections

Pixel devices don't have KASAN_HW_TAGS, so this mechanism works there. MTK doesn't.

Root Cause 2: CONFIG_PANIC_ON_OOPS Is the Killer

Pixel:  kernel OOPS → dump_stack → keeps running → exploit can retry
MT6985: kernel OOPS → die() → panic() → instant reboot → no room for trial and error
A slight deviation in the π chain corruption causes total collapse; on Pixel a deviation just means "this attempt failed, try another set of addresses."

And the bootloader is locked (flash.locked=1) → cannot flash a custom kernel to remove this option.

Root Cause 3: Kernel Version Drift

Source tree: 5.15.178 android15 GKI
Device:      5.15.178-android13 (vivo vendor)

Although the major version is 5.15.178 for both, the GKI branches differ (android13 vs android15), so key struct layouts like task_struct/cred are inconsistent. After repeatedly switching between frankel/android15 offset sets, disassembly was ultimately required to lock it down.

---

Adjustments Attempted (All Useless)

Change	Purpose	Result
THRESHOLD_MULT 10→5→3	Lower collision detection threshold	<5 too many false positives
APPENDED_FUTEXES 4096→8192	Increase hash chain difference	No effect
REPEAT_MEASUREMENT/AVERAGE	Increase sampling precision	No effect
MTE=1	Make bruteforce iterate tags	Slower, actually fewer crashes
MM_STRUCT_SZ 0x500→0x400	Fix mm_struct stride	Necessary, ABI is actually 992 bytes
IDENTITY_END 64GB→256GB	Expand scan range	Too slow (MTE iteration), still no match
TASK offsets: android15↔frankel	Lock down correct offsets	Disassembly confirms android15
FOPS offsets: android15↔frankel	android13 has no iopoll	Used frankel

---

Current State of target.h

In exploit/targets/android_15.0_kernel_MT6985/target.h:

Category	Confidence	Verification Method
Memory layout	Correct	memory.h calculation + kallsyms _text verification
Symbol offsets (22)	Correct	Extracted from 15.2.10.2 boot.img
task_struct offsets	Correct	ABI XML + capstone disassembly (pi_blocked_on=0x8b0)
FOPS offsets	Incorrect (fixed 2026-07-31)	Original values copied from frankel (android13 has no iopoll); source tree ABI actually has iopoll@0x30, ioctl=0x50, open=0x70 — see VERIFICATION.md
CRED offsets	Correct (verified)	ABI XML: uid=0x04, securebits=0x24, caps=0x28, security=0x78

Assembly compiles, it runs, but loses at the last mile.

---

If You Want to Continue

Prerequisites (All Required)

1. Remove CONFIG_PANIC_ON_OOPS — either flash a custom kernel (requires unlocking the bootloader), or find an MT6985 device where this option is disabled by default
2. Fix KernelSnitch — requires cache timing calibration for MTK Dimensity 9200, or completely replace KernelSnitch with another mm_struct leak method in the exploit

Possible Alternative Approaches

• /proc/self/pagemap — restricted on this device (returns all zeros)
• MTK-specific debug interfaces (/proc/mtk_*) — exist but require further analysis
• MTK camera/GPU driver ioctl vulnerabilities — simpler privilege escalation path
• Wait for community adaptation of an MTK variant

Residual Value of This Repository

• symbols/kallsyms_PD2241_15.2.10.2.txt — complete 15.2.10.2 symbol table, directly usable by others
• device_config.txt — actual device kernel config, shows what the vendor changed
• exploit/targets/android_15.0_kernel_MT6985/target.h — struct offsets verified
• scripts/server_compile.py — automated compilation, fast rebuild after parameter changes

---

Pitfall Checklist (For Future Reference)