CVE-2026-0056 AI-generated analysis

platform/frameworks/base, libs/androidfw (ResStringPool string pool parser)

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 (6 corrections). Verify against the commit before relying on it.

Adds two validations of ResStringPool_header.styleCount in ResStringPool::setTo (libs/androidfw/ResourceTypes.cpp) so that the declared style offset array cannot overflow its size computation or extend past stringsStart, returning BAD_TYPE for such chunks.

Root cause

Before the fix, ResStringPool::setTo did not validate the header's styleCount against the chunk layout. The visible context shows checks on stringCount (headerSize + stringCount*sizeof(uint32_t) <= size), stringsStart and stylesStart, but none relating styleCount to the space between the style offsets (mEntryStyles) and stringsStart. Per the commit message, this could allow out-of-bounds reads beyond the bounds of the string pool chunk. The exact read site is not shown in the material.

How the fix works

• libs/androidfw/ResourceTypes.cpp:ResStringPool::setTo, right after an existing stylesStart BAD_TYPE check and before mStylePoolSize is computed: the pool is rejected with mError = BAD_TYPE if mHeader->styleCount > numeric_limits<decltype(styleCount)>::max() / sizeof(uint32_t), so the following multiplication cannot overflow (log: 'potential integer overflow when finding style entries').
• Same function: computes styleOffsetsStart = mEntryStyles (as uint8_t) - mHeader (as uint8_t), the byte offset of the style offsets inside the chunk, and rejects with BAD_TYPE if mHeader->styleCount * sizeof(uint32_t) > (mHeader->stringsStart - styleOffsetsStart). The declared style offset array must therefore fit before stringsStart (log: 'style offsets extend past style data start').
• libs/androidfw/tests/ResourceTypes_test.cpp (new) and libs/androidfw/Android.bp: adds two tests to libandroidfw_tests. Each builds a valid one-style pool with StringPool::FlattenUtf8, sets styleCount to UINT32_MAX in one test and to 2 in the other, and asserts that setTo returns BAD_TYPE.

Completeness

• Covers two cases: an overflow of styleCount * sizeof(uint32_t), and a styleCount that declares more offset entries than fit before stringsStart. Both are rejected when setTo parses the pool.
• The second check uses an unsigned subtraction (mHeader->stringsStart - styleOffsetsStart). The material does not show an explicit check that stringsStart >= styleOffsetsStart, so it is not visible whether earlier validation guarantees that order.
• The fix does not change how the style data area is sized (mStylePoolSize derived from header.size - stylesStart), and it leaves the existing stylesStart checks as they were.

Behavior changes

• ResStringPool::setTo now returns BAD_TYPE (and sets mError) for string pool chunks whose styleCount exceeds the type maximum / 4 or whose style offset array would extend past stringsStart. Two new ALOGW messages are logged.
• Resource data containing such malformed string pools is rejected; the commit's manual test notes that an APK with an invalid styleCount failed to install.
• New test file tests/ResourceTypes_test.cpp added to the libandroidfw_tests cc_test.

Per major

• Android 14: same fix: f1c0bc9dd174 in android-security-14.0.0_r28, ResourceTypes.cpp hunk at @@ -652 plus the test file; 8/8 patched lines present at android-security-14.0.0_r29.
• Android 15: same fix: e80f76ded67a in android-security-15.0.0_r16, identical code change; only the hunk offsets differ (ResourceTypes.cpp @@ -670); 8/8 lines present at android-security-15.0.0_r17.
• Android 16: same fix: d5a52f737cab in android-security-16.0.0_r7, identical code change (@@ -673); 8/8 lines present at android-security-16.0.0_r8.
• Android 17: same fix: d69b0c6010e5 in android-17.0.0_r1, diff identical to Android 14; 8/8 lines present at android-security-17.0.0_r1.

Unknowns

• The material does not show how mEntryStyles is computed or where style offsets are read (e.g. styleAt), so the exact out-of-bounds read site is not shown.
• The enclosing condition of the new checks (for example whether they run only when styleCount > 0) is not visible in the provided context.
• Whether earlier validation guarantees that stringsStart is at or after the end of the style offset area (which would make the unsigned subtraction in the new check safe) is not visible.
• Which caller paths (install-time parsing vs. runtime resource loading) were the reported trigger is not stated, apart from the commit's manual test note about APK installation.

Back to June 2026 · Findings