Status Update
No update yet.
Comments
da...@gmail.com
vi...@google.com
Thanks again for the feedback! Our product and engineering teams have evaluated the request and responded:
Hello,
An MTE-specific strlen (and all string.h family of functions) is necessary and desirable to detect buffer-overflow bugs.
The example you mention, vector.push_back(toCppString(**).c_str()), is a great example of the type of
Some of those specific examples of use-after-free bugs are begnign, however they're still undefined behaviour. MTE catching them is the desired functionality.
da...@gmail.com
Thanks for your reply. I can understand that and I found a new case that the __memchr_aarch64_mte called by strstr could give a MTE error if the input pointer has not been aligned by 16 bytes. I think it is a bug,right? test case:
char *data = (char*)calloc(128,1);
memset(data, 'A', 128);
char *str2 = "BBbbbaa";
char *res = strstr(data+2, str2);
vi...@google.com
The backtrace for the test case:
signal 11 (SIGSEGV), code 9 (SEGV_MTESERR), fault addr 0x0200007b9b4e67e0
Cause: [MTE]: Buffer Overflow, 0 bytes right of a 128-byte allocation at 0x7b9b4e6760
***
backtrace:
#00 pc 0000000000092fe0 /apex/com.android.runtime/lib64/bionic/libc.so (__strchr_aarch64_mte+96) (BuildId: cfc293be733954571ce0dc79a9917039)
#01 pc 00000000000e8f88 /apex/com.android.runtime/lib64/bionic/libc.so (strstr+24) (BuildId: cfc293be733954571ce0dc79a9917039)
#02 pc 00000000000017d8 /data/local/tmp/a.out (main+116)
Oh,sorry that the case I give above is for the __strchr_aarch64_mte, and the case for __memchr_aarch64_mte is below.
char *data = (char*)calloc(128,1);
memset(data, 'A', 128);
char *str2 = "ABbbbAa";
char *res = strstr(data+2, str2);
and the backtrace of the __memchr_aarch64_mte case:
signal 11 (SIGSEGV), code 9 (SEGV_MTESERR), fault addr 0x0f000074794803b0
Cause: [MTE]: Buffer Overflow, 0 bytes right of a 128-byte allocation at 0x7479480330
***
backtrace:
#00 pc 000000000009268c /apex/com.android.runtime/lib64/bionic/libc.so (__memchr_aarch64_mte+12) (BuildId: cfc293be733954571ce0dc79a9917039)
#01 pc 00000000000e92c0 /apex/com.android.runtime/lib64/bionic/libc.so (twoway_strstr+464) (BuildId: cfc293be733954571ce0dc79a9917039)
I think the __strchr_aarch64_mte and __memchr_aarch64_mte has the same problem that they preread 16 bytes and if there are two MTE tag in a single bytes chunk, a MTE exception would raise. And that is caused without any wrong operations by developer.
kc...@google.com
cu...@google.com
Sorry and I give another issue for that. 317403451
Description
Version used:1.0.1
Theme used: Theme.AppCompat.Light.DarkActionBar
Devices/Android versions reproduced on: pixel 2 Android 10, Emulator API 27&29
- Relevant code to trigger the issue: equal to the documentation:
and using setDeviceCredentialAllowed(true)
I implemented the new androidx.biometric:biometric:1.0.1 as described in the documentation and using setDeviceCredentialAllowed(true). On API 29 it works correctly, on API < 29 when there aren't any device credentials set I would expect to get ERROR_NO_DEVICE_CREDENTIAL but I'm getting ERROR_USER_CANCELED, is this a library bug or if not what am I missing?
Since the documenation says this library is backwards compatible I would expect I don't need to handle anything myself for API<29, right?
As I could see in BiometricPrompt.java there is a code-block:
case DeviceCredentialHandlerBridge.RESULT_ERROR:
// Device credential auth failed. Assume this is due to the user canceling.
final CharSequence errorMsg = getActivity() != null
? getActivity().getString(R.string.generic_error_user_canceled) : "";
mAuthenticationCallback.onAuthenticationError(
BiometricConstants.ERROR_USER_CANCELED, errorMsg);
bridge.stopIgnoringReset();
bridge.reset();
break;
Don't know why the lib is returning a generic error code in form of ERROR_USER_CANCELED, nothing of this is documented in BiometricConstants.java.