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
As part of fixing a recent security issue, DownloadManager now needs
to issue Uri permission grants for all downloads. However, if an app
that requested a download is upgraded or otherwise force-stopped,
the required permission grants are removed.
We could tell DownloadManager about the app being stopped, but that
would be racy (due to background broadcast), and waking it up would
degrade system health. Instead, as a special case we now only
consider clearing DownloadManager permission grants when app data
is being cleared.
Bug: 32172542, 30537115
Test: builds, boots, app upgrade doesn't clear grants
Change-Id: I7e3d4546fd12bfe5f81b9fb9857ece58d574a6b9
(cherry picked from commit 23ec811266)
As part of fixing a recent security issue, DownloadManager now needs
to issue Uri permission grants for all downloads. However, if an app
that requested a download is upgraded or otherwise force-stopped,
the required permission grants are removed.
We could tell DownloadManager about the app being stopped, but that
would be racy (due to background broadcast), and waking it up would
degrade system health. Instead, as a special case we now only
consider clearing DownloadManager permission grants when app data
is being cleared.
Bug: 32172542, 30537115
Test: builds, boots, app upgrade doesn't clear grants
Change-Id: I7e3d4546fd12bfe5f81b9fb9857ece58d574a6b9
(cherry picked from commit 23ec811266)
For an app to either send or receive content change notifications,
require that they have some level of access to the underlying
provider.
Without these checks, a malicious app could sniff sensitive user data
from the notifications of otherwise private providers.
Test: builds, boots, PoC app now fails
Bug: 32555637
Change-Id: If2dcd45cb0a9f1fb3b93e39fc7b8ae9c34c2fdef
For an app to either send or receive content change notifications,
require that they have some level of access to the underlying
provider.
Without these checks, a malicious app could sniff sensitive user data
from the notifications of otherwise private providers.
Test: builds, boots, PoC app now fails
Bug: 32555637
Change-Id: If2dcd45cb0a9f1fb3b93e39fc7b8ae9c34c2fdef
The emergency call was not launched in the current user
and therefore was only launching once the user had switched.
Change-Id: If6f3bcf77d88a0658b6e0f91f7e4da5d6264b04f
Fixes: 32424103
Test: manual: switch to secondary user and launch emergency affordance
When a FastScroller is enabled, we were invalidating the
list data during layout, which left the UI in a bad state.
Long-presses didn't work properly, and TalkBack touches
were impossible to perform.
Bug: 31160338
Test: Manually tested long pressing, and verified
that TalkBack now works with the TestActivity in ag/1567328.
Change-Id: Iecd2d597259748a3ecbf5573950e565a0e9faa42
Test: docs only, no test apart from verifying that it builds
Bug: #32158219 clean up InputConnection.commitContent() javadocs
Change-Id: I9b438d6b14aa8bc868fe41f7e0fe22b0e83800fb
Enabling BLE in airplane mode puts BluetoothManagerService in an
unexpected state which causes Bluetooth to be on when airplane mode
is disabled.
Also fixes a bug where a crash of a BLE client would trigger a restart
into ON mode.
Test: SL4A BleBackgroundScanTest:test_airplane_mode_disables_ble
Bug: 32140251
Bug: 32140271
Bug: 32369494
Change-Id: Ie65157e65c3a1ca914f567a7a0c631175d1e5835
(cherry picked from commit bd93b7b3dc6141cef6236cf0ca7dcc5acf5bfeed)
Properly account for VPN apps that make heavy use of the tun
interface. Prior to this change a VPN app could be incorrectly charged
for more data than it actually used if it sent more traffic through
the tun interface than the underlying interface.
This change excludes VPN app traffic on the tun interface from the
adjustment pool and doesn't redistribute traffic to the VPN app.
Instead all of the redistributed traffic is deducted from the VPN app
which effectively represents any overhead incurred by the VPN app.
BUG: 30557871
Change-Id: I62a75a0c0c0111e052b7903baa9f5d6d94ef57fd
ag/1542219 introduced a regression where if the display was the default
display, the configuration would still be adjusted as if it were
a non-default display. This fixes that logic to only adjust the
configuration if the display is non-default.
Bug:32133693
Test: cts-tradefed run cts --module CtsServicesHostTestCases --test android.server.cts.ActivityManagerAppConfigurationTests#testConfigurationUpdatesWhenRotatingToSideFromDocked
Change-Id: Ib2fda8c1651609efa9d20b3e2dace8a122864916
Allows configuring notification and sensor triggers
separately. Introduces a helper class that hosts the
logic for determining what kinds of triggers a device
supports.
Bug: 32073185
Change-Id: Ie7e8eb6b895dcc54e6f972e70642c7248b9e223a
Test: disable "ambient display", sensor triggers should still work
This is a follow up CL to my previous CL [1] that let
IInputConnectionWrapper to call InputContentInfo#requestPermission()
automatically so that temporary URI permissions can be granted
automatically on API 25+ devices whenever
INPUT_CONTENT_GRANT_READ_URI_PERMISSION is specified.
However, in that CL we forgot to handle exceptions thrown from
InputContentInfo#requestPermission(). This is problematic because it is
actually easy for IMEs to cause SecurityException by specifying a
content URI that does not allow grantUriPermission, e.g.:
inputConnection.commitContent(
new InputContentInfo(Uri.parse("content://call_log/test"),
new ClipDescription("test", new String[]{"image/gif"}));
As a result, IMEs can let the application crash at any time because
InputContentInfo#requestPermission() is automatically called inside the
Framework.
This CL makes sure that exceptions thrown from
InputContentInfo#requestPermission() can be handled gracefully.
[1]: Id955435dd2e72549ee7134f46b3c6951581694ad
f3806f57a5
Bug: 32162481
Change-Id: I08916a1f54518390d3b67ab1673dc901e3f9716a
Fix a bug where the DisplayMetrics wouldn't be updated for a Resources
object on the default display. Since multi-window, we want to update
all Resources.
This didn't always manifest itself due to recreation of assets, which
would force an update of DisplayMetrics. Re-use of an AssetManager from
the cache would expose the bug.
Bug:32133693
Bug:31998629
Test: cts-tradefed run cts --module CtsServicesHostTestCases
Change-Id: Ic51ab82710517b87eb995ccf982085dba876ad58
Ignore every filesystem entity that is not a regular file or directory.
In particular, we now ignore not only symlinks but also sockets, pipes,
et cetera.
Bug 32143362
Change-Id: If51b54df1f7a643af145eb15bf12d389d19f8780
