CVE-2026-28664 AI-generated analysis
platform/art, runtime (runtime-generated app image, runtime/runtime_image.cc)
In platform/art, RuntimeImage::WriteImageToDisk now calls fchmod() to set the newly created runtime-generated app image (.art) file to 0444 right after creation, and fails image generation if that call fails.
Root cause
RuntimeImage::WriteImageToDisk did not restrict the permissions of the app image file it created, so the file stayed writable both while it was being generated and afterwards. The commit message says there was no need to keep it writable and that making it read-only helps prevent tampering. The bulletin rates the issue High, EoP.
How the fix works
- runtime/runtime_image.cc: adds #include <sys/stat.h> for fchmod and the S_IR* mode constants.
- runtime/runtime_image.cc:RuntimeImage::WriteImageToDisk: after an earlier failure check ('return false;') and before image->FillData(), calls fchmod(image_file->Fd(), S_IRUSR | S_IRGRP | S_IROTH) to set the file to 0444. The in-code comment says this happens immediately after creation to prevent tampering during the generation window, and that writes through the already-open descriptor still succeed.
- If fchmod fails, *error_msg is set to 'Failed to make runtime image read-only: <strerror>' and the function returns false. The commit message says the image is deleted in that case, but no explicit deletion appears in this hunk.
- The commit message says the image is made read-only once it is written and moved to its final path. The code instead applies fchmod at creation time, before the data is written.
Completeness
- Covers only the file created inside RuntimeImage::WriteImageToDisk. The mode is set on the open file's inode, so it should still apply after the file is moved to its final path.
- Does not change permissions of the containing directory. The diff does not address replacing or renaming the file by someone with write access to the directory.
- Does not change images generated before the patch. Nothing in the diff handles existing files.
- There is still a short window between file creation and the fchmod call.
- Whether the partially created file is actually deleted on the fchmod failure path is not shown in the hunk; only the commit message states it.
Behavior changes
- Runtime-generated app image files end up with mode 0444, set by fchmod after creation.
- New failure mode: if fchmod fails, WriteImageToDisk returns false with the error 'Failed to make runtime image read-only: ...' and no image is produced for that run.
Per major
- Android 14: same fix: commit f8f793610644 in android-security-14.0.0_r29, same hunk (the include context differs: <sstream> is present). 6/6 patched lines present.
- Android 15: same fix: commit 19665de3fb4d in android-security-15.0.0_r17, same hunk at about line 1903. 6/6 patched lines present.
- Android 16: same fix: commit a57f914df7ee in android-security-16.0.0_r8, same hunk at about line 1904. 6/6 patched lines present.
- Android 17: same fix: commit 70be2043e6db in android-security-17.0.0_r1, same hunk at about line 1915. 6/6 patched lines present.
Unknowns
- The file's mode before the fix, and how another party could modify the writable image (the commit only says 'tampering').
- Whether the existing failure handling in WriteImageToDisk deletes the file when fchmod fails, as the commit message claims.
- Why the commit message (read-only after the move) and the code (read-only at creation) describe different timing.
- Whether any later path-based open of the image for writing is affected by the new 0444 mode.