International Color Consortium
Members
Getting Started
V4
iccMAX
Making color seamles between devices and documents
ICC Specifications
Technical Notes
ICC Resource Center
ICC Slide Presentation
ICC Logos
Information on Profiles
ICC White Papers
Color Management Links
Member List
ICC Working Groups
FAQ
Forum
Home
Search ICC:
 
Got a question about ICC Profiles or colour management?

Android lock screen bug and ICC profiles

Early in 2020 a bug was widely reported (for example here, here and here) on smartphones running a version of Android. When the picture below was used as a lock screen image, users noted that the OS crashed and the phone could only be restarted after a factory reset. This occurred when a particular ICC profile was embedded in the image, leading some users to believe the profile was the root cause of the problem. When replaced by another profile, such as one for the sRGB colour space, the problem did not occur. The problem was quickly addressed by a code update.

Image with faulty embedded profileImage with sRGB profile embedded

The root cause of the crash has been identified by multiple sources including Lineageos and River Loop Security as a rounding error in a luminosity histogram calculation (using a fixed-value ITU BT.709 matrix hardcoded in Java). In the image above, the brightest pixel (at x=407, y=600) has RGB values [255 255 253], which yield a greyscale value of 257 when the luminosity calculation is applied, because the conversion from float to integer rounds to the ceiling and there is no bounds-checking. This leads to an attempt to access an out-of-bounds array element in a 256-element fixed-size array, Modifying this code resulted in the problem being solved.

Why was it thought that the ICC profile was the cause?

The profile was generated automatically by the OS, and examining it (e.g. using Profile Dump or ICC Profile Inspector) shows that the profile is poorly constructed and technically invalid. The problems are described below. However, similar problems are not uncommon in ICC profiles in circulation, and in practice CMMs usually handle these without rejecting the profile.

What was wrong with the embedded profile?

According to the header the profile version is 2.1, corresponding to a 1997 version of the specification. This version has long been superseded; the current version of ICC.1 is 4.3 (2010) while for developers still using v2 the final v2 version 2.4 is recommended. The following problems can be seen in the profile:

  1. The preferred CMM field is empty. While v4 allows the CMM field to be set to zero if there is no preferred CMM, this is not allowed in v2.
  2. The date and time of profile creation are set to zero. This is not a valid date/time.
  3. Unicode data types are used to store the profile description and copyright information. These are v4 data types which are undefined in v2.
  4. Although the tone reproduction curve is defined as a simple gamma function, it is encoded using the parametric curve encoding introduced in v4. This is also undefined in v2.
  5. Issues 1 and 2 above are minor problems which a CMM parsing the profile will usually ignore. Issues 3 and 4 are technically violations of the specification making the profile invalid. However, CMMs often encounter the encoding of v4 tags in v2 profiles and in many cases are able to handle them.

  6. The XYZ values of the primaries are outside the visible range. This does not violate the specification since the XYZ values remain within the domain of the encoding. Assigning such values to the primaries has the effect of increasing the vividness of the image, as can be seen in the images above. An issue could conceivably arise if the RGB image data were converted PCS XYZ and then back to RGB using a smaller-gamut encoding such as sRGB, as some pixels may now be outside the encoding range unless they are clipped during the conversion.

ICC recommendations

The Android lock screen issue highlights a number of issues developers should be aware of in order to minimize vulnerabilities.

Profile makers Ensure that profiles strictly conform to the chosen profile version. ICC recommends version 4.3 as the current specification for ICC.1 profiles. Where there is a requirement to make version 2 profiles (for example due to adherence to an older file format standard), use the ICC.1:2001-04 specification for v2.4 profiles. See the ICC recommendations for making good v2 profiles.

CMM developers Follow good programming practice by testing code before release on all values within the domain and range of the supported image encodings, and particularly check that index values always remain with the correct range.

Image pipeline developers Ensure the CMM used to parse and apply profiles has been thoroughly tested, and test its output against a baseline CMM such as RefIccMax. Follow the above suggestions for CMM developers for image processing operations outside of the profile conversion.

More information about security in ICC profiles can be found here.