Memory tagging detected. May be a system compromise?

CGG

I got a memory tag detection from an attack on whatsapp. My question is: it was just detected or the memory tagging was effective on blocking lhe hack attempt? The log is below:

type: crash
osVersion: google/komodo/komodo:15/BP1A.250505.005/2025062700:user/release-keys
userType: full.secondary
package: com.whatsapp:251880000, targetSdk 35
process: com.whatsapp
installer: com.android.vending

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0000000000001013

backtrace:
NOTE: Function names and BuildId information is missing for some frames due
NOTE: to unreadable libraries. For unwinds of apps, only shared libraries
NOTE: found under the lib/ directory are readable.
NOTE: On this device, run setenforce 0 to make the libraries readable.
NOTE: Unreadable libraries:
NOTE: /data/user/15/com.whatsapp/files/decompressed/libs.spo/libessential.so
#00 pc 0000000000023078 /data/user/15/com.whatsapp/files/decompressed/libs.spo/libessential.so
#01 pc 0000000000022b18 /data/user/15/com.whatsapp/files/decompressed/libs.spo/libessential.so
#02 pc 0000000000021e8c /data/user/15/com.whatsapp/files/decompressed/libs.spo/libessential.so
#03 pc 00000000000218b8 /data/user/15/com.whatsapp/files/decompressed/libs.spo/libessential.so
#04 pc 000000000000f200 /data/user/15/com.whatsapp/files/decompressed/libs.spo/libessential.so
#05 pc 0000000000394f00 /apex/com.android.art/lib64/libart.so (art_quick_generic_jni_trampoline+144) (BuildId: 74229eb3e4846c28b10d56ebbabe2198)
#06 pc 00000000034f2184 /data/app/xn3IVbKI7lISEz4wrs-gjg==/com.whatsapp-Err5Qh95jfGeXTEXYSi2A==/oat/arm64/base.odex (X.10R.A00+1156)
#07 pc 0000000002bb5364 /data/app/xn3IVbKI7lISEz4wrs-gjg==/com.whatsapp-Err5Qh95jfGeXTEXYSi2A==/oat/arm64/base.odex (X.00n.run+52)
#08 pc 00000000034f08f0 /data/app/xn3IVbKI7lISEz4wrs-gjg==/com.whatsapp-Err5Qh95jfGeXTEXYSi2A==/oat/arm64/base.odex (X.10Q.A01+1760)
#09 pc 00000000034f0f70 /data/app/xn3IVbKI7lISEz4wrs-gjg==/com.whatsapp-Err5Qh95jfGeXTEXYSi2A==/oat/arm64/base.odex (X.10Q.A03+48)
#10 pc 0000000002baa334 /data/app/xn3IVbKI7lISEz4wrs-gjg==/com.whatsapp-Err5Qh95jfGeXTEXYSi2A==/oat/arm64/base.odex (com.whatsapp.AbstractAppShellDelegate.installAnrDetector+452)
#11 pc 0000000002bae81c /data/app/xn3IVbKI7lISEz4wrs-gjg==/com.whatsapp-Err5Qh95jfGeXTEXYSi2A==/oat/arm64/base.odex (com.whatsapp.AbstractAppShellDelegate.onCreate+3196)
#12 pc 0000000002ba80f4 /data/app/xn3IVbKI7lISEz4wrs-gjg==/com.whatsapp-Err5Qh95jfGeXTEXYSi2A==/oat/arm64/base.odex (X.006.onCreateWithHiltReady+756)
#13 pc 0000000002ba8ed8 /data/app/xn3IVbKI7lISEz4wrs-gjg==/com.whatsapp-Err5Qh95jfGeXTEXYSi2A==/oat/arm64/base.odex (X.009.onCreate+312)
#14 pc 00000000002ade30 /system/framework/arm64/boot-framework.oat (android.app.Instrumentation.callApplicationOnCreate+48) (BuildId: 7c976f836a4f99302e38df49f289b32b55f4c9c2)
#15 pc 000000000022ea28 /system/framework/arm64/boot-framework.oat (android.app.ActivityThread.handleBindApplication+5256) (BuildId: 7c976f836a4f99302e38df49f289b32b55f4c9c2)
#16 pc 000000000022802c /system/framework/arm64/boot-framework.oat (android.app.ActivityThread$H.handleMessage+8220) (BuildId: 7c976f836a4f99302e38df49f289b32b55f4c9c2)
#17 pc 00000000004b8528 /system/framework/arm64/boot-framework.oat (android.os.Handler.dispatchMessage+152) (BuildId: 7c976f836a4f99302e38df49f289b32b55f4c9c2)
#18 pc 00000000004ed2a0 /system/framework/arm64/boot-framework.oat (android.os.Looper.loopOnce+976) (BuildId: 7c976f836a4f99302e38df49f289b32b55f4c9c2)
#19 pc 00000000004ece54 /system/framework/arm64/boot-framework.oat (android.os.Looper.loop+244) (BuildId: 7c976f836a4f99302e38df49f289b32b55f4c9c2)
#20 pc 00000000002377bc /system/framework/arm64/boot-framework.oat (android.app.ActivityThread.main+1564) (BuildId: 7c976f836a4f99302e38df49f289b32b55f4c9c2)
#21 pc 000000000037de60 /apex/com.android.art/lib64/libart.so (art_quick_invoke_static_stub+640) (BuildId: 74229eb3e4846c28b10d56ebbabe2198)
#22 pc 000000000036c77c /apex/com.android.art/lib64/libart.so (_jobject* art::InvokeMethod<(art::PointerSize)8>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject, _jobject, jobject, unsigned long)+892) (BuildId: 74229eb3e4846c28b10d56ebbabe2198)
#23 pc 00000000006c2504 /apex/com.android.art/lib64/libart.so (art::Method_invoke(JNIEnv, _jobject, _jobject, jobjectArray) (.uniq.165753521025965369065708152063621506277)+36) (BuildId: 74229eb3e4846c28b10d56ebbabe2198)
#24 pc 00000000002ce1a4 /system/framework/arm64/boot.oat (art_jni_trampoline+116) (BuildId: aa30d0107f68521d3d1b9c43ed9360fbd3a4498f)
#25 pc 000000000079d714 /system/framework/arm64/boot-framework.oat (com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run+116) (BuildId: 7c976f836a4f99302e38df49f289b32b55f4c9c2)
#26 pc 00000000007c9d44 /apex/com.android.art/lib64/libart.so (nterp_helper+7636) (BuildId: 74229eb3e4846c28b10d56ebbabe2198)
#27 pc 0000000000238ed0 /system/framework/framework.jar (com.android.internal.os.ExecInit.main+88)
#28 pc 000000000037de60 /apex/com.android.art/lib64/libart.so (art_quick_invoke_static_stub+640) (BuildId: 74229eb3e4846c28b10d56ebbabe2198)
#29 pc 000000000037c9a0 /apex/com.android.art/lib64/libart.so (art::JValue art::InvokeWithVarArgs<jmethodID>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject, jmethodID, std::va_list)+784) (BuildId: 74229eb3e4846c28b10d56ebbabe2198)
#30 pc 0000000000740640 /apex/com.android.art/lib64/libart.so (art::JNI<false>::CallStaticVoidMethodV(JNIEnv, _jclass, jmethodID, std::va_list)+144) (BuildId: 74229eb3e4846c28b10d56ebbabe2198)
#31 pc 00000000000fb48c /system/lib64/libandroid_runtime.so (JNIEnv::CallStaticVoidMethod(_jclass, _jmethodID, ...)+108) (BuildId: 391f9b511678b8184389350e2a7a4a5c)
#32 pc 000000000011bda4 /system/lib64/libandroid_runtime.so (android::AndroidRuntime::callMain(android::String8 const&, jclass, android::Vector<android::String8> const&)+340) (BuildId: 391f9b511678b8184389350e2a7a4a5c)
#33 pc 00000000000049e8 /system/bin/app_process64 (android::AppRuntime::onStarted()+72) (BuildId: 7e4d389e6aa317d3112b88b81bcf0451)
#34 pc 00000000007e4ed8 /system/framework/arm64/boot-framework.oat (art_jni_trampoline+104) (BuildId: 7c976f836a4f99302e38df49f289b32b55f4c9c2)
#35 pc 00000000007c8008 /apex/com.android.art/lib64/libart.so (nterp_helper+152) (BuildId: 74229eb3e4846c28b10d56ebbabe2198)
#36 pc 00000000002498f8 /system/framework/framework.jar (com.android.internal.os.RuntimeInit.main+48)
#37 pc 000000000037de60 /apex/com.android.art/lib64/libart.so (art_quick_invoke_static_stub+640) (BuildId: 74229eb3e4846c28b10d56ebbabe2198)
#38 pc 000000000037c9a0 /apex/com.android.art/lib64/libart.so (art::JValue art::InvokeWithVarArgs<jmethodID>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject, jmethodID, std::va_list)+784) (BuildId: 74229eb3e4846c28b10d56ebbabe2198)
#39 pc 0000000000740640 /apex/com.android.art/lib64/libart.so (art::JNI<false>::CallStaticVoidMethodV(JNIEnv, _jclass, jmethodID, std::va_list)+144) (BuildId: 74229eb3e4846c28b10d56ebbabe2198)
#40 pc 00000000000fb48c /system/lib64/libandroid_runtime.so (JNIEnv::CallStaticVoidMethod(_jclass, _jmethodID, ...)+108) (BuildId: 391f9b511678b8184389350e2a7a4a5c)
#41 pc 000000000012077c /system/lib64/libandroid_runtime.so (android::AndroidRuntime::start(char const*, android::Vector<android::String8> const&, bool)+908) (BuildId: 391f9b511678b8184389350e2a7a4a5c)
#42 pc 00000000000045b0 /system/bin/app_process64 (main+1232) (BuildId: 7e4d389e6aa317d3112b88b81bcf0451)
#43 pc 0000000000060688 /apex/com.android.runtime/lib64/bionic/libc.so (libc_init+120) (BuildId: 76b3eba33cd561e774657995ea2278a4)

fid02

CGG code 1 (SEGV_MAPERR)

This is not from memory tagging. Memory tagging will show up in the log as code 9 (SEGV_MTESERR): https://source.android.com/docs/security/test/memory-safety/mte-reports#synchronous-mode-mte

GrapheneOS

CGG This isn't related to memory tagging. It's very likely a null pointer dereference leading to the crash, although what caused that is unclear. You can tell it's a null pointer dereference because the fault address is so close to 0 meaning that it's likely an offset into a large structure or array from 0. 0x0000000000001013 is 4115, as in 4115 bytes from the start of the address space, which is within the reserved region for this purpose. This is some form of memory corruption bug in WhatsApp but it's being caught by the OS. If you have memory tagging enabled for user installed apps, then it's not a use-after-free causing this via the zero-on-free protection since that would be caught by memory tagging in any typical case. Therefore, it's likely some other kind of bug leading to a null pointer dereference.

Titan_M2

I got a memory tag detection from an attack on whatsapp.

How do you know it was an attack?

CGG

My whatsapp account was highjacked by session cookies but the hacker left something more... After that happened i was trying recovering the account with the same APP, at the time of recover using 2fa, the APP crashed and graphene promptly send me a notification of memory tag detection

wuseman

CGG My whatsapp account was highjacked by session cookies but the hacker left something more...

How does one steal a session cookie for a WhatsApp account? In the app?

CGG

Well that log showed up when i receive and tapped to show more.

CGG

wuseman using phishing tools available in github...

jacksmith

Memory tagging exception(or "error") happens when you have faulty low-level code in your app, probably a type of pointer mismanagement.

It could be an attack.. But some apps' code just sucks, that the default state is tripping the memory tagging exception. WhatsApp is known to be one of those apps. You probably have to disable MTE and maybe one or more security settings. And if there's an attack, it should reasonably remain within the confines of taking control of WhatsApp i.e. the attacker will have same access and abilities as WhatsApp.

If you want to keep using WhatsApp and keep a higher level of seperation, you can use a seperate user just for WhatsApp. It will not increase your protection, but when WhatsApp is hacked or decides to act out against your interests, it will be fully isolated from your main user.

Oh and also, sometimes you may not get notification that the MTE is getting tripped; do keep in mind that, it might be the reason why a specific app crashes.

CGG

jacksmith well this is whatsapp from google store after a successful session stole which disconected my session in whatsapp. I do exactly as you say and evento can been seen in the log i pasted. User15. Another user for whatsapp. But as i never seen a memory tag message before and this happened exactly after my account stolen.. Something is not correct. I will never disable memory tagging for whatsapp.

CGG

jacksmith i agree with you. Whatsapp is one of those worst bugged apps. But never in months, heavy using it, i received this tagging notification. Just exactly when i was under attack... Its curious..

wuseman

CGG
Yeah, but how? Only WhatsApp can access the WhatsApp cookies.

CGG

wuseman lol... Whatsapp , instagram are one of the most exploited platforms ever... But i use it for work.
So i have to deal with this.

wuseman

CGG
WhatsApp isn't easily exploited. Do you have a source for this crazy claim?

Stealing the WhatsApp session token on GrapheneOS would require a GrapheneOS vulnerability.

CGG

GrapheneOS thanks for the explanation. I use memory tag for all applications and users. Thanks. I was thinking, after the attack the hacker may have use some corrupted message to prevent me from recover my account by sending something to overflow the application crashing it... There are tools that are available that do those crashes.

CGG

wuseman make a little research to find out how bugged whatsapp is. Its prohibited from use by some US gov agencies. It has nothing related with graphene. Sessions cookies are managed by the APP not by the OS.
There are hundreds if not 1000 tools that exploit whatsapp. Its not my first time... Already happened to me more than once.

wuseman

CGG
No, I'm not gonna "make a little research" about something that you and you alone are claiming here.

Yes, session cookies are managed by the app and not the OS. So how would someone steal them from you?

CGG

Despite the time from the log pasted and the notification events diferent, this is the graphene notification sent to me at the same time the log was generated when the attack was happening. I just cant explain the time difference between the log and notifications.

https://imgur.com/a/3A0AA3P

Oh and sorry.. Its in portuguese...

CGG

I have never seen whatapp try to use native code debugging also before today.

matchboxbananasynergy

CGG This isn't new.

locked

I have memory tagging enabled for WhatsApp and it is always crashing, it just shuts down, particularly when i turn phone on, but it' consistent. I deal with it because i don't want to turn off memory tagging.

userofgos

locked Yeah I get it all the time too. On another note, does calling on WhatsApp work without the phone permission?

I used to have Exploit protection compatibility mode turned on for WhatsApp but decided to try disabling it again and seeing if it's usable with MTE, Native code debugging disabled, Dynamic code loading via memory and storage disabled.

locked

userofgos I am uncertain about that, I don't worry too much about the phone app, since I don't have a sim card, and I am always on airplane mode. However whatsapp calls do work without giving it network access.