Fix a bug where a malformed Parceled representation
of an AccessibilityNodeInfo could be used to mess with
Bundles as they get reparceled.
Bug: 36491278
Test: Verified that POC no longer works, a11y cts still passes.
Change-Id: I10f24747e3ab87d77cd1deba56db4526e3aa5441
(cherry picked from commit 687bb44b43)
A recent security fix prevents the system UID from handing out Uri
permission grants directly from itself. Instead, services need to
issue grants as the original calling UID to ensure that the caller
actually has access to the Uris.
Test: builds, boots, send/recv MMS works in primary/secondary users
Bug: 33231106
Change-Id: Ia9fe19843b52977c8a94ee5349b907beda1882fc
Merged-In: Ia9fe19843b52977c8a94ee5349b907beda1882fc
(cherry picked from commit 7ff418d9a9)
System server is no longer allowed to grant uri permission directly. As a result
we use grantUriPermissionFromIntent() to grant permission from the shell UID,
who is the owner of the bug report content.
Also fix a security bug where the broadcast to notify user consent of remote
bug report mismatches the <protected-broadcast> definition, causing it to be
sendable by anyone.
Bug: 34159108
Test: manual - Install TestDPC and request bugreport, try accept and decline
once the report is ready (Bullhead).
Merged-In: I66e3f2a16d4547549f09d3c96d52aed2330caedf
Change-Id: I66e3f2a16d4547549f09d3c96d52aed2330caedf
A recent security fix prevents the system UID from handing out Uri
permission grants directly from itself. Instead, services need to
issue grants as the original calling UID to ensure that the caller
actually has access to the Uris.
Test: builds, boots, send/recv MMS works in primary/secondary users
Bug: 33231106
Change-Id: Ia9fe19843b52977c8a94ee5349b907beda1882fc
(cherry picked from commit 7ff418d9a9)
A recent security fix prevents the system UID from handing out Uri
permission grants directly from itself. Instead, services need to
issue grants as the original calling UID to ensure that the caller
actually has access to the Uris.
Test: builds, boots, send/recv MMS works in primary/secondary users
Bug: 33231106
Change-Id: Ia9fe19843b52977c8a94ee5349b907beda1882fc
(cherry picked from commit 7ff418d9a9)
On FBE devices, don't save the metrics to disk but compute them when the
password is first entered and only store them in RAM.
Merged-in: 5daf273b7e
Bug: 32793550
Change-Id: Icee7f615167761177b224b342970a36c7d90f6ba
Avoid potential race condition between FRP wipe and write operations
during factory reset by making the FRP partition unwritable after
wipe.
Bug: 30352311
Test: manual
Change-Id: If3f024a1611366c0677a996705724458094fcfad
(cherry picked from commit a629c772f4)
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
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
