Super SU v.2.76 stable
-
-
http://forum.supersu.com/ - © 2016 Coding Code Mobile Technolgy
[size=18]XDA [Stable](2016.09.01)SuperSU v2.78 Release
https://www.facebook.com/SuperSU-1024576694301637/?ref=br_rs[/SIZE]
[size=18]BETA-SuperSU-v2.77-20160827190633.zip[/SIZE]
-
Update
The latest test release is:
SR1-SuperSU-v2.78-SR1-20160915123031.zip
That is a recovery flashable ZIP (I recommend FlashFire or TWRP). If you want to install via APK, it is also present inside the ZIP, in the common folder.BETA-SuperSU-v2.77-20160827190633.zip
Changelogs
15.09.2016 - v2.78 - SR1 - RELEASE NOTES
- subinary: Adjust app_process detection with manipulated mount namespaces
- subinary: Adjust Zygote PID detection to prefer 64-bit
- subinary: Fix possible NPE in LD_PRELOAD sanitization
- subinary: In systemless mode, ensure PATH contains /su/bin and /su/xbin
- supolicy: Ensure zero-on-alloc for new rules
- supolicy: Fix parsing allowxperm with multiple sources/targets in a single definition
- ZIP/Systemless: Give su.d 60 seconds to execute (from 4 seconds) -
Finde diese Infos dürfen nicht fehlen...
Besonders für manch Panikmacher ohne den so wichtigen Aluhut! :moustach:
ZitatSuperSU v2.78 SR1 released
This update brings primarily bugfixes to the su binary (related to suhide and Magisk compatibility), but there is one supolicy update of particular note as well:
supolicy
Due to an initialization bug, introduced in v2.68 BETA, some SELinux contexts (including shell and untrusted_app) could be granted sys_module capability. If this happens, and your kernel is compiled with module loading support (most modern stock kernels have this disabled) and an exploit is used to gain uid 0, this then allows for a complete SELinux bypass and kernel pwn.The requirements are pretty extensive and your chances of being vulnerable are slim, but nevertheless I would recommend updating.
This fix requires SuperSU to be updated by flashing the ZIP. Updating by APK will not suffice.
SRx instead of BETA
We're moving from BETA to Service Release naming, so we can keep the version number for the next test release the same as the current stable release. So, v2.78 SR1 is what would have been v2.79 BETA before.While this may be slightly more confusing, we need to keep the version numbers the same to reduce the effectiveness of people trying to upload the test releases to stores (many stores will not accept a version number already present). Surprisingly, this is a real problem on non-Play stores.
CCMT
Discussion regarding CCMT has suddenly (about a year late) become prominent again. There will be some announcements regarding this probably next week. -
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!