Make sure to increment the parcel data position even when trying to
improperly read from protected data
Bug: 29833520
Test (M): cts-tradefed run cts -c android.os.cts.ParcelTest -m testBinderDataProtection
Test (M): cts-tradefed run cts -c android.os.cts.ParcelTest -m testBinderDataProtectionIncrements
Test: cts-tradefed run cts -m CtsOsTestCases -t android.os.cts.ParcelTest#testBinderDataProtection
Test: cts-tradefed run cts -m CtsOsTestCases -t android.os.cts.ParcelTest#testBinderDataProtectionIncrements
Change-Id: Ie4aae6277fc5f5c924f603d9828c3a608998b986
Merged-In: Ie4aae6277fc5f5c924f603d9828c3a608998b986
(cherry picked from commit 6a825e8ad1a3928dd872bb7c3fbcd94784d77267)
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
If ACTION_OUTSIDE_EVENTS contain information about whether the touch is
obscured, then a pattern of invisible, untouchable, unfocusable
SYSTEM_ALERT_WINDOWS can be placed across the screen to determine
approximate locations of touch events without the user knowing.
Bug: 31097064
Test: cts-tradefed run cts --class android.security.cts.MotionEventTest
Change-Id: Iebbb68231cbb76f87241201e7640a1fe3e188625
CVE-2017-0860
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)
In EventThread, 2 VSYNCs are needed to do composition and update
the client status. So, a 30FPS video may leads to 60FPS VSYNC,
which means the DispSync thread would be waked 60FPS. This is a
unexpected behavior which takes more power consumption. Now we
update the SF status soon after the first VSYNC, which means no
extra VSYNC needed, and the DispSync could be awaked as expected,
and consequently power get saved.
Change-Id: If486eb9b87f109a71f71b510768f15dd733f1233
Orig-Change-Id: I1d3b166021e15a81b2ad770b039761fc2c15fddf
Tracked-On: https://jira01.devtools.intel.com/browse/IMINAN-12211
Category: aosp improvement
Domain: Graphics-SF
Origin: internal
Upstream-Candidate: yes
Signed-off-by: Wang, Yue A <yue.a.wang@intel.com>
Reviewed-on: https://android.intel.com:443/238344
-----BEGIN PGP SIGNATURE-----
iEYEABECAAYFAlfz3S0ACgkQ6K0/gZqxDnhJWgCfRoySrnvsFMmshmNaBf/EqTzK
aLcAmQFWLnkHlnHBkOZDYh8SQlmRpqr1
=qsLC
-----END PGP SIGNATURE-----
Merge tag 'android-6.0.1_r72' into HEAD
Android 6.0.1 Release 72 (M4B30X)
# gpg: Signature made Tue 04 Oct 2016 09:47:41 AM PDT using DSA key ID 9AB10E78
# gpg: Can't check signature: public key not found
-----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
This should be reverted when all system services have been cleaned up to not
do this. A process looking up a service while running in the background will
see the service registered by the active user (assuming the service is
registered on every user switch), not the service registered by the user that
the process itself belongs to.
BUG: 30795333
Change-Id: I1b74d58be38ed358f43c163692f9e704f8f31dbe
(cherry picked from commit e6bbe69ba739c8a08837134437aaccfea5f1d943)
Prevent apps from registering services without relying on selinux checks.
Bug: 29431260
Change-Id: I38c6e8bc7f7cba1cbd3568e8fed1ae7ac2054a9b
(cherry picked from commit f03ba2c0d878071603d73b7f8e9a4a468364ac27)
The previous configuration sets target utilization as .25, which is geared towards
low memory devices. This path increases it to .75 and makes us pass the check:
(heaptargetutilization / 2) * heapsize = heapgrowthlimit
Example:
heapgrowthlimit: 256m
heapsize: 512m
heaptargetutilization: 0.75
0.75/2 * 512 = 192
To pass the check this has to be true:
192 = 256 (WRONG)
Check not passed.
This new configuration is optimized for higher RAM devices and passes the check:
heapgrowthlimit: 384m
heapsize: 1024m
heaptargetutilization: 0.75
0.75/2 * 1024 = 384
384 = 384 (TRUE)
Check passed.
Change-Id: I6839339382229da80546761c3746a032081ff2cd
Signed-off-by: Alex Naidis <alex.naidis@linux.com>
- Check if display id is within display ID range. Negative
display ids lead to undefined behavior in CTS tests.
Change-Id: I2db8caf8d7ac65700e5bc37c180763357cc90aad
CRs-Fixed: 1043297
The stylus eraser appeared not to work, i.e. Android did not respond to
input from the eraser. It turned out that all input except stylus input
is rejected when palm rejection is activated. The problem was that the
eraser itself activates palm rejection when it hovers. The solution is
to allow the eraser during palm rejection. This solution makes sense
because the eraser input works in the exact same way as normal stylus
input.
Change-Id: I9c7451112ce7dbca14a1e1694eedca2d4ed041a1
* If QCOM WFD isn't in use, we'll get -1 here. Don't try and
dig into the array because we'll get some random memory back.
Change-Id: Ib14642fea760dc0e659473bb183c5e0116622302
Pop buffer item from shadow queue only when
number of queued buffer items is greater than zero.
Change-Id: I039bc133842293c29e3e130efd65f521ef0049c6
CRs-Fixed: 1009466
Allow HWC composition of virtual displays for HDMI primary only
when the output pixel format of the HDMI display is RGB.
CRs-Fixed: 1007249
Change-Id: I9680b162d844e9e6397f919e8dcc1b1a948d182c
Add support to draw S3D framebuffer target in case HWC driver
can not handle due to resource or capability issue.
Change-Id: I536fa4a03e246d51891045b692d5dc5be88f2adf
CRs-fixed: 999055
Andrés Domínguez