CVE-2026-55279 AI-generated analysis
platform/system/fs/fs_mgr, libfiemap (ImageManager, used by first-stage init for DSU image mapping)
ImageManager::MapAllImages in libfiemap now logs an error and returns false when the metadata directory does not exist, instead of silently returning true, so first-stage init no longer treats a non-existent or invalid DSU slot as a successfully mapped, running DSU.
Root cause
In libfiemap/image_manager.cpp, ImageManager::MapAllImages began with `if (!MetadataExists(metadata_dir_)) return true;`. A missing metadata directory was therefore reported to the caller as a successful mapping of all images. Per the commit message, when first-stage init was given an invalid or non-existent DSU slot (for example "."), this success return made init assume the DSU images were mapped and running, so it set ro.gsid.image_running=1; gatekeeperd then applied a GSI user ID offset, producing a persistent lockout of the host PIN (DoS).
How the fix works
- libfiemap/image_manager.cpp : ImageManager::MapAllImages: the early-return for `!MetadataExists(metadata_dir_)` is changed from `return true` to `LOG(ERROR) << "Metadata directory does not exist: " << metadata_dir_; return false;`. The caller now receives a failure for a missing metadata directory, consistent with the existing `return false` when OpenMetadata fails, so init does not proceed as if a DSU were mapped.
- Single-commit fix; no other files or functions changed. The rest of MapAllImages (OpenMetadata, init callback with block device partition names, CreateLogicalPartitions) is unchanged.
Completeness
- Covers only the missing-metadata-directory path in ImageManager::MapAllImages; the OpenMetadata failure path already returned false and is untouched.
- The fix does not validate the DSU slot name itself (e.g. reject "."); it relies on the metadata directory for a bogus slot not existing. The init-side logic that sets ro.gsid.image_running based on the MapAllImages result is not part of this diff and is not shown in the material.
- Other ImageManager entry points that may check MetadataExists are not shown in the material, so whether they share a similar success-on-missing-metadata return cannot be judged from what is provided.
Behavior changes
- MapAllImages now returns false (previously true) when metadata_dir_ does not exist.
- A new LOG(ERROR) line 'Metadata directory does not exist: <metadata_dir_>' is emitted in that case.
- Any caller that previously relied on MapAllImages succeeding as a no-op when no metadata exists will now observe a failure; per the commit message, the intended effect is that first-stage init does not mark a DSU as running for an invalid slot.
Per major
- Android 14: not affected per the bulletin; platform/system/fs/fs_mgr is not present in android-security-14.0.0_r30; no fix applied.
- Android 15: not affected per the bulletin; project not present in android-security-15.0.0_r18; no fix applied.
- Android 16: not affected per the bulletin; project not present in android-security-16.0.0_r9; no fix applied.
- Android 17: same fix: commit 666f09f0529c (cherry-pick of edb7e21425c1, Change-Id I103689be4b65f4e95ff9f44f261debc7d46ae9e7) in android-security-17.0.0_r1; all 3 lines of the patched region present at android-security-17.0.0_r2.
Unknowns
- The first-stage init code that calls MapAllImages and sets ro.gsid.image_running, and the gatekeeperd GSI user ID offset logic, are not in the material; the DoS chain is known only from the commit message.
- How the invalid DSU slot value (e.g. ".") can be supplied, and with what privilege, is not shown.
- Whether other ImageManager methods have the same return-true-on-missing-metadata pattern is not shown.
- Whether equivalent libfiemap code exists in Android 14 to 16 under a different project path is not shown; the material only states the platform/system/fs/fs_mgr project is absent from those security tags.