Skip to content

Instantly share code, notes, and snippets.

@invisiblek invisiblek/-
Created Feb 10, 2017

What would you like to do?
commit c639cb67b4310b80aeddb4184dc191a24b23e9ca (tag: android-7.1.1_r21, tag: android-7.1.1_r20, upstream/nougat-mr1.3-release)
Author: Philip P. Moltmann <>
Date: Tue Dec 13 16:32:06 2016 -0800
Do not write if apply() did not change the file.
Bug: 33385963
Test: SharedPreferences CTS tests
Change-Id: I39955f8fbcdaa54faa539a3c503e12cb00808136
(cherry picked from commit 1f99f81bdc5e8430717def157f4abe1176d6a88e)
commit 06276708d6e0a3d3cfa8dee7e7b4be06cde52469
Author: Philip P. Moltmann <>
Date: Tue Dec 13 16:23:21 2016 -0800
Only persist last Shared Preferences state
If multiple async shared preferences writes are queued, all but the
last one can be ignored as they will be overwritten by the last one
For commit() we need to make sure that we have at least persisted the
state of the commit.
Generation counts are 64 bit, hence they never overflow.
Test: Produced a lot of SharedPreferences.Editor.apply and did not see
excessive writes anymore, ran SharedPreferences CTS tests
Bug: 33385963
Change-Id: I3968ed4b71befee6eeb90bea1666a0bb646544f6
(cherry picked from commit 31d6889f4c89dd8498e2095f9d8a3c39fbd17c86)
(cherry picked from commit d15c4f1da58de847ebdecdfade96d21ba8128929)
commit 70e13cc6830c081dd67290e3e55a17c091a44365
Author: Svet Ganov <>
Date: Thu Dec 15 14:51:17 2016 -0800
[DO NOT MERGE] Fix vulnerability in MemoryIntArray - fix build file
Change-Id: If0431b77ec546c72f8cc25bb605a851572bb22a6
(cherry picked from commit c3db570a0064b2dcbe806ddb5de3f678623612ca)
commit de5e34583e1111b50eb04cd7e77d0084a2e8b78a
Author: Svetoslav Ganov <>
Date: Thu Dec 8 11:48:19 2016 -0800
Fix vulnerability in MemoryIntArray
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.
Change-Id: I1004579181ff7a223ef659e85c46100c47ab2409
(cherry picked from commit a97171ec499fd876722733f35e51d0d6dbd8d223)
commit 36772fc2263e06972add737660392afd246da15e
Author: Jeff Sharkey <>
Date: Wed Nov 30 16:07:00 2016 -0700
DO NOT MERGE. Retain DownloadManager Uri grants when clearing.
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 23ec811266fb728cf159a90ce4882b3c9bac1887)
(cherry picked from commit 6eee8e37fd06bd47dd19b8503bc30cc8ccaf72a7)
commit db57376d6ccbd4d3e39fc35aa8cfb561bbca4bac
Author: Jeff Sharkey <>
Date: Wed Nov 16 17:22:48 2016 -0700
DO NOT MERGE: Check provider access for content changes.
For an app to either send or receive content change notifications,
require that they have some level of access to the underlying
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
(cherry picked from commit c813f5dae231bd8f01864227c5dba10d43a89249)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.