CVE-2026-55256 AI-generated analysis

platform/frameworks/base, telephony MMS PDU parser (telephony/common/com/google/android/mms/pdu/PduParser.java); mirrored copy in platform/development samples/ApiDemos mmslib

AI-generated: written from the bulletin and the fixing diffs by claude-fable-5-1, then checked against the code by claude-opus-5-5 (4 corrections). Verify against the commit before relying on it.

Adds null checks in PduParser.parsePartHeaders so that a null Content-Disposition token-text value, a null filename parameter, or a null custom text header name or value is no longer passed on or dereferenced, which prevents NullPointerExceptions while parsing an MMS PDU.

Root cause

In PduParser.parsePartHeaders, values from the parser were used without a null check in three places. The parseWapString(pduDataStream, TYPE_TEXT_STRING) result for the Token-text form of Content-Disposition went straight to part.setContentDisposition(...). The parseWapString result for the P_FILENAME parameter went straight to part.setFilename(...). In the custom text header branch, tempHeader was dereferenced via new String(tempHeader) in the Content-Transfer-Encoding comparison, and tempValue (a parseWapString result) was passed to part.setContentTransferEncoding. The commit message describes these as potential NPEs, and the bulletin rates the issue as a Critical DoS. The added guards imply these values can be null; the conditions under which parseWapString returns null are not shown.

How the fix works

• telephony/common/com/google/android/mms/pdu/PduParser.java:parsePartHeaders (frameworks/base bcba9a47c23e): the Content-Disposition Token-text branch now stores the parseWapString result in a local byte[] contentDisposition and calls part.setContentDisposition only when it is non-null.
• Same function: the P_FILENAME branch stores the parseWapString result in byte[] filename and calls part.setFilename only when it is non-null.
• Same function: the custom text header branch replaces 'if (true == CONTENT_TRANSFER_ENCODING.equalsIgnoreCase(new String(tempHeader)))' with 'if (null != tempHeader && null != tempValue && ...)'. As a result, new String(tempHeader) is never evaluated on null and setContentTransferEncoding is never passed null.
• samples/ApiDemos/src/com/example/android/mmslib/pdu/PduParser.java:parsePartHeaders (development 6aa9341a7695): the same three hunks are applied to the sample copy of the parser.
• In all three cases a null value is now skipped (the field is not set on the PduPart) and parsing continues. The diff adds no error return.

Completeness

• Covers the three spots in parsePartHeaders named in the commit message: Content-Disposition Token-text, the filename parameter, and the custom text header name/value pair.
• Only parsePartHeaders is changed. The context shows parseHeaders calling new String(bVal) on a parseWapString result inside an 'if (LOCAL_LOGV)' block without a null check (see potential_variants). This fix leaves it unchanged.
• The fix does not change parseWapString or the PduPart setters. It only guards these call sites.
• The production copy (frameworks/base) and the ApiDemos sample copy (development) both received the same change.

Behavior changes

• If the Content-Disposition Token-text value or the filename parameter comes back null, the PduPart now has that field unset instead of throwing an exception.
• A custom text header with a null name or value is now ignored instead of throwing. Content-Transfer-Encoding is set only when both the name and the value are non-null.
• The diff adds no error codes or logging. Parsing continues past the affected field.

Per major

• Android 14: same fix: frameworks/base bcba9a47c23e and development 6aa9341a7695, both in android-security-14.0.0_r29. Both are cherry-picks with identical hunks (Merged-In I4cad171d30b14f3b6fd9dd2a0ef6bb1e5320665d / Ia8ea444778992ac7a3c2cdfab855e3b1f7e9c53f).
• Android 15: same fix: frameworks/base e2b80df1360a in android-security-15.0.0_r17, identical diff (same blob ids ecab9562f72e -> 6b3135945e53).
• Android 16: same fix: frameworks/base 01f51483eb2f in android-security-16.0.0_r8, identical diff.
• Android 17: same fix: development 21dbe0e7ba1f in android-security-17.0.0_r1 (ApiDemos copy, identical diff). The resolver reports 17 as resolved, but the material does not show a frameworks/base commit for 17.

Unknowns

• Whether the NPE comes from the PduPart setters (setContentDisposition/setFilename) or only from new String(tempHeader); the setter bodies are not in the material.
• The body of parseWapString, and which malformed input makes it return null, are not shown.
• Where tempHeader is assigned is not in the shown context.
• Which process would crash, and so why the bulletin rates this Critical, is not shown. The delivery path to PduParser is not in the material.
• No frameworks/base commit is listed for Android 17, and the meaning of '6/8 lines of the patched region present' at each tag is not explained.
• Which copy of the parser (frameworks/base or the ApiDemos sample) is actually used on devices is not shown.

Back to September 2026 · Findings