CVE-2025-48603 AI-generated analysis
platform/frameworks/base, input method framework (core/java/android/view/inputmethod/InputMethodInfo.java, consumed by InputMethodManagerService)
Adds a 200 KB size limit on an input method's metadata XML resource (InputMethod.SERVICE_META_DATA) in InputMethodInfo. An oversized resource now makes the code throw XmlPullParserException before the XML is parsed, so the system process (IMMS) cannot be driven out of memory while constructing InputMethodInfo.
Root cause
The InputMethodInfo constructor that takes a ServiceInfo called si.loadXmlMetaData(pm, InputMethod.SERVICE_META_DATA) and parsed the resulting XmlResourceParser with no limit on the size of the referenced XML resource. Per the commit message, a malicious IME could load an extremely large metadata XML, and IMMS ran out of memory while constructing InputMethodInfo from it.
How the fix works
- core/java/android/view/inputmethod/InputMethodInfo.java, constructor: the call pm.getResourcesForApplication(si.applicationInfo) moves ahead of si.loadXmlMetaData(...), and a new call validateXmlMetaData(si, res) is inserted before loadXmlMetaData. The size check therefore runs before any XML parsing starts.
- core/java/android/view/inputmethod/InputMethodInfo.java: new constant MAX_METADATA_SIZE_BYTES = 200 * 1024.
- core/java/android/view/inputmethod/InputMethodInfo.java, new private static validateXmlMetaData(ServiceInfo si, Resources res): returns early if si.metaData is null or metaData.getInt(InputMethod.SERVICE_META_DATA) is 0. Otherwise it opens the resource with res.openRawResource(resourceId) in a try-with-resources block and calls is.skip() in a loop until MAX_METADATA_SIZE_BYTES bytes are skipped or the stream ends. If exactly MAX_METADATA_SIZE_BYTES bytes were skipped and is.read() != -1, it throws XmlPullParserException("Input method metadata exceeds maximum allowed limit of 200KB for <pkg>. InputMethod will not be loaded. ").
- The exception is thrown inside the constructor's try block, before loadXmlMetaData runs. Its message says the input method will not be loaded.
Completeness
- Covers only the InputMethod.SERVICE_META_DATA resource referenced from the IME ServiceInfo metaData, and only in the InputMethodInfo constructor path that calls si.loadXmlMetaData.
- The check measures the raw resource byte size, not the in-memory size of the parsed structures, so the bound on memory use is indirect.
- If metaData is null or metaData.getInt(InputMethod.SERVICE_META_DATA) returns 0, validation is skipped.
- The patch does not touch any other metadata-XML consumers in frameworks/base. The material does not show whether sibling parsers have equivalent limits.
Behavior changes
- An IME whose metadata resource exceeds 200 KB (204800 bytes) now causes an XmlPullParserException ('InputMethod will not be loaded'). Before the fix it was parsed regardless of size.
- pm.getResourcesForApplication(si.applicationInfo) is now called before si.loadXmlMetaData, so a NameNotFoundException for missing application resources is raised earlier, before the null-parser check.
- Each InputMethodInfo construction now does an extra openRawResource and skips up to 200 KB of the metadata resource.
Per major
- Android 14: same fix: commit ea309e799b21 in android-security-14.0.0_r24 (cherry-pick of 5e31d9c067f0, Change-Id Ic90e1bd6615f5954577ed29c3daf7b44596fb137). 8/8 patched lines present at android-security-14.0.0_r29.
- Android 15: same fix: commit e7824e85ad70 in android-security-15.0.0_r12. The hunks are identical apart from line offsets (the file has an extra java.util.Collections import and an mIsVirtualDeviceOnly field). 8/8 lines present at android-security-15.0.0_r17.
- Android 16: same fix: commit b4c6786312a2 in android-security-16.0.0_r3, with hunks identical to Android 15. 8/8 lines present at android-security-16.0.0_r8.
- Android 17: not affected: the bulletin does not list Android 17. The patched region (8/8 lines) is present at android-security-17.0.0_r1.
Unknowns
- The material does not show the exact caller in InputMethodManagerService or when the vulnerable constructor runs (package scan, IME list refresh).
- The material does not show the constructor's catch/handling of XmlPullParserException or how callers react, so how the rejection is surfaced (log, skipped IME) is not confirmed.
- The material does not show whether the original OOM came from the parser itself or from the subtype list built from the XML. The fix bounds only the raw resource size.
- The material does not show what loadXmlMetaData does when the meta-data value is not a resource reference.