Researchers from Google's Project Zero team have detailed a technique for creating a working exploit that allows remote code execution with kernel privileges. Linux, by sending an SMS or RCS message with a specially crafted audio attachment. The attack is carried out without any user interaction, including viewing or listening to the received message.
The exploit involves two vulnerabilities: in the Dolby Unified Decoder library (CVE-2025-54957) and the bigwave kernel driver. Linux (CVE-2025-36934). Previously, exploiting codec vulnerabilities required the user to listen to or view malicious content. Following the integration of AI assistants in recent releases, AndroidIn firmware, received multimedia content is automatically decoded upon receipt, significantly increasing the attack surface for zero-click attacks. In the context of SMS and RCS audio messages, the Google Messages app automatically generates transcriptions for text search using the com.google.android.tts service, allowing exploitation of vulnerabilities in existing audio codecs without user intervention.
The issue in Dolby Unified Decoder is caused by an integer overflow when calculating the buffer size for processed syncframe data structures, which can be exploited to write beyond the allocated buffer's bounds. The overflow can overwrite the pointer used to process the next sync frame. Modifying this pointer, in turn, allows the attacker to overwrite the function pointer with data controlled by the attacker, executing their code with "mediacodec" privileges, restricted through SE.Linux.
To exploit the kernel Linux A vulnerability was exploited in the bigwave driver, responsible for working with the character device /dev/bigwave , which was accessible from SELinux- "mediacodec" context. The vulnerability allowed kernel structures to be overwritten by manipulating the BIGO_IOCX_PROCESS ioctl call, resulting in code execution with kernel privileges.
The vulnerability in the Dolby Unified Decoder library (libcodec2_soft_ddpdec.so), which provides functions for decoding Dolby Digital (DD, AC-3) and Dolby Digital Plus (DD+, EAC-3) formats, is not specific to Android and firmware for Pixel 9, and also appears on other platforms (Samsung S24, MacBook Air M1, iPhone 17 Pro, Windows, ChromeOS, etc.). In AndroidThe AOSP repositories and the Samsung S24 firmware apply a seccomp system call filter to processes launched in the mediacodec context, making it more difficult to exploit kernel vulnerabilities. The Pixel 9 firmware lacked such a filter. attacks could protect Memory Tagging (MTE) mechanism, but it is available for Pixel 8+ devices only as an option activated when you turn on the "Advanced Protection" mode. macOS and iOS exploitation is complicated by building the library with the "-fbounds-safet" flag, which introduces additional array bounds checks that reduce performance.
Researchers are separately investigating issues with the release of a fix for a vulnerability in the Dolby Unified Decoder to users. The vulnerability was publicly disclosed 82 days before the fix was released to Pixel device users. Dolby was informed of the issue on June 26, 2025. The first binary fix was released on September 18 for Chrome OS 6, but for devices Android Dolby only released binary patches on October 8th. On October 15th, information about the vulnerability was publicly disclosed. On November 12th, Samsung released a fix, and only on January 5th was a fix for Pixel devices published. The patch was distributed to all Android-the devices took 139 days.
The vulnerability was discovered in Dolby Unified Decoder in less than two days, and in the BigWave driver in less than a day of review. The effort to develop a working exploit for the Dolby Unified Decoder vulnerability was estimated at eight weeks for a single researcher, and three weeks for BigWave. In a report published by Dolby on October 14, the Dolby Unified Decoder vulnerability was rated as low-risk, despite sharing details of the exploit being developed. The BigWave vulnerability was rated as low-risk. Android Moderate severity level, citing that the attack was only possible from privileged content and was not available to unprivileged contexts (three months later, the vulnerability status was changed to "dangerous issue").
Source: opennet.ru
