History log of /frameworks/base/core/tests/utiltests/src/android/util/RemoteIntArray.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
74c9983e80d8224bbe1de7c37e8f6ac4a76df11d 06-Dec-2016 Svetoslav Ganov <svetoslavganov@google.com> Fix vulnerability in MemoryIntArray

MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.

Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.

Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.

Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.

Tests: Updated the tests and they pass.

bug:33039926
bug:33042690

Change-Id: Ib8e50afcdb5475123968572ac9696e8ed4031631
/frameworks/base/core/tests/utiltests/src/android/util/RemoteIntArray.java
04df738bcb6584dd82b731a67f4cf8d6925b061e 11-May-2016 Svetoslav Ganov <svetoslavganov@google.com> Make settings cahches generation mechanism robust.

Settings is using a MemoryIntArray to communicate the settings table
version enabling apps to have up-to-date local caches. However, ashmem
allows an arbitrary process with a handle to the fd (even in read only
mode) to unpin the memory which can then be garbage collected. Here we
make this mechanism fault tolerant against bad apps unpinning the ashmem
region. First, we no longer unpin the ashmem on the client side and if
the ashmem region is purged and cannot be pinned we recreate it and
hook up again with the local app caches. The change also adds a test
that clients can only read while owner can read/write.

bug:28764789

Change-Id: I1ef79b4b21e976124b268c9126a55d614157059b
/frameworks/base/core/tests/utiltests/src/android/util/RemoteIntArray.java