Bug Report: Write-After-Free Memory Corruption on GrapheneOS

Plex Players
1

Server Version: 1.43.1.10611
Player Version: 2026.08.0
Device: Various (running GrapheneOS)
OS Version: Android 16 (GrapheneOS Build)
Reproducibility: Intermittent/Random

Description

The latest version of the Plex Android app (v2026.8.0) is experiencing frequent, random crashes specifically on GrapheneOS. The cause has been identified as a write-after-free (WAF) memory bug.

While the standard Android allocator may allow these violations to pass silently (often leading to undefined behavior or delayed instability), GrapheneOS utilizes hardened_malloc. This allocator is designed to detect memory corruption in real-time and issues a SIGABRT to terminate the process when a write-after-free is detected, preventing potential security exploits.

Observed Behavior

The app crashes to the home screen without a “Plex has stopped” dialogue (typical of a SIGABRT). The system logcat identifies the crash as a fatal allocator error: hardened_malloc: fatal allocator error: detected write after free

Steps to Reproduce

Due to the nature of write-after-free bugs, the crash is non-deterministic but appears to occur most frequently during:

  1. Seeking during video playback.

  2. Backgrounding and foregrounding the app during active playback.

  3. Rapidly scrolling through metadata-heavy rows.

Technical Context & Workaround

The issue is confirmed to be a memory safety violation within the app’s native code or memory management layer.

  • Workaround: I suspect (but have not confirmed) that enabling “Exploit protection compatibility mode” or disabling the “Hardened memory allocator” for the Plex app within the GrapheneOS settings (which reverts the app to the standard, less-strict allocator) stops the crashing.

However, this is only a temporary fix. The presence of a write-after-free indicates a genuine memory corruption bug that should be addressed in the codebase to ensure stability and security across all Android distributions.

Note to Developers: If required, I can provide a full logcat dump including the backtrace provided by hardened_malloc to help pinpoint the specific offset where the violation is occurring.