Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

FORTIFY: pthread_mutex_lock called on a destroyed mutex #2038

Open
oShcherbininSuper opened this issue Dec 18, 2023 · 1 comment
Open

FORTIFY: pthread_mutex_lock called on a destroyed mutex #2038

oShcherbininSuper opened this issue Dec 18, 2023 · 1 comment
Labels
bug new

Comments

@oShcherbininSuper
Copy link

oShcherbininSuper commented Dec 18, 2023 •
edited

System (please complete the following information):

  • Android 9-13
  • Kernel version (if applicable): [e.g. 5.10]
  • strongSwan version(s): 5.9.11
  • Tested/confirmed with the latest version: [no]

Describe the bug
From the Android platform when launched by alarm or work manager native function executeJob it can crash when mutex is destroyed:
public native void executeJob(String id);

To Reproduce
Steps to reproduce the behavior:
Run executeJob native method when the mutex is destroyed
public native void executeJob(String id);

Expected behavior
We could ignore logic if mutex is destroyed

Logs/Backtraces

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 18833 >>> com.example <<<

backtrace:
FORTIFY: pthread_mutex_lock called on a destroyed mutex (0x<sanitized>)
  #00  pc 0x0000000000078974  /apex/com.android.runtime/lib64/bionic/libc.so (abort+180)
  #01  pc 0x00000000000dc9d4  /apex/com.android.runtime/lib64/bionic/libc.so (__fortify_fatal(char const*, ...)+124)
  #02  pc 0x00000000000dbebc  /apex/com.android.runtime/lib64/bionic/libc.so (HandleUsingDestroyedMutex(pthread_mutex_t*, char const*)+52)
  #03  pc 0x00000000000dbd14  /apex/com.android.runtime/lib64/bionic/libc.so (pthread_mutex_lock+172)
  #04  pc 0x00000000001d56d0  /data/app/~~ILMKSKfjTC6pbJwuMtjWrw==/com.example-yVTnsyBarsI_Uj8X5I50qQ==/lib/arm64/libstrongswan.so (lock) (BuildId: 94a1d9b48539f88a4d2c56b1a1b45653caeab93e)
  #05  pc 0x00000000001d4ba8  /data/app/~~ILMKSKfjTC6pbJwuMtjWrw==/com.example-yVTnsyBarsI_Uj8X5I50qQ==/lib/arm64/libstrongswan.so (thread_current+140) (BuildId: 94a1d9b48539f88a4d2c56b1a1b45653caeab93e)
  #06  pc 0x00000000001d4bf8  /data/app/~~ILMKSKfjTC6pbJwuMtjWrw==/com.example-yVTnsyBarsI_Uj8X5I50qQ==/lib/arm64/libstrongswan.so (thread_current_id+8) (BuildId: 94a1d9b48539f88a4d2c56b1a1b45653caeab93e)
  #07  pc 0x000000000000c310  /data/app/~~ILMKSKfjTC6pbJwuMtjWrw==/com.example-yVTnsyBarsI_Uj8X5I50qQ==/lib/arm64/libandroidbridge.so (segv_handler) (BuildId: 4b339dd190eef765ffaa5049082542aee38732b3)
  #08  pc 0x0000000000004e78  /system/bin/app_process64 (art::SignalChain::Handler(int, siginfo*, void*)+328)
  #09  pc 0x0000000000000628  [vdso] (__kernel_rt_sigreturn)
  #10  pc 0x00000000000095e4  /data/app/~~ILMKSKfjTC6pbJwuMtjWrw==/com.example-yVTnsyBarsI_Uj8X5I50qQ==/lib/arm64/libandroidbridge.so (Java_org_strongswan_android_logic_Scheduler_executeJob+32) (BuildId: 4b339dd190eef765ffaa5049082542aee38732b3)
  #11  pc 0x0000000000217698  /data/app/~~ILMKSKfjTC6pbJwuMtjWrw==/com.example-yVTnsyBarsI_Uj8X5I50qQ==/oat/arm64/base.odex

second version:

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 13608 >>> com.example <<<

backtrace:
  #00  pc 0x0000000000062eee  /apex/com.android.runtime/lib/bionic/libc.so (abort+138)
  #01  pc 0x0000000000064203  /apex/com.android.runtime/lib/bionic/libc.so (__fortify_fatal(char const*, ...)+26)
  #02  pc 0x00000000000aebc1  /apex/com.android.runtime/lib/bionic/libc.so (HandleUsingDestroyedMutex(pthread_mutex_t*, char const*)+24)
  #03  pc 0x00000000000aea7f  /apex/com.android.runtime/lib/bionic/libc.so (pthread_mutex_lock+150)
  #04  pc 0x000000000011e3d0  /data/app/~~y10PewVfaAML9GBKYXQrrA==/ com.example-yh-V1Id4Sf1_PE5BzoJ7LQ==/lib/arm/libstrongswan.so (lock) (BuildId: 702d52e3d8c27aa4fe1402433407cb33397b812a)
  #05  pc 0x000000000011d710  /data/app/~~y10PewVfaAML9GBKYXQrrA==/ com.example-yh-V1Id4Sf1_PE5BzoJ7LQ==/lib/arm/libstrongswan.so (thread_current+156) (BuildId: 702d52e3d8c27aa4fe1402433407cb33397b812a)
  #06  pc 0x000000000011d78c  /data/app/~~y10PewVfaAML9GBKYXQrrA==/ com.example-yh-V1Id4Sf1_PE5BzoJ7LQ==/lib/arm/libstrongswan.so (thread_current_id+8) (BuildId: 702d52e3d8c27aa4fe1402433407cb33397b812a)
  #07  pc 0x000000000000a8ec  /data/app/~~y10PewVfaAML9GBKYXQrrA==/ com.example-yh-V1Id4Sf1_PE5BzoJ7LQ==/lib/arm/libandroidbridge.so (segv_handler) (BuildId: e37594cd013a5afee892bbde8330d5332081759d)
  #08  pc 0x0000000000002321  /apex/com.android.art/lib/libsigchain.so (art::SignalChain::Handler(int, siginfo*, void*)+648)
  #09  pc 0x000000000005d9b4  /apex/com.android.runtime/lib/bionic/libc.so (__restore_rt)
  #10  pc 0x0000000000007680  /data/app/~~y10PewVfaAML9GBKYXQrrA==/ com.example-yh-V1Id4Sf1_PE5BzoJ7LQ==/lib/arm/libandroidbridge.so (Java_org_strongswan_android_logic_Scheduler_executeJob+28) (BuildId: e37594cd013a5afee892bbde8330d5332081759d)
  #11  pc 0x0000000000148f1d  /apex/com.android.art/lib/libart.so (art_quick_generic_jni_trampoline+44)
  #12  pc 0x00000000020f404b  /memfd:jit-cache (org.strongswan.android.logic.Scheduler$scheduleJob$1.invokeSuspend+898)
  #13  pc 0x00000000020fd825  /memfd:jit-cache (kotlin.coroutines.jvm.internal.a.resumeWith+164)
  #14  pc 0x000000000200a7db  /memfd:jit-cache (dy.z0.run+1946)
  #15  pc 0x0000000002012733  /memfd:jit-cache (dy.h1.d1+146)
  #16  pc 0x000000000204ee93  /memfd:jit-cache (dy.a1.e+338)
  #17  pc 0x000000000204162f  /memfd:jit-cache (dy.a1.a+398)
  #18  pc 0x00000000020bfa15  /memfd:jit-cache (dy.p.t+92)
  #19  pc 0x00000000020ceb11  /memfd:jit-cache (dy.p.z+64)
  #20  pc 0x00000000020cf339  /memfd:jit-cache (fy.c.B+152)
  #21  pc 0x00000000020df94b  /memfd:jit-cache (fy.c.u+66)
  #22  pc 0x00000000020670a7  /memfd:jit-cache (fy.b$a.i+222)
  #23  pc 0x00000000020a7b57  /memfd:jit-cache (fy.b.I0+614)
  #24  pc 0x00000000020496dd  /memfd:jit-cache (fy.b.O0+500)
  #25  pc 0x00000000020def2d  /memfd:jit-cache (fy.b.B+100)
  #26  pc 0x00000000020fe2fb  /memfd:jit-cache (fy.o.V0+538)
  #27  pc 0x000000000032fb6c  /apex/com.android.art/lib/libart.so (nterp_helper+2908)
  #28  pc 0x000000000089682a  /data/app/~~y10PewVfaAML9GBKYXQrrA==/ com.example-yh-V1Id4Sf1_PE5BzoJ7LQ==/oat/arm/base.vdex (fy.o.W0+22)
  #29  pc 0x000000000032fb00  /apex/com.android.art/lib/libart.so (nterp_helper+2800)
  #30  pc 0x00000000008965de  /data/app/~~y10PewVfaAML9GBKYXQrrA==/ com.example-yh-V1Id4Sf1_PE5BzoJ7LQ==/oat/arm/base.vdex (fy.o.w+2)
  #31  pc 0x00000000003304ac  /apex/com.android.art/lib/libart.so (nterp_helper+5276)
  #32  pc 0x00000000008959c0  /data/app/~~y10PewVfaAML9GBKYXQrrA==/ com.example-yh-V1Id4Sf1_PE5BzoJ7LQ==/oat/arm/base.vdex (fy.e.w+4)
  #33  pc 0x0000000000330568  /apex/com.android.art/lib/libart.so (nterp_helper+5464)
  #34  pc 0x0000000000221b64  /data/app/~~y10PewVfaAML9GBKYXQrrA==/ com.exampleyh-V1Id4Sf1_PE5BzoJ7LQ==/oat/arm/base.vdex (androidx.lifecycle.n$a.p)
  #35  pc 0x000000000032f048  /apex/com.android.art/lib/libart.so (nterp_helper+56)
  #36  pc 0x0000000000221b2c  /data/app/~~y10PewVfaAML9GBKYXQrrA==/ com.examplen-yh-V1Id4Sf1_PE5BzoJ7LQ==/oat/arm/base.vdex (androidx.lifecycle.n$a.m)
  #37  pc 0x000000000032f048  /apex/com.android.art/lib/libart.so (nterp_helper+56)
  #38  pc 0x0000000000221778  /data/app/~~y10PewVfaAML9GBKYXQrrA==/ com.example-yh-V1Id4Sf1_PE5BzoJ7LQ==/oat/arm/base.vdex (androidx.lifecycle.m.a+4)
  #39  pc 0x00000000020f6371  /memfd:jit-cache (androidx.lifecycle.LiveData.c+240)
  #40  pc 0x00000000020ee59d  /memfd:jit-cache (androidx.lifecycle.LiveData.d+396)
  #41  pc 0x00000000020f2795  /memfd:jit-cache (androidx.lifecycle.LiveData.n+148)
  #42  pc 0x000000000032fb6c  /apex/com.android.art/lib/libart.so (nterp_helper+2908)
  #43  pc 0x00000000002246d4  /data/app/~~y10PewVfaAML9GBKYXQrrA==/ com.example-yh-V1Id4Sf1_PE5BzoJ7LQ==/oat/arm/base.vdex (androidx.lifecycle.j0.n)
  #44  pc 0x00000000020ea553  /memfd:jit-cache (androidx.lifecycle.LiveData$a.run+290)
  #45  pc 0x000000000091c0ef  /data/misc/apexdata/com.android.art/dalvik-cache/arm/boot.oat (android.os.Handler.dispatchMessage+70)
  #46  pc 0x000000000091f1cb  /data/misc/apexdata/com.android.art/dalvik-cache/arm/boot.oat (android.os.Looper.loopOnce+882)
  #47  pc 0x000000000091edcf  /data/misc/apexdata/com.android.art/dalvik-cache/arm/boot.oat (android.os.Looper.loop+1022)
  #48  pc 0x00000000006bcc0b  /data/misc/apexdata/com.android.art/dalvik-cache/arm/boot.oat (android.app.ActivityThread.main+2210)
  #49  pc 0x00000000001419d5  /apex/com.android.art/lib/libart.so (art_quick_invoke_stub_internal+68)
  #50  pc 0x00000000001bb041  /apex/com.android.art/lib/libart.so (void art::quick_invoke_reg_setup<true>(art::ArtMethod*, unsigned int*, unsigned int, art::Thread*, art::JValue*, char const*) (.__uniq.192663596067446536341070919852553954320.llvm.17112358095869631794)+112)
  #51  pc 0x00000000001bab9f  /apex/com.android.art/lib/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+134)
  #52  pc 0x000000000029e9dd  /apex/com.android.art/lib/libart.so (_jobject* art::InvokeMethod<(art::PointerSize)4>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jobject*, _jobject*, unsigned int)+1100)
  #53  pc 0x00000000004c492f  /apex/com.android.art/lib/libart.so (art::Method_invoke(_JNIEnv*, _jobject*, _jobject*, _jobjectArray*) (.__uniq.165753521025965369065708152063621506277)+22)
  #54  pc 0x000000000031c289  /data/misc/apexdata/com.android.art/dalvik-cache/arm/boot.oat (art_jni_trampoline+56)
  #55  pc 0x00000000008a473f  /data/misc/apexdata/com.android.art/dalvik-cache/arm/boot.oat (com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run+118)
  #56  pc 0x00000000008ad067  /data/misc/apexdata/com.android.art/dalvik-cache/arm/boot.oat (com.android.internal.os.ZygoteInit.main+3134)
  #57  pc 0x00000000001419d5  /apex/com.android.art/lib/libart.so (art_quick_invoke_stub_internal+68)
  #58  pc 0x00000000001bb041  /apex/com.android.art/lib/libart.so (void art::quick_invoke_reg_setup<true>(art::ArtMethod*, unsigned int*, unsigned int, art::Thread*, art::JValue*, char const*) (.__uniq.192663596067446536341070919852553954320.llvm.17112358095869631794)+112)
  #59  pc 0x00000000001bab9f  /apex/com.android.art/lib/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+134)
  #60  pc 0x00000000001ee501  /apex/com.android.art/lib/libart.so (art::JValue art::InvokeWithVarArgs<art::ArtMethod*>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, art::ArtMethod*, std::__va_list)+268)
  #61  pc 0x0000000000106315  /apex/com.android.art/lib/libart.so (art::JValue art::InvokeWithVarArgs<_jmethodID*>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, std::__va_list)+24)
  #62  pc 0x0000000000470d2f  /apex/com.android.art/lib/libart.so (art::JNI<true>::CallStaticVoidMethodV(_JNIEnv*, _jclass*, _jmethodID*, std::__va_list)+454)
  #63  pc 0x0000000000081a41  /system/lib/libandroid_runtime.so (_JNIEnv::CallStaticVoidMethod(_jclass*, _jmethodID*, ...)+28)
  #64  pc 0x000000000008aa39  /system/lib/libandroid_runtime.so (android::AndroidRuntime::start(char const*, android::Vector<android::String8> const&, bool)+520)
  #65  pc 0x00000000000024fd  /system/bin/app_process32 (main+912)
  #66  pc 0x000000000005c10b  /apex/com.android.runtime/lib/bionic/libc.so (__libc_init+54)
@tobiasbrunner
Copy link
Member

Steps to reproduce the behavior:
Run executeJob native method when the mutex is destroyed

Obviously not a good idea, but does that happen naturally? Note that according to the backtrace there might be some other issue as this seems to be somehow caused in the segmentation fault handler (segv_handler()) when it tries to determine the thread ID (probably because one of the pointers is invalid in executeJob(), so that callback was called after the native parts of the app were already deinitialized. But since flush() (which is called during deinitialization) calls Scheduler::Terminate() it's weird that there would be further calls to executeJob() afterwards (I suppose there could be a race condition between Terminate() and onReceive() but since scheduled jobs are relatively rare that would be quite unlucky).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug new
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tobiasbrunner @oShcherbininSuper