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
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
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
- When Accessibility is turned on, Android Wear devices become unusable.
Add an option to disable animations, will be disabled in an overlay.
Bug: 24985771
Change-Id: If5fc44705d56579b305abd48a0d820f306b9be10
The split ambient settings default to on - which is a bad experience
if the user explicitly turned it off before the split.
Change-Id: Id80d62727952f63b363f87c19b5befbde8ab5c31
Merged-In: I986d35a1a28e97f4c8d7d3d47ed5658e1836a44f
Merged-In: I346a53b0dc9cdf578c238113f4f33056ba0f3aea
Fixes: 32332195
Test: Flash angler to NYC, disable ambient, upgrade to NYC-MR1, check if "Lift to check phone" is still off.
The split ambient settings default to on - which is a bad experience
if the user explicitly turned it off before the split.
Change-Id: I346a53b0dc9cdf578c238113f4f33056ba0f3aea
Merged-In: I986d35a1a28e97f4c8d7d3d47ed5658e1836a44f
Fixes: 32332195
Test: Flash angler to NYC, disable ambient, upgrade to NYC-MR1, check if "Lift to check phone" is still off.
This change adds historical operations to the dump state
of the settings provider. The historica operations are
currently appended only on user-debug and eng builds.
These change is needed to help diagnose the referred
bug and improve the settings provider's maintenance.
bug:30561721
Change-Id: I58a1ba0d598c4d28adcb5e654ebb78cf947e94db
Adds "panic" detection to the back button. Implemented solution
uses 4x button presses in a short duration to detect for "panic".
The value used to determine the duration between key up and key down
that still count as a multi-button press is configurable via the
Settings Provider.
BUG: 28027764
Change-Id: Ibf1370ff3cb539a9a54002a8704922744a3ca5d7
If the device being upgraded happens to have a timeout of
500ms it will be reset to 400. If the value is something
else it will be left alone upon upgrade.
Bug: 30159825
Change-Id: Ifec70e458ce0199b61d36f7504aea02b4a974990
- Removed Secure.ACCESSIBILITY_DISPLAY_COLOR_MATRIX, it's not desirable
to persist the actual color transformation matrix.
- Refactored all SurfaceFlinger transforms to DisplayTransformManager,
which allows color transforms to be set independently from the a11y
manager service.
Bug: 30042357
Change-Id: Iefa477dedb66aac90e1218e327802a3fab6899ed
Currently we used global setting to restrict user from enabling oem
unlock. As global settings can be chagned using adb, using user
restrictions instead.
Bug: 29893399
Change-Id: Ic83112a4838b8279bf50408a29ae205e0b8639ee
