CVE-2024-32927 - Critical Use-After-Free in Android Radio HAL (sendDeviceState_1_6) Explained

On April 2024, security researchers identified a critical vulnerability in Android’s Radio Hardware Abstraction Layer (HAL), tracked as CVE-2024-32927. This bug allows a local malicious app to elevate privileges by exploiting a use-after-free condition in the sendDeviceState_1_6 function of RadioExt.cpp. In this deep dive, I’ll unpack what went wrong, show relevant code, describe how attackers exploit the bug, and link to more resources.

What is CVE-2024-32927?

CVE-2024-32927 is a use-after-free vulnerability caused by improper locking in code that handles phone radio communication between Android and the modem chipset. Here, a local app—without any special permissions—can abuse this flaw to gain higher privileges, possibly taking control over phone calls, radio settings, or even execute arbitrary code in the context of the privileged service.

Understanding the Vulnerable Code

The faulty logic lives inside the function sendDeviceState_1_6 in RadioExt.cpp (part of AOSP and vendor-specific HALs).

Simplified vulnerable snippet

Return<void> RadioExtImpl::sendDeviceState_1_6(DeviceStateType type, int32_t state) {
    std::lock_guard<std::mutex> lock(mutex_);
    auto callback = mCallback;  // Shared pointer to callback object

    // ... Some other operations

    // Unsafe: releasing lock too soon!
    lock.~lock_guard();

    // Another thread could free callback object here

    // Use after free vulnerability
    callback->onStateChanged(type, state);

    return Void();
}

What went wrong?

- mCallback is a shared resource, possibly freed or replaced by another thread after the lock is released.
- The code calls a method on callback after the lock is released, risking that callback has been deleted, leading to a *use-after-free*.

An attacker-controlled local app can

1. Race: Interact with the vulnerable Radio HAL to trigger sendDeviceState_1_6 repeatedly, while simultaneously causing the callback object to be destroyed from another thread.
2. Exploit UAF: When the lock is released and before onStateChanged is called, attacker may trigger cleanup, letting callback point to freed memory.
3. Privilege Escalation: By carefully controlling memory reuse, execute malicious code or cause denial-of-service as the service accesses stale or poisoned memory.

Key Point: No root or special privileges required; the attack can be staged using only standard Android app capabilities.

Here’s a simplified (pseudocode) illustration of the race

// Thread 1: Triggers sendDeviceState_1_6
RadioExtImpl->sendDeviceState_1_6(TYPE, STATE);

// Thread 2: Destroys/Resets mCallback
std::lock_guard<std::mutex> lock(mutex_);
mCallback.reset(); // Or sets to null, frees object

By racing these two threads, the sendDeviceState_1_6 method may end up calling a method on a deleted object.

Potential Impact

- Local privilege escalation: Attackers may gain elevated permissions within the Radio HAL context.
- Service crashes/denials: Device instability.

Possibly arbitrary code execution: If attacker reuses freed memory with crafted payloads.

## Fix: How Google/Vendors Remediated

Patch backported to AOSP and vendor trees. The fix is simple: Don’t use objects after releasing the lock. Ensure the callback object is retained safely.

Fixed snippet

Return<void> RadioExtImpl::sendDeviceState_1_6(DeviceStateType type, int32_t state) {
    std::shared_ptr<CallbackType> safeCallback;
    {
        std::lock_guard<std::mutex> lock(mutex_);
        safeCallback = mCallback;  // Safe copy under lock
    }
    if (safeCallback) {
        safeCallback->onStateChanged(type, state);  // Use only outside lock, safe
    }
    return Void();
}

References and More Information

- Official Android Security Bulletin, April 2024
- AOSP Patch Commit for CVE-2024-32927
- Common Weakness Enumeration: CWE-416: Use After Free
- Technical Deep Dive, Project Zero (Historical Similar Bug)

Update your device as soon as a vendor patch is available.

- App Developers: Always use proper object locking, and never use shared objects after releasing locks.

Conclusion

CVE-2024-32927 is a textbook example of why correct locking and memory management are vital in system code. As Android devices rely on complex HAL code for critical functions, a small race can quickly become a serious security issue.

Stay safe by keeping devices fully updated, and encourage vendors to patch fast!


*For more details and hands-on guidance, follow up on the linked advisories. If you’re a researcher, consider reviewing your project for similar locking problems!*

Timeline

Published on: 08/19/2024 17:15:07 UTC
Last modified on: 08/19/2024 18:36:20 UTC