d712f837c446f8edcb3bb032357c91982e1610a4 |
|
12-Feb-2018 |
Philip P. Moltmann <moltmann@google.com> |
Revert "Add logging to MemoryIntArray" This reverts commit 6d8f30bee76f5f9cd97697a7aa5108c73df12057. Reason for revert: No more bug reports, logging not needed anymore Change-Id: I4b3150ac76f509c5baf75f10b58330d332836b97
/frameworks/base/core/java/android/util/MemoryIntArray.java
|
6d8f30bee76f5f9cd97697a7aa5108c73df12057 |
|
25-Jan-2018 |
Philip P. Moltmann <moltmann@google.com> |
Add logging to MemoryIntArray Test: Booted and saw logging Bug: 72415980 Change-Id: I828c74b2e703a8bd3cce9f325e5747f9243fe485
/frameworks/base/core/java/android/util/MemoryIntArray.java
|
7c5e0fd43175d09abf2b6e79a5cbaf6614c4eae5 |
|
12-May-2017 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Init MemoryIntArray#mFd with -1" am: d6eaa80590 am: a3f14a1531 am: b1274a057f am: 88993e244a Change-Id: I2c01823fd8bc0e1485352ea7edba32d84f31cd6a
|
88993e244a83829d054abdd76536e31c426749d4 |
|
12-May-2017 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Init MemoryIntArray#mFd with -1" am: d6eaa80590 am: a3f14a1531 am: b1274a057f Change-Id: I1db50e323b452520c766be40a0c6524a12e14194
|
d6eaa8059037d52695c011c02ba58e0d73fd9b9a |
|
12-May-2017 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Init MemoryIntArray#mFd with -1"
|
492e9e851cadca62df84eaff1a3c1ba788492fba |
|
22-Mar-2017 |
Narayan Kamath <narayan@google.com> |
Properly guard access to CloseGuard in finalizers. CloseGuard instances are allocated in constructors and usually assigned to final fields. This implies they're non-null in finalizers except in the case where the constructor throws. We add a null check to make sure we can continue cleaning up other state in the finalizer (if applicable). Also, this change decouples closeguard warnings in constructors from other state based logic. This because the logic there is usually duplicated with the call to close(). NOTE: This change is not a "complete" fix. Many of these finalizers are broken in the case where <init> throws. The only objective of this change is to make such errors more obvious. Note that some of these classes don't have CTS tests. Test: make, CtsMediaTestCases. Bug: 35609098 Change-Id: I24d9e0215f80e44914dba8ab99b6312fd6ed1fc0
/frameworks/base/core/java/android/util/MemoryIntArray.java
|
7b73266998e0dd4aa70f78c42854be9aaf91b7eb |
|
13-Oct-2016 |
Tetsutoki Shiozawa <tetsutoki.x.shiozawa@sonymobile.com> |
Init MemoryIntArray#mFd with -1 Symptom: mFd was left uninitialized when constructor was failed. As a result, it tried to close mFd=0 at finalize and it crashed with SIGABRT. Bug: 35791084 Change-Id: I913975ce3e8524a4e323f948621509e4655de17b
/frameworks/base/core/java/android/util/MemoryIntArray.java
|
1181f448c1a0705328a5593810100946e0c3e0dd |
|
09-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: Ibf56827209a9b791aa83ae679219baf829ffc2ac
/frameworks/base/core/java/android/util/MemoryIntArray.java
|
43966dafb3d3b2d04ac7e63198cd42047df00969 |
|
08-Dec-2016 |
Bill Napier <napier@google.com> |
Revert "Fix vulnerability in MemoryIntArray am: a97171ec49" This reverts commit fb12dd509f8e106d034f67c2e404845128128994. Change-Id: I9e1b22b8df0e754095541a758096cba279a81ab1
/frameworks/base/core/java/android/util/MemoryIntArray.java
|
a97171ec499fd876722733f35e51d0d6dbd8d223 |
|
08-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: I1004579181ff7a223ef659e85c46100c47ab2409
/frameworks/base/core/java/android/util/MemoryIntArray.java
|
1f06508bc640b90e613179f6371f53b9a839fa53 |
|
08-Dec-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Revert "Fix vulnerability in MemoryIntArray" This reverts commit 4694cad51122c20880d00389ef95833d7a14b358. Change-Id: I235ea3c4bd86d90bf97bc1a2d023f4780251e570
/frameworks/base/core/java/android/util/MemoryIntArray.java
|
4694cad51122c20880d00389ef95833d7a14b358 |
|
08-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: Id7f0e8a4c861b0b9fa796767e0c22d96633b14d1
/frameworks/base/core/java/android/util/MemoryIntArray.java
|
29139a8ae51110b0cd9d6249f643364849d401c9 |
|
08-Dec-2016 |
Aart Bik <ajcbik@google.com> |
Revert "Fix vulnerability in MemoryIntArray" This reverts commit 86dfa094de773670743d41c3e3156eace8e403a3. BROKE BUILD (as shown in some treehugger builds) frameworks/base/core/java/android/util/MemoryIntArray.java:84: error: cannot find symbol mCloseGuard.open("close"); ^ bug:33039926 bug:33042690 Change-Id: Ief875e543ec849fe55c747fb1ed5253f0cd9a122
/frameworks/base/core/java/android/util/MemoryIntArray.java
|
86dfa094de773670743d41c3e3156eace8e403a3 |
|
08-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: Ie267646eb88014034fbd048d7a9bc273420c7eff
/frameworks/base/core/java/android/util/MemoryIntArray.java
|
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/java/android/util/MemoryIntArray.java
|
388d08b6e3f6eab30e90ac22b151862b3b4ab352 |
|
01-Sep-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
resolve merge conflicts of a2c1196 to master Change-Id: I221f03e2cda9e677199698d492d16788c25c9e96
|
e257d6e167fc1beed092324ff4b8bcb073e55904 |
|
29-Aug-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Properly close fd backing a MemoryIntArray Use ParcelFileDescriptor only as an IPC transport to make sure MemoryIntArray manges its backing fd. Bug:30310689 Change-Id: Ib3cc13ef4ae2a744e5f7a96099570e0431847bce (cherry picked from commit fe2462f3a60b34ee6b7d8764d92ae58fc0cd7dfd)
/frameworks/base/core/java/android/util/MemoryIntArray.java
|
fe2462f3a60b34ee6b7d8764d92ae58fc0cd7dfd |
|
29-Aug-2016 |
Svetoslav Ganov <svetoslavganov@google.com> |
Properly close fd backing a MemoryIntArray Use ParcelFileDescriptor only as an IPC transport to make sure MemoryIntArray manges its backing fd. Bug:30310689 Change-Id: Ib3cc13ef4ae2a744e5f7a96099570e0431847bce
/frameworks/base/core/java/android/util/MemoryIntArray.java
|
9d723d3d573a53173bd8210be20f0ec622eef8fd |
|
27-Aug-2016 |
Svet Ganov <svetoslavganov@google.com> |
Polish MemoryIntArray 1. Add close guard 2. Adopt instead of clone the ahsmem fd to fix a dangling fd 3. Clear only the return flag when writing fd to parcel 4. Immediately destroy remote MemoryIntArray if stale 5. Throw Java exception if someone closed the fd under us Change-Id: I85533fec336c40e3380e10d5448e18c9616ec341
/frameworks/base/core/java/android/util/MemoryIntArray.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/java/android/util/MemoryIntArray.java
|
53a441ca8eda5a3e6209a952b1bbd32a39e19a1c |
|
20-Apr-2016 |
Svet Ganov <svetoslavganov@google.com> |
Ensure local settings caches are not stale We used the system proterties as a shared memory mechanism to propagate information to local settings caches when the content has changed and the cache should be cleared. The system properties are unfortunately updated asynchronously leading to cases where clients may read stale data. This change adds a simple int array data structure backed by shared memory which guarantees individual values are atomically read and updated without memory tear. Multi- index opearations are not synchronized between each other. The settings provider is using the new data structure to propagate the settings generation which drives when caches are purged. We have a single memory array keeping the generation for different settings tables per user. Since memory array is not a compact data structure and the user space exceeds the memory array size we use an in-memory map from keys to indices in the memory array where the generation id of a key is stored. A key is derived by the setting type in the 4 most significant bits and the user id in the 28 least significant bits. The mapping from a key to an index is cleared if the user is removed and the corresponding index in the memory arry is reset to make it available for other users. The size of the memory array is derived from the max user count that can be created at the same time. bug:18826179 Change-Id: I64009cc5105309ef9aa83aba90b82afc8ad8c659
/frameworks/base/core/java/android/util/MemoryIntArray.java
|