Skip to content

GitLab

Switch branch/tag
  1. 30 Nov, 2016 2 commits
    • Fabien Sanglard's avatar
      Fix SF security vulnerability: 32660278 · cb7eff6a
      Fabien Sanglard authored 
      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)
      cb7eff6a
    • Casey Dahlin's avatar
      Fix integer overflow in unsafeReadTypedVector · 8163b881
      Casey Dahlin authored 
      Passing a size to std::vector that is too big causes it to silently
under-allocate when exceptions are disabled, leaving us open to an OOB
write. We check the bounds and the resulting size now to verify
allocation succeeds.

Test: Verified reproducer attached to bug no longer crashes Camera
      service.
Bug: 31677614

Change-Id: I064b1442838032d93658f8bf63b7aa6d021c99b7
(cherry picked from commit 65a8f07e57a492289798ca709a311650b5bd5af1)
      8163b881
  3. 01 Nov, 2016 1 commit
    • Jeff Sharkey's avatar
      Check and restorecon cache/code_cache directories. · f14208e0
      Jeff Sharkey authored 
      To speed up boot times, we recently relaxed SELinux restorecon logic
to only consider relabeling app storage when the top level SELinux
label changed.

However, if an app manually deletes either their cache or code_cache
directories, installd will helpfully recreate those directories at
the next boot, but they'll be stuck with incorrect SELinux labels
which an app can't fix.  (Our historically aggressive restorecons had
relabeled them, which is why we didn't observe until now.)

This change checks the labels of the cache/code_cache directories,
and runs a restorecon if needed, fixing the issue above.

Test: delete cache and verify recreated with correct label
Bug: 32504081
Change-Id: I0114ae4129223e5909b1075d56a9b1145ebc5ef4
(cherry picked from commit 397ec266753a675e6891c479971e6506491b1b44)
      f14208e0
  5. 26 Oct, 2016 2 commits
  7. 25 Oct, 2016 6 commits
  9. 23 Oct, 2016 1 commit
  11. 21 Oct, 2016 1 commit
  13. 19 Oct, 2016 2 commits
  15. 12 Oct, 2016 1 commit
  17. 11 Oct, 2016 1 commit
    • Wei Wang's avatar
      Move atrace init into on fs trigger · f920891b
      Wei Wang authored 
      sysfs should be ready on ealier stage than boot

Bug: 32025203
Test: take systrace
Change-Id: Id73b6959f3075dc793d93551963193a211060da8
      f920891b
  19. 05 Oct, 2016 1 commit
  21. 04 Oct, 2016 1 commit
  23. 02 Oct, 2016 1 commit
  25. 30 Sep, 2016 1 commit
  27. 28 Sep, 2016 4 commits
  29. 26 Sep, 2016 1 commit
  31. 25 Sep, 2016 1 commit
  33. 22 Sep, 2016 2 commits
    • Rob Carr's avatar
      Merge "Surface: Add force disconnection method." into nyc-mr1-dev · 6cc1933a
      Rob Carr authored
      6cc1933a
    • Jeff Sharkey's avatar
      Recursively restorecon when SELinux label changes. · 993de796
      Jeff Sharkey authored 
      PackageManager has been pretty aggressive about asking installd to
restorecon over app data when it thinks something might have
changed.  However, in the vast majority of cases these are no-op
requests, and we waste a bunch of time recursively walking all
private data, easily costing 60+ seconds on dogfooder devices.

This change updates the initial "create_app_data" command to kick off
a recursive restorecon if it detects that the top-level SELinux label
on the app private data directory changes.  The "create_app_data"
command is designed to ensure that an app's storage is ready, so
PackageManager always calls it at least once per boot before apps
can run.  (This change means that PackageManager no longer needs to
make separate "restorecon_app_data" calls.)

Test: booted, verified that a label change triggered restorecon
Bug: 30768146
Change-Id: I0c8d4018cf8ff888d0ae07a82adc3d61a6002aad
      993de796
  35. 18 Sep, 2016 1 commit
  37. 15 Sep, 2016 1 commit
    • Dan Stoza's avatar
      HWC2On1: Fall back to GLES for SolidColor · 5df47cb6
      Dan Stoza authored 
      Even though SolidColor layers map cleanly to HWC_BACKGROUND composition
in HWC1, SurfaceFlinger never used HWC_BACKGROUND, so we can't trust
that HWC1 devices implemented it correctly. To preserve backwards
compatibility, this changes the behavior to fall back to client
composition to minimize incompatibilities with existing devices.

Bug: 30479781
Change-Id: I638339062e03f2c057b3e1624e7157587ddee7ec
      5df47cb6
  39. 14 Sep, 2016 2 commits
  41. 13 Sep, 2016 5 commits
  43. 12 Sep, 2016 2 commits