CVE-2026-0010 AI-generated analysis
platform/frameworks/av, drm/common (drmserver Binder interface IDrmManagerService)
In BnDrmManagerService::onTransact, the fix replaces a fixed 16-byte stack buffer that sprintf("%lu") filled with the file descriptor value by a dynamically sized String8::format("%d", fd). This removes a possible stack buffer overflow when the descriptor value is negative.
Root cause
In drm/common/IDrmManagerService.cpp, BnDrmManagerService::onTransact (hunk at line ~1001, inferred to be in the handler after the ACQUIRE_DRM_INFO case label at line 985 of the context) handled a request entry with key "FileDescriptorKey" as follows: it read data.readFileDescriptor() into an int fd, cast it to unsigned long and wrote it with sprintf(buffer, "%lu", ...) into a local char buffer[16]. If fd is negative and unsigned long is 64-bit, the cast value prints as up to 20 decimal digits plus the terminating NUL. That is more than the 16-byte stack buffer. The key and the parcel content come from the Binder caller of drmserver.
How the fix works
- drm/common/IDrmManagerService.cpp, BnDrmManagerService::onTransact, "FileDescriptorKey" branch: the local char buffer[16] and the sprintf call are deleted.
- The value stored in drmInfoRequest now comes from String8::format("%d", fd). This sizes the string as needed and formats fd as a signed int, so there is no fixed-size buffer left to overflow.
- data.readFileDescriptor() and the drmInfoRequest->put(key, ...) call are otherwise unchanged. The fix is a single hunk in a single file.
Completeness
- The fix covers the only sprintf-into-fixed-buffer site shown in the material. The overflow is gone whatever value fd holds.
- The fix does not check that fd is non-negative. A negative fd still produces a "FileDescriptorKey" entry whose value is a negative number string, passed on through drmInfoRequest. This change does not address that.
- The neighbouring PROCESS_DRM_INFO case (lines 932-983 of the context) reads only key/value strings and has no file-descriptor formatting path. No sibling occurrence appears in the shown code.
Behavior changes
- For non-negative descriptors the stored string is the same as before (decimal digits).
- For a negative fd, the stored value is now the signed decimal (e.g. "-1") instead of a wrapped unsigned number. No error is returned and the request still proceeds.
- The change adds no new error codes, permission checks or parcel validation.
Per major
- Android 14: same fix: platform/frameworks/av 8bf16f1ae904 in android-security-14.0.0_r25 (cherry-pick, Change-Id I6efecac362757c10b2308d020440eac5edc5b873), identical hunk. At android-security-14.0.0_r29, 5/8 lines of the patched region are present.
- Android 15: same fix: platform/frameworks/av c8713a065232 in android-security-15.0.0_r13, identical hunk. At android-security-15.0.0_r17, 5/8 lines of the patched region are present.
- Android 16: same fix: platform/frameworks/av ebdbf918dd87 in android-security-16.0.0_r4, identical hunk. At android-security-16.0.0_r8, 5/8 lines of the patched region are present.
- Android 17: not affected: Android 17 is not listed by the bulletin. At android-security-17.0.0_r1, 5/8 lines of the patched region are present.
Unknowns
- The exact transaction case label containing the hunk is not shown. The context ends at the ACQUIRE_DRM_INFO case label (line 985) and the hunk is at line ~1001 using drmInfoRequest, so it is inferred to be in that handler.
- What data.readFileDescriptor() returns when no valid descriptor is present at that position is not shown.
- Why only 5/8 lines of the patched region match at the latest tags is not explained.
- Which processes or SELinux domains can reach this drmserver interface is not shown in the material.
- The two googleplex Cherrypick-From commits are referenced but their contents are not shown. The AOSP commit is a single hunk.