CVE-2026-55273 AI-generated analysis

platform/frameworks/base, tools/aapt2 (Java R.java generation, AnnotationProcessor)

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.

aapt2's AnnotationProcessor now rewrites Javadoc terminators ("*/") and Java Unicode escape introducers ("\u") in resource XML comments before emitting them into the Javadoc blocks of generated R.java, so a comment can no longer close the Javadoc block and inject Java source.

Root cause

AnnotationProcessor::AppendCommentLine in tools/aapt2/java/AnnotationProcessor.cpp placed comment text taken from resource XML into the "/** ... */" Javadoc block that aapt2 prints into generated R.java, and did not escape Javadoc terminators or Unicode escapes first. A comment containing the literal sequence "*/" ends the Javadoc block early. Because the Java compiler decodes Unicode escapes (e.g. \u002f for '/' or \u002a for '*') before it parses comments, sequences like "*\u002f" or "\u002a\u002f" have the same effect. Text after the breakout is then compiled as Java code in R.java.

How the fix works

• tools/aapt2/java/AnnotationProcessor.cpp: adds a file-static SanitizationRule struct (find_target, replace_length, replacement) and a static SanitizeJavadoc(std::string*) function with two rules, applied in order. (1) Every "*/" is replaced by "*/". (2) For every "\u", only the leading backslash is replaced (replace_length 1) by "\", giving "\u...". Each rule scans with std::string::find and moves past the replacement, so the loop does not re-match inside its own output.
• tools/aapt2/java/AnnotationProcessor.cpp:AnnotationProcessor::AppendCommentLine: calls SanitizeJavadoc(&comment) after the annotation-rule processing and before the empty-line trim check.
• tools/aapt2/java/AnnotationProcessor_test.cpp: adds TEST(AnnotationProcessorTest, SanitizesJavadocTermination). It covers a literal "*/", "*\u002f", "\u002a/", the multi-u form "\uu002f", adjacent "\u002a\u002f", and a backslash before the escape, and checks the exact printed Javadoc block.

Completeness

• Covers the two breakout primitives visible in the diff: the literal Javadoc terminator and Java Unicode escapes, including the multi-u form, because only the backslash is replaced. The second rule neutralizes every backslash followed by 'u', however many backslashes come before it (see the test case "\\u002f" -> "\\u002f").
• The sanitization is called in AppendCommentLine, which lines added via AppendComment reach (per the test). The output of the "*/" rule ("*/") cannot form a new "*/" or "\u", and the "\" output cannot form a new "*/".
• The fix only sanitizes text that goes through AnnotationProcessor. The material does not show whether other parts of the R.java generator emit resource-derived text outside AnnotationProcessor.
• The replacement puts HTML entities into the Javadoc text. This changes the generated comment text but not the Java semantics of R.java.

Behavior changes

• Generated R.java Javadoc comments now contain "*/" wherever the source XML comment had "*/", and "\u" wherever it had "\u".
• No new errors or warnings are added in the diff. aapt2 rewrites the text instead of rejecting the resource.
• The existing TrimWhitespace empty-line check now runs on the sanitized text.

Per major

• Android 14: Not affected (not listed by the bulletin). The resolver finds 6/8 lines of the patched region at android-security-14.0.0_r29. No Android 14 fix commit is shown.
• Android 15: Not affected (not listed by the bulletin). The resolver finds 8/8 lines of the patched region at android-security-15.0.0_r17. No Android 15 fix commit is shown.
• Android 16: Same fix: platform/frameworks/base 74f5e6fa6a20 in android-security-16.0.0_r8 (cherry-pick of internal changes 863026ecf4f3/89513b592c1e, Change-Id I6a566be2d3772bfbf86897f1ccf70bc8c7250e5f); 8/8 lines present.
• Android 17: Same fix: platform/frameworks/base 28830f292a06 in android-security-17.0.0_r1, with identical code. Only the surrounding context differs: sAnnotationRules has 4 entries including @hide, and the test file offset is different. 8/8 lines present.

Unknowns

• Whether any other code path in the aapt2 Java generator emits resource-derived text into R.java without going through AnnotationProcessor.
• Which build or packaging scenario the bulletin's Critical EoP rating assumes, and whether the impact is limited to the build host. The material only shows the host-side aapt2 code change.
• Why Android 14 and 15 are not listed as affected while the patched region is partly (14) or fully (15) present in their latest security tags.

Back to September 2026 · Findings