Bootloop with November 16 security patches

[Underknowledge]

One plus X on 6.0.1 with OOS 3.1.4 [Oxygen OS3 v2.78 SU.zip]( <-maybe problem?) & x86 xposed

Can install and run Xposed but when i want to start a single module i stuck in bootloop. Tried with diffrent modules like youtube background player, Amplyfy, Gravitybox & More

Also tested v84 - same case. always flashing uninstaller and reflashing.. i try to make logcats? on wednesday - wish me luck Stay tuned =D

[aviraxp]

https://github.com/rovo89/XposedBridge/wiki/Bugs

Generally, I think it is an known issue, which is caused by the November security patches. You can find some details here https://github.com/android/platform_frameworks_base/commit/186af6a4e5a79915ef2917393d36a3266e261f81.

Sadly there is no solution at the moment, unless you know how to build a rom and revert this commit.

Wait, x86 xposed? I think you are saying ARM, otherwise you cannot boot with xposed.

[Underknowledge]

Jeah.. sorry. Version 86 ARM.. Is it helping if i create logcats?

Read 200+ posts on xda. Didnt saw one who pointed Out the November patch.

Do somebody know? Can i Just Flash a oder Version of oos (OnePlus) over it and Flash xposed & superSU again?

[rovo89]

I actually didn't know about this issue either, I don't think anyone brought it up on GitHub before. Someone mentioned the security patches, but I thought this was just a very limited issue.

Logs would definitely help as I don't have the official ROM installed at the moment.

[rovo89]

@aviraxp Did you/someone already verify that the issue is caused by that commit?

[aviraxp]

Not quite sure, but I know that this ROM version contains November security patches, and this commit in the patches, as you see, introduces a whitelist, which does not consider /data/app an open path that zygote is allowed to open, and thus cause the bootloop. It is already confirmed by many people on XDA discussion thread.

Someone has already tried to bypass it by always return true for the bool IsWhiteListed, and it seems works, though has some issues.

[rovo89]

Yes, makes sense. Not sure if /proc/self/fd shows the path like it was opened or if it resolves symlinks. If it does not resolve symlinks, it could probably tricked with /system/framework/../../some/other/path.jar. Otherwise... not sure how this could be circumvented. Probably only by disabling this new security feature, which may be possible by making ReopenOrDetach() a no-op. SELinux might complain about that though...

[rovo89]

Actually, even to disable this feature would be more work as the check is done before Zygote forks... So I would highly recommend not to upgrade at this point if Xposed is more important to you than the potential security increase!

[aviraxp]

Thanks for your insights, symlinks may make sense, or I think bind-mount is another method?Besides, I have noticed that this commit is merged into Nougat several days ago, so I guess the way of Closed on nougat is longer...

[rovo89]

Bind mounts require that the target file already exists.

[aviraxp]

Yes, creating an empty file in advance is fine. Or maybe topjohnwu's magisk works, as it supports creating non-exist files. I will try to play with the possibility these days.

[rovo89]

Nothing of that would be suitable for the official Xposed version though, so I need to find an alternative solution anyway...

[Ibuprophen]

That security update affected the D2VZW CM13 Nightly beginning with the 11 November release.

I was able to install the Xposed installer and restart as normal but, after installing a module (any module), then activating that module, that is when the the restart hangs on the CM splash screen (blue guy at the center).

Framework for the ARM 86 installed fine without any errors.

Just wanted title let you know...

[HanabishiRecca]

I think that is:

• Add CMSDK resource APK to Zygote FD whitelist https://review.cyanogenmod.org/#/c/170201/

Coz http://pastebin.com/1e6XNpU6

Also check: https://review.cyanogenmod.org/#/c/170575/

[aviraxp]

@HanabishiRecca Nah,

https://github.com/android/platform_frameworks_base/blob/186af6a4e5a79915ef2917393d36a3266e261f81/core/jni/com_android_internal_os_Zygote.cpp#L478

It is upstream AOSP commit that causes this.

According to the guy that brought up this commit, he will add more paths to whitelist in the future, but surely not /data/app, which most Xposed modules are in.

[HanabishiRecca]

@aviraxp, I mean this is possible solution for Xposed. What if try to add /data/app to extra whitelist? (just suppose, I'm pretty noob in android) https://review.cyanogenmod.org/#/c/170575/6/core/jni/fd_utils-inl.h https://review.cyanogenmod.org/#/c/170575/6/core/jni/fd_utils-inl-extra.h

[AndyCGYan]

@HanabishiRecca I literally just tried that and it doesn't work - seems like explicit reference to each APK is required. But I'm now trying another approach - I'll just make the whitelist judgement function return true, i.e. whitelist everything. I'll let you know what happens after the build.

[aviraxp]

@HanabishiRecca Ah, sorry... Anyway, recompiling rom is needed, which is far from a common user's knowledge. I am going to fully revert this commit in my own rom.

[AndyCGYan]

@aviraxp How? As you probably saw I posted in the XDA Xposed discussion thread, plain git revert won't work because of conflicts. Do you do a full rebase? // Also, good to see another Chinese here, and you happen to have the same name as one of my classmates O_o

[aviraxp]

@AndyCGYan Maybe it is because CM added some lines to whitelist. You can manually check it.

[arter97]

This would be hacky as hell, but how about making symlink from /data/data/de.robv.android.xposed.installer/files/load.apk to /system/framework/XposedBridge_load.jar upon installation, since every .jar files in /system/framework is allowed?

[rovo89]

That would require modifying /system. This is prevented by read-only partitions and SELinux and would not work on systemless.

[arter97]

Ugh. And I guess modding libandroid_hardware.so will be out of the question, eh?

[AndyCGYan]

2nd test complete and successful - device booted with all Xposed modules enabled!

For ROM builders: manually edit frameworks/base/core/jni/fd_utils-inl.h, find the method IsWhitelisted() and make it return "true" all the time, so that it whitelists everything. Save, commit, build. This should be easier than trying to revert all future whitelist-related changes (I'm a git beginner so no good at that).

EDIT: Arter's description (in #200 above) is more precise and detailed. I'll leave it here nonetheless.

[aviraxp]

@AndyCGYan , @arter97 's this commit would be better, https://github.com/arter97/android_frameworks_base/commit/35724b039e7a990950100354d01467c05756de37, as it detects XposedBridge, so it would be more secure for users who doesn't use Xposed.

[AndyCGYan]

@aviraxp Thanks for the heads up, didn't know he also made it available. I'll just pick that in later builds.

[rovo89]

Here's another idea: Maybe Xposed could avoid keeping those files open at all. I assume that this field keeps the file alive: https://android.googlesource.com/platform/libcore/+/android-6.0.1_r74/dalvik/src/main/java/dalvik/system/DexPathList.java#419 Maybe closing the ZipFile early enough could make it pass the criteria. I can't try this before Wednesday even though.

[wanam]

Yes, i think we can hook and close "zipFile" after "findNativeLibrary" and "findResource" calls and set "initialized" field to false, both methods call "maybeInit();", so i guess we can't expect in which order they will be executed.

Unfortunately i can't test it, i don't have a device that runs this sec patch.

[rovo89]

Not sure if I'd hook these methods. Manipulating the field after loading the module (or even just creating the classloader?) could be sufficient. But yeah, I don't have the possiblity to really test this either at the moment, I could only test whether closing the file has any negative impact and whether this makes the file disappear from /proc/<pid>/fd. Not to forget: What about interpret-only mode, does it require the file to stay opened?

[manuelmagix]

My device bq x5 plus, rom stock, and securite patch level 16/11/1 bug bootloop. And I compiled resurrección remix, patch level 16/11/5, xposed work fine.

[Ibuprophen]

I just wanted to provide the exact words from an email i had received from the CM Dev Dan Pasanen. He is listed here: https://wiki.cyanogenmod.org/w/DevsAOSP

Now here is the response from the email:

Mr Kerr,

ASOP pushed a patch that effectively breaks xposed. At CM we don't support xposed (in fact we don't even take bug reports from users who have it installed). That being said, we don't actively work against it either.

My comments here apply on d2 as well: http://forum.xda-developers.com/showpost.php?p=69631802&postcount=1162

The patch that AOSP pushed is going to require xposed to do something to work around it (or users can compile their own builds with a workaround). CM won't be reverting this new AOSP security measure, for obvious reasons.

Thank you, Dan

[roberto-sartori-gl]

Well i agree with Dan, they shouldn't put Xposed in whitelist. Of course i'm here because i use Xposed but that is not a solution.

[rovo89]

I agree as well, and it wouldn't help us with stock ROMs anyway. Good enough that they don't actively block Xposed, that's all I ask for.

[Underknowledge]

@rovo89 As promised.

https://drive.google.com/open?id=0ByaPe5D8DttOenRUTV9DMEVHWGM

[aviraxp]

@WagnerBeccard

11-16 14:28:25.532 E/Zygote  (  670): Not whitelisted : /data/app/com.pyler.youtubebackgroundplayback-1/base.apk
11-16 14:28:25.532 F/art     (  670): art/runtime/jni_internal.cc:497] JNI FatalError called: frameworks/base/core/jni/com_android_internal_os_Zygote.cpp:478: Unable to construct file descriptor table.

That's exactly what we are talking about above.

[rovo89]

@arter97 Do you have a chance to test the "nov16" branch? https://github.com/rovo89/XposedBridge/commits/nov16 The module APKs are actually opened twice, once for reading the xposed_init file (for which Android implicitly caches the open file, hence I need to open, read, close it manually) and in the ClassLoader itself (for accessing the assets, which should not be needed, hence I close these as well). On Genymotion with a Marshmallow image, this leaves no Xposed-specific file open (according to /proc//fd).

HOWEVER, this is probably not enough in the real world. Creating an Resources/XModuleResources object with the module path (or any other path) will also open the file and keep it open...

[taugimo]

Would it be possible to install the Xposed Modules like systemless SuperSu, which means the apps are no longer located on /data/app? I have no coding knowledge, but as far as I understood this theard, the problem is a chack of /data/app, so if the Modules would not be located there, it might be possible than the check passes(?)

[rovo89]

Also, could someone upload their libandroid_runtime.so? Although I'd really like to avoid nuking this check, it might be necessary (not sure how though), so I have to check which of the new stuff is accessible in the compiled file.

[rovo89]

@Genie3000: No, it's not a problem of /data/app. It's a problem of any file which is not in the whitelist: https://github.com/android/platform_frameworks_base/commit/186af6a4e5a79915ef2917393d36a3266e261f81#diff-7b8d35fc4a3bb7df07f04382a5398a58R38

[AndyCGYan]

@rovo89 https://www.androidfilehost.com/?fid=529152257862682219 - from my own compilation this month before I was aware of the issue. It's an armv7 device by the way.

[shakalaca]

@rovo89 https://mega.nz/#!E0cBQBhR!sEie-2NAlN0NJ5XYm5YSdwIx-YBEjZEiAqirkvmsj3Q - from ZenFone 2 (x86)

[shakalaca]

@rovo89 the patch works on ZenFone 2 (at least it boots up), nice job ! :)

[aviraxp]

@rovo89 https://github.com/aviraxp/Binaries/blob/master/libandroid_runtime.so

I haven't tested the patch myself, but I compile it and let my friends test, seems it does not work.

Logs later.

Edit: Seems it is a rom-specific condition. Some stock rom still have issues, but others works fine.

[HanabishiRecca]

Addition to symlink idea:

* During Xposed installation *
mkdir /system/framework/xhack

* During compilation *
mount tmpfs /system/framework/xhack
...
ln -s /data/app/<module_name>/base.apk /system/framework/xhack/<module_name>.jar

Possible?

[aviraxp]

@HanabishiRecca Possible. But this is not a good way to solve problem...

[HanabishiRecca]

@aviraxp, okay.

Here is my libandroid_runtime.so (both arm&arm64) http://www.mediafire.com/file/5779v51m7qiah32

[aviraxp]

@rovo89 Here is a log with new XposedBridge of Oneplus 3, H2OS.

https://github.com/aviraxp/Binaries/commit/e082719df96482229c958f9a1d0235ce0d31594d

What you said seems make sense.

11-18 14:09:59.075  1882  1882 F libc    : Fatal signal 6 (SIGABRT), code -6 in tid 1882 (main)

11-18 14:09:59.127   844   844 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

11-18 14:09:59.127   844   844 F DEBUG   : Build fingerprint: 'OnePlus/OnePlus3/OnePlus3:6.0.1/MXB48T/361013:user/release-keys'

11-18 14:09:59.127   844   844 F DEBUG   : Revision: '0'

11-18 14:09:59.127   844   844 F DEBUG   : ABI: 'arm64'

11-18 14:09:59.128   844   844 F DEBUG   : pid: 1882, tid: 1882, name: main  >>> zygote64 <<<

11-18 14:09:59.128   844   844 F DEBUG   : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------

11-18 14:09:59.141   844   844 F DEBUG   : Abort message: 'art/runtime/jni_internal.cc:497] JNI FatalError called: frameworks/base/core/jni/com_android_internal_os_Zygote.cpp:483: Unable to construct file descriptor table.'

11-18 14:09:59.142   844   844 F DEBUG   :     x0   0000000000000000  x1   000000000000075a  x2   0000000000000006  x3   0000000000000000

11-18 14:09:59.142   844   844 F DEBUG   :     x4   0000000000000000  x5   0000000000000001  x6   0000000000000000  x7   0000000000000000

11-18 14:09:59.142   844   844 F DEBUG   :     x8   0000000000000083  x9   0000000000017b40  x10  0000000003794040  x11  0000000003794180

11-18 14:09:59.142   844   844 F DEBUG   :     x12  0000000000000000  x13  0000007fb549b000  x14  0000000000000000  x15  0000000000000000

11-18 14:09:59.142   844   844 F DEBUG   :     x16  0000007fb548d568  x17  0000007fb54202fc  x18  0000007fb549ef50  x19  0000007fb58890a8

11-18 14:09:59.142   844   844 F DEBUG   :     x20  0000007fb5888fe8  x21  0000000000000002  x22  0000000000000006  x23  0000007fb25fba00

11-18 14:09:59.142   844   844 F DEBUG   :     x24  0000007fb1e17b40  x25  0000000000000000  x26  0000007fb1e2c000  x27  0000000000000000

11-18 14:09:59.142   844   844 F DEBUG   :     x28  0000007fb25fba00  x29  0000007fed57d9b0  x30  0000007fb541da98

11-18 14:09:59.142   844   844 F DEBUG   :     sp   0000007fed57d9b0  pc   0000007fb5420304  pstate 0000000020000000

11-18 14:09:59.149   844   844 F DEBUG   : 

11-18 14:09:59.149   844   844 F DEBUG   : backtrace:

11-18 14:09:59.149   844   844 F DEBUG   :     #00 pc 0000000000069304  /system/lib64/libc.so (tgkill+8)

11-18 14:09:59.149   844   844 F DEBUG   :     #01 pc 0000000000066a94  /system/lib64/libc.so (pthread_kill+68)

11-18 14:09:59.149   844   844 F DEBUG   :     #02 pc 00000000000239f8  /system/lib64/libc.so (raise+28)

11-18 14:09:59.149   844   844 F DEBUG   :     #03 pc 000000000001e198  /system/lib64/libc.so (abort+60)

11-18 14:09:59.149   844   844 F DEBUG   :     #04 pc 00000000004336c0  /system/lib64/libart.so (_ZN3art7Runtime5AbortEv+324)

11-18 14:09:59.149   844   844 F DEBUG   :     #05 pc 0000000000136f78  /system/lib64/libart.so (_ZN3art10LogMessageD2Ev+3176)

11-18 14:09:59.149   844   844 F DEBUG   :     #06 pc 000000000032c048  /system/lib64/libart.so (_ZN3art3JNI10FatalErrorEP7_JNIEnvPKc+108)

11-18 14:09:59.149   844   844 F DEBUG   :     #07 pc 0000000000132870  /system/lib64/libandroid_runtime.so

11-18 14:09:59.149   844   844 F DEBUG   :     #08 pc 0000000000133d8c  /system/lib64/libandroid_runtime.so

11-18 14:09:59.150   844   844 F DEBUG   :     #09 pc 0000000000134570  /system/lib64/libandroid_runtime.so

11-18 14:09:59.150   844   844 F DEBUG   :     #10 pc 0000000073e98c94  /data/dalvik-cache/arm64/system@framework@boot.oat (offset 0x20d4000)

11-18 14:09:59.190   532   532 I chatty  : uid=0(root) /system/bin/oemlogkit expire 6 lines

11-18 14:09:59.212   844   844 F DEBUG   : 

11-18 14:09:59.212   844   844 F DEBUG   : Tombstone written to: /data/tombstones/tombstone_04

11-18 14:09:59.238   522   522 I ServiceManager: service 'user.xposed.system' died

11-18 14:09:59.245   522   522 I ServiceManager: service 'user.xposed.app' died

[rovo89]

As I said - if any of the module hooks resources, they'll need an XModuleResources instance, which will keep the file open.

Does anyone know which Android releases got this? 6.0, 7.0 and 7.1 definitely have it, how about 5.0/5.1, any reports on stock or custom Lollipop ROMs with that issue? And how about 4.4?

[retsifp]

I have a Fairphone 2 (FP2) and the latest BETA-Version (v. 1.9.3/Android 5.1) doesn't boot when XPosed is installed. This version has 2016-11-05 patchlevel, so I think Android 5.1 is also affected.

[DerVerruckteFuchs]

I have a Samsung SMT-320 that also has the Xposed incompatibility issue with the new CM13 update. Though it seems to be more of hanging indefinitely at boot instead of a bootloop occurring. The workaround I'm using for now is simply downgrading CM to a version before the security patch that introduces the compatibility issue.

[M7ammad-eb]

@rovo89 I might be late.. but here is my libandroid_runtime.so OnePlus 3 OOSbeta7 security patch level 1/11/16

https://drive.google.com/file/d/0B8X_h0OLcwSpUWNBSDBlamd4Rkk/view?usp=drivesdk