CVE-2026-28596 AI-generated analysis

platform/frameworks/base, services/core GameManagerService (game mode config meta-data parsing)

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

Adds OutOfMemoryError to the catch clause around the game-mode-config XML meta-data parsing in GameManagerService, so an oversized package XML resource no longer crashes the process; the service falls back to the default game mode flags instead.

Root cause

In services/core/java/com/android/server/app/GameManagerService.java, a method parses a package's game mode config meta-data XML. It gets the package Resources via packageManager.getResourcesForApplication, walks the parser with parser.next(), then calls resources.obtainAttributes(attributeSet, R.styleable.GameModeConfig). It caught only NameNotFoundException, XmlPullParserException and IOException. According to the commit message, a very large XML (>1 GB) makes parsing fail with an OutOfMemoryError. Nothing caught that error, so the process crashed.

How the fix works

• services/core/java/com/android/server/app/GameManagerService.java, in the meta-data parsing method that returns xmlFound: the multi-catch is extended from `NameNotFoundException | XmlPullParserException | IOException` to also include `OutOfMemoryError`.
• The existing handler body is reused unchanged. On OutOfMemoryError it resets the flags to their defaults (mPerfModeOverridden=false, mBatteryModeOverridden=false, mAllowDownscale=true, mAllowAngle=true, mAllowFpsOverride=true), logs 'Error while parsing XML meta-data for ' + METADATA_GAME_MODE_CONFIG with Slog.e, and the method returns xmlFound.
• Single-file change (2 insertions, 1 deletion). It adds no size validation and no parser limits.

Completeness

• Covers only an OutOfMemoryError raised inside this one try block. The oversized XML is still processed; the fix catches the error and recovers rather than limiting input size.
• The handler adds no finally block. If the OutOfMemoryError happens after resources.obtainAttributes() and before array.recycle(), the TypedArray is not recycled (see lines 598-610 of the shown code).
• Code before the start of the try block is not shown in the material, so it is unclear whether any allocation there is covered.
• This commit touches no other XML-parsing sites.

Behavior changes

• An OutOfMemoryError during game-mode-config meta-data parsing is now caught: the service logs an error, applies the default game mode flags and returns xmlFound (which may already be true), instead of crashing.
• No new error codes, API changes or stricter validation.

Per major

• Android 14: same fix: commit 12567c8df8f3 in android-security-14.0.0_r29, identical two-line catch extension at line ~613 (resolved by bug_id).
• Android 15: same fix: commit 47898903e7c3 in android-security-15.0.0_r17, identical hunk at line ~622 (only the line offset differs).
• Android 16: same fix: commit 581fd9950f41 in android-security-16.0.0_r8, identical hunk at line ~636 (only the line offset differs).
• Android 17: not affected: the bulletin does not list Android 17. android-security-17.0.0_r1 has 4 of 5 lines of the patched region; the material contains no 17 commit.

Unknowns

• The name of the enclosing method and class is not shown in the provided context.
• Where the try block begins, and whether any allocation before it could also throw OutOfMemoryError.
• Which callers invoke this parse, and therefore how directly a third-party app can trigger it.
• Whether the Android 17 branch contains an equivalent change: the region matches in 4 of 5 lines, but the material has no 17 commit.

Back to September 2026 · Findings