CVE-2025-34449: 
NixOS vulnerability analysis and mitigation

CVE-2025-34449 is a global buffer overflow vulnerability in Genymobile/scrcpy's sc_device_msg_deserialize() function, specifically within the sc_read32be helper invoked during device message processing. It affects all scrcpy versions up to and including 3.3.3, prior to commit 3e40b24. The vulnerability was discovered and reported by Vlatko Kosturjak of Marlink Cyber on October 9, 2025, and publicly disclosed on December 18, 2025. It carries a CVSS v3.1 base score of 9.1 (Critical) (Marlink Advisory, Red Hat CVE).

The root cause is an inverted bounds check (CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer; CWE-502: Deserialization of Untrusted Data) in sc_device_msg_deserialize() (device_msg.c, around line 53). The condition if (size < len - 5) should be if (size > len - 5) — the incorrect comparison allows a crafted device message with an oversized payload length field to pass validation, causing sc_read32be to read beyond the end of the global 262,144-byte buffer buf defined in receiver.c. The overflow is triggered via the call chain: sc_read32be → sc_device_msg_deserialize → process_msgs → run_receiver, all executing in a dedicated receiver thread. Exploitation requires a compromised or malicious Android device (or a proxy injecting device messages) connected to a host running scrcpy; no authentication beyond the existing ADB/scrcpy session is needed. A public PoC (binary crash file and helper scripts) was included in the original GitHub issue report (GitHub Issue, Marlink Advisory).

Successful exploitation causes an out-of-bounds read on a global buffer, leading to memory corruption or a crash (denial of service) of the scrcpy host process. Because the overflow reads past the buf global array into adjacent global memory (including the scrcpy global struct), it may corrupt control-flow-relevant data, potentially enabling further exploitation depending on the host environment and available memory mitigations. Confidentiality impact is rated High (adjacent global memory may be disclosed), and availability impact is High (confirmed crash/DoS); integrity impact is not directly demonstrated but cannot be ruled out in permissive environments (Marlink Advisory, Red Hat CVE).

A proof-of-concept crash binary (device_msg_crash_0.bin) and helper scripts were published alongside the original GitHub issue, making the vulnerability reproducible with minimal effort (GitHub Issue). There is no evidence of in-the-wild exploitation or threat actor attribution at this time. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.015% (0.000150), indicating a low current probability of exploitation in the wild (Feedly).

1. Prerequisite — Compromised or Controlled Device: The attacker must control an Android device (physical or emulated) that is connected to the target host via ADB, with scrcpy version ≤ 3.3.3 running on the host.
2. Craft Malicious Device Message: Construct a UHID_OUTPUT device message with an oversized size field in the 16-bit big-endian length field at bytes 3–4, such that size < len - 5 evaluates to true (the inverted check passes), but the actual payload extends beyond the 262,144-byte global buf buffer.
3. Inject Message via ADB/Control Channel: Send the crafted binary message through the ADB control channel to the scrcpy receiver thread on the host. This can be done by a compromised device firmware, a malicious app with ADB access, or a man-in-the-middle proxy on the ADB connection.
4. Trigger Out-of-Bounds Read: The process_msgs() function in receiver.c passes the message to sc_device_msg_deserialize(), which calls sc_read32be() with a pointer that extends past the end of buf, reading into adjacent global memory.
5. Achieve DoS or Memory Disclosure: The out-of-bounds read causes a crash (confirmed via ASan and debug assertions), resulting in denial of service. In environments without memory protections, adjacent global data (including the scrcpy struct) may be read or corrupted, potentially enabling further exploitation (GitHub Issue, Marlink Advisory).

• Process: Unexpected crash or abort of the scrcpy process on the host, particularly with an error message such as Assertion 'head <= len' failed or an ASan global-buffer-overflow report referencing sc_read32be in binary.h:56.
• Logs: scrcpy stderr output containing ERROR: Received unexpected HID output message immediately before a crash or abort; ASan output referencing sc_device_msg_deserialize and process_msgs in the stack trace.
• Network/ADB: Unusual or malformed UHID_OUTPUT messages observed on the ADB control channel; unexpected binary data sent from a connected Android device to the host scrcpy process.
• File System: Presence of crash dump files or core dumps generated by the scrcpy process in the working directory or system crash directories (GitHub Issue, Marlink Advisory).

Users should upgrade scrcpy to version 3.3.4 or apply commit 3e40b2473772cea3a23d4932088fd0bc4cc0f52c, which corrects the inverted bounds check in sc_device_msg_deserialize() (device_msg.c line 56: if (size < len - 5) → if (size > len - 5)) (GitHub Commit). As a workaround, only connect trusted, uncompromised Android devices to hosts running scrcpy, and avoid exposing the ADB interface to untrusted networks. Running scrcpy within a sandboxed environment (e.g., with SELinux, AppArmor, or a container) can limit the impact of memory corruption if patching is not immediately possible (Marlink Advisory).

The vulnerability was reported responsibly by Vlatko Kosturjak of Marlink Cyber and acknowledged via the scrcpy GitHub issue tracker, where the maintainer (rom1v) promptly applied a one-line fix (GitHub Commit). Red Hat and SUSE have tracked the CVE in their security advisories, and Tenable's Nessus plugin 279420 was released to detect the vulnerability (Red Hat CVE). No significant broader media coverage or notable social media discussion has been identified beyond the technical disclosure.