The check added to each non-object reads adds an overhead. If the
objects (binders and file descriptors) were written to the Parcel in
sequential order then check adds a small O(1) overhead to each read,
plus an O(N) overhead to the first read (to verify the N objects were
added in order).
If the objects were written out of order (as in by jumping around the
Parcel
with setDataPosition and writing Binder, DON'T DO THIS!!) (writing non
objects out of order is fine), the first read is forced to sort the
objects
in the internal bookkeeping. Based on the assumption non sequential
writes
are infrequent and overall Parcels are probably mostly sorted, insertion
sort was used. Worst case sorts will add an O(N^2) overhead to the first
non object read from the Parcel.
Test: run cts -m CtsOsTestCases -t android.os.cts.ParcelTest
Bug: 29833520
Change-Id: I82de8eb5f5eb56f869542d5358e96884c24301b2
(cherry picked from commit c517681c66a1a387be657e0cf06da8d19659dd14)
writeInplace() itself already pads securely, by masking off
the padded bytes. If the padding is done before calling
writeInplace(), no mask is applied, and heap data can leak.
Bug: 77237570
Test: builds
Change-Id: Ide27a0002d4ed4196530430760245b971f6a3f44
Merged-In: Ide27a0002d4ed4196530430760245b971f6a3f44
(cherry picked from commit f8542381b72a7bb2452a5278a00ca8c34edbf8a0)
(cherry picked from commit 732132b765cd7b667f16cf32f0fe4c852d7d44dd)
Change-Id: Id65e4573e18ab68b804f1cf63a6977a71da01e5d
Differs slightly from mnc+ patch: GetFlattenedSize was fixed in mnc.
Test: Boot device, run poc from bug, observe no longer crashes
Bug: 37285689
AOSP-Change-Id: Id8b851733b088cce0d07493fbf76e7e24f9299ad
(cherry picked from commit 9809602ac32dcb7bceaa5bc34df5b7fb68aacd38)
CVE-2017-0666
Change-Id: I778c82b363ca0409d534f255cc5d17b39e751986
Checks that the slot number received from mGraphicBufferProducer in
Surface::dequeueBuffer is on the interval [0, NUM_BUFFER_SLOTS) to
protect against a malicious BnGraphicBufferProducer.
Bug: 36991414
AOSP-Change-Id: I1a76fd1bcce1c558f1c0c30f03638278288ed4fa
(cherry picked from commit 90ce2a9c1d3af422c66b4061805831cb208263d8)
CVE-2017-0665
Change-Id: If0fd4864b9fc4ea5a1c83d10adef26cdabb0f7e8
Because of lack of mutex lock when get mConsumerName, if one thread
getConsumerName, another thread setConsumerName frequently, an UAF will
be triggered.
Change-Id: Id1bbf0d15de6d16def2f54ecade385058cda3b65
Test: Marling with poc provided in bug report.
Bug: 32706020
(cherry picked from commit d073eb7a3f28fd74bfa24c8b7599465cb7de5436)
(cherry picked from commit 2e16d5fac149dab3c3e8f1b2ca89f45cf55a7b34)
Because of lack of mutex lock when get mSidebandStream, if one thread
getSidebandStream, another thread setSidebandStream frequently, an UAF
will be triggered.
Bug: 32660278
Test: Marlin device with poc
Change-Id: Idbcf0976ce2db682d0f13455105c45a5c7481a45
(cherry picked from commit 2d8a2432e04234d9edbb3b099f9bbbaa36ad4843)
(cherry picked from commit 675e212c8c6653825cc3352c603caf2e40b00f9f)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEABECAAYFAlfO7kcACgkQ6K0/gZqxDniKDACfe+IKxeKXazFQSWgFI0CW9HUK
nuQAoIomQRV9NOdD2SVHJR1zyTKXx82E
=FStj
-----END PGP SIGNATURE-----
Merge tag 'android-6.0.1_r66' into HEAD
Android 6.0.1 release 66
# gpg: Signature made Tue 06 Sep 2016 09:26:47 AM PDT using DSA key ID 9AB10E78
# gpg: Can't check signature: public key not found
check if device matches the ashmem rdev, before calling
ashmem_get_size_region. This eliminates making this call
when associated with other driver file descriptors.
Bug: 26374183
Bug: 26918423
Bug: 26871259
Change-Id: I1f88c2c93ea35a73c8e14125f3d1a6c67fa4f15b
check if device is a character device, before calling
ashmem_get_size_region. We do not check if the st_rdev
matches /dev/ashmem. So this at least eliminates making
this call when associated with a socket.
Bug: 26374183
Change-Id: I68ed9d1c2cd4c47228ed065e3e18eb4151f038f4
Sending transaction to freed BBinder through weak handle
can cause use of a (mostly) freed object. We need to try to
safely promote to a strong reference first.
Change-Id: Ic9c6940fa824980472e94ed2dfeca52a6b0fd342
(cherry picked from commit c11146106f94e07016e8e26e4f8628f9a0c73199)
* Some legacy Samsung HALs supporting BODY_SENSOR types are
incompatible with the new permission checks added in M.
Extend the NO_SENSOR_PERMISSION_CHECK flags to cover more
of the actual checks.
Change-Id: Id2b9b57d8151b0998d9233e0a6541e8c88e06af7
This is needed by Samsung devices with pre-M sensor
blobs which have support for SENSOR_TYPE_HEART_RATE
or body sensors in general.
These HALs somehow segfault on the flagged code.
Change-Id: I698f4129e71b683f6f063f00da79f32a5f521149
In a4650a5 the concept of a maximum frame number allowance for the consumer was
introduced. A call to acquireBuffers will only return buffers when their frame
number is less-than-or-equal-to this maximum frame number. When SurfaceFlinger
is the consumer, this maximum frame number is calculated in the
onFrameAvailable/onFrameReplaced callbacks. These callbacks are called when a
new buffer is dequeued by the application. The problem is that these callbacks
are called _after_ the fence wait which is used to throttle the frame
production of client apps. When the previous frame needs a long time to draw,
those waits can potentially be a long time. As a result SurfaceFlinger won't do
any composition with the new frame until the wait is over.
Normally this isn't a big problem because there is a queue of buffers for
SurfaceFlinger to work with. However, this changes massively when a client app
is using a swap interval of zero. In this case, a new frame will instantly
replace the previous queued frame. However, SurfaceFlinger doesn't know this
until the onFrameReplaced callback gets called - which is delayed by the fence
wait. If the timing is bad, SurfaceFlinger never gets a chance to pick up a new
frame to do the composition with.
We see this behaviour on our TC development system (slow GPU) with legacy
on-screen benchmarks. Such apps are using a swap interval of zero and sometimes
frames don't get updated for several seconds. This behaviour can be also seen
on a Nexus5, although it isn't as obvious as on our TC.
The fix in this cl is to move the EGL throttling to the end of the queueBuffers
function. This ensures that if a frame gets replaced in the queue, all
consumers who installed the callbacks, get called in a timely fashion.
Change-Id: I36e9ecda162150f41e97d4fb7437963a3d86b371
Signed-off-by: Christian Poetzsch <christian.potzsch@imgtec.com>
The addition of ashmem size tracking can lead to parcel objects
overwriting other values on the stack in old binary blobs.
Change-Id: Ife8514be1ba639c4061de38b59794c46bcc2d7f8
The addition of ashmem size tracking can lead to parcel objects
overwriting other values on the stack in old binary blobs.
Change-Id: Ida52cec851a6f9d5a57c8f9130a5875c03dcb094
Reportedly Mali and PowerVR GPUs are crashing when setting handle to NULL
So we will set a flag for the devices that might need this aswell
Set BOARD_EGL_NEEDS_HANDLE_VALUE=true in BoardConfig.mk to use
Change-Id: I6c967f62dc6adced7583d7b2045d11cf5b25fc80
This reverts c784dfc39f for exynos4 devices
with Mali 400 GPUs, which causes a fatal signal (SIGSEGV) and death of
the graphics subsystem
Change-Id: I6dbf8f8664fca01baf63fece7c64016609fe3e1c
