Los bloqueos de SIGSEGV con el código 9 (SEGV_MTESERR) o el código 8 (SEGV_MTEAERR) son fallas de etiquetado de memoria. La extensión de etiquetado de memoria (MTE) es una característica de Armv9 compatible con Android 12 y versiones posteriores. MTE es una implementación de hardware de memoria etiquetada. Proporciona protección de memoria detallada para la detección y mitigación de errores de seguridad de la memoria .
En C/C++, un puntero devuelto por una llamada a malloc() o al operador new() o funciones similares solo se puede usar para acceder a la memoria dentro de los límites de esa asignación, y solo mientras la asignación esté viva (no liberada ni liberada). eliminar-ed). MTE se utiliza en Android para detectar infracciones de esta regla, a las que se hace referencia en los informes de fallas como problemas de "Desbordamiento de búfer"/"Desbordamiento de búfer" y "Usar después de liberar".
MTE tiene dos modos: síncrono (o "sincrónico") y asíncrono (o "asincrónico"). El primero funciona más lentamente pero proporciona diagnósticos más precisos. Este último corre más rápido, pero solo puede dar detalles aproximados. Cubriremos ambos por separado, ya que los diagnósticos son ligeramente diferentes.
Modo síncrono MTE
En el modo síncrono ("sincronización") de MTE, SIGSEGV falla con el código 9 (SEGV_MTESERR).
pid: 13935, tid: 13935, name: sanitizer-statu >>> sanitizer-status <<< uid: 0 tagged_addr_ctrl: 000000000007fff3 signal 11 (SIGSEGV), code 9 (SEGV_MTESERR), fault addr 0x800007ae92853a0 Cause: [MTE]: Use After Free, 0 bytes into a 32-byte allocation at 0x7ae92853a0 x0 0000007cd94227cc x1 0000007cd94227cc x2 ffffffffffffffd0 x3 0000007fe81919c0 x4 0000007fe8191a10 x5 0000000000000004 x6 0000005400000051 x7 0000008700000021 x8 0800007ae92853a0 x9 0000000000000000 x10 0000007ae9285000 x11 0000000000000030 x12 000000000000000d x13 0000007cd941c858 x14 0000000000000054 x15 0000000000000000 x16 0000007cd940c0c8 x17 0000007cd93a1030 x18 0000007cdcac6000 x19 0000007fe8191c78 x20 0000005800eee5c4 x21 0000007fe8191c90 x22 0000000000000002 x23 0000000000000000 x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000 x28 0000000000000000 x29 0000007fe8191b70 lr 0000005800eee0bc sp 0000007fe8191b60 pc 0000005800eee0c0 pst 0000000060001000 backtrace: #00 pc 00000000000010c0 /system/bin/sanitizer-status (test_crash_malloc_uaf()+40) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #01 pc 00000000000014a4 /system/bin/sanitizer-status (test(void (*)())+132) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #02 pc 00000000000019cc /system/bin/sanitizer-status (main+1032) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #03 pc 00000000000487d8 /apex/com.android.runtime/lib64/bionic/libc.so (__libc_init+96) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) deallocated by thread 13935: #00 pc 000000000004643c /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::quarantineOrDeallocateChunk(scudo::Options, void*, scudo::Chunk::UnpackedHeader*, unsigned long)+688) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #01 pc 00000000000421e4 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::deallocate(void*, scudo::Chunk::Origin, unsigned long, unsigned long)+212) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #02 pc 00000000000010b8 /system/bin/sanitizer-status (test_crash_malloc_uaf()+32) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #03 pc 00000000000014a4 /system/bin/sanitizer-status (test(void (*)())+132) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) allocated by thread 13935: #00 pc 0000000000042020 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::allocate(unsigned long, scudo::Chunk::Origin, unsigned long, bool)+1300) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #01 pc 0000000000042394 /apex/com.android.runtime/lib64/bionic/libc.so (scudo_malloc+36) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #02 pc 000000000003cc9c /apex/com.android.runtime/lib64/bionic/libc.so (malloc+36) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #03 pc 00000000000010ac /system/bin/sanitizer-status (test_crash_malloc_uaf()+20) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #04 pc 00000000000014a4 /system/bin/sanitizer-status (test(void (*)())+132) (BuildId: 953fc93301472d0b72709b2b9a9f6f30)
Todos los informes de fallos de MTE contienen el volcado de registro habitual y el seguimiento del punto en el que se detectó el problema. La línea "Causa:" de un error detectado por MTE contendrá "[MTE]" como en el ejemplo anterior, junto con más detalles. En este caso, el tipo específico de error detectado fue "Usar después de liberar", y "0 bytes en una asignación de 32 bytes en 0x7ae92853a0" nos dice el tamaño y la dirección de la asignación, y el desplazamiento en la asignación que deseamos. trató de acceder.
Los informes de fallas de MTE también incluyen rastreos adicionales, no solo el del punto de detección.
Los errores "Usar después de liberar" agregan las secciones "desasignado por" y "asignado por" al volcado de memoria, mostrando los seguimientos de la pila en el momento en que se desasignó esta memoria (¡antes de que se usara!) y el momento en que se asignó previamente. Estos también le indican qué subproceso realizó la asignación/desasignación. Los tres subprocesos de detección, subproceso de asignación y subproceso de desasignación son iguales en este ejemplo simple, pero en casos más complejos del mundo real esto no es necesariamente cierto, y saber que difieren puede ser una pista importante para encontrar una concurrencia -error relacionado.
Los errores "Desbordamiento de búfer" y "Subdesbordamiento de búfer" solo proporcionan una pista de pila adicional "asignada por", ya que, por definición, aún no se han desasignado (o aparecerán como "Usar después de liberar"):
Cause: [MTE]: Buffer Overflow, 0 bytes right of a 32-byte allocation at 0x7ae92853a0 [...] backtrace: [...] allocated by thread 13949:
Tenga en cuenta el uso de la palabra "correcto" aquí: esto significa que le estamos diciendo cuántos bytes después del final de la asignación fue el acceso incorrecto; un subdesbordamiento diría "izquierda" y sería un número de bytes antes del inicio de la asignación.
Múltiples causas potenciales
A veces, los informes SEGV_MTESERR contienen la siguiente línea:
Note: multiple potential causes for this crash were detected, listing them in decreasing order of likelihood.
Esto sucede cuando hay varios buenos candidatos para el origen del error y no podemos decir cuál es la causa real. Imprimimos hasta 3 de estos candidatos en orden aproximado de probabilidad y dejamos el análisis al usuario.
signal 11 (SIGSEGV), code 9 (SEGV_MTESERR), fault addr 0x400007b43063db5
backtrace:
[stack...]
Note: multiple potential causes for this crash were detected, listing them in decreasing order of probability.
Cause: [MTE]: Use After Free, 5 bytes into a 10-byte allocation at 0x7b43063db0
deallocated by thread 6663:
[stack...]
allocated by thread 6663:
[stack...]
Cause: [MTE]: Use After Free, 5 bytes into a 6-byte allocation at 0x7b43063db0
deallocated by thread 6663:
[stack...]
allocated by thread 6663:
[stack...]En el ejemplo anterior, detectamos dos asignaciones recientes en la misma dirección de memoria que podrían haber sido el objetivo previsto del acceso no válido a la memoria. Esto puede suceder cuando las asignaciones reutilizan la memoria libre, por ejemplo, si tiene la secuencia como nuevo, libre, nuevo, libre, nuevo, libre, acceso. La asignación más reciente se imprime primero.
Heurística detallada de determinación de causa
La "Causa" de un bloqueo debe mostrar la asignación de memoria de la que se derivó originalmente el puntero al que se accedió. Desafortunadamente, el hardware MTE no tiene forma de traducir de un puntero con una etiqueta no coincidente a una asignación. Para explicar un bloqueo de SEGV_MTESERR, Android analiza los siguientes datos:
- La dirección de la falla (incluida la etiqueta del puntero).
- Una lista de asignaciones de montón recientes con seguimientos de pila y etiquetas de memoria.
- Asignaciones cercanas actuales (en vivo) y sus etiquetas de memoria.
Cualquier memoria desasignada recientemente en la dirección de falla donde la etiqueta de memoria coincide con la etiqueta de dirección de falla es una posible causa de "Uso después de libre".
Cualquier memoria viva cercana donde la etiqueta de memoria coincida con la etiqueta de dirección de falla es una posible causa de "desbordamiento de búfer" (o "desbordamiento insuficiente de búfer").
Las asignaciones que están más cerca de la falla, ya sea en el tiempo o en el espacio, se consideran más probables que las que están más lejos.
Dado que la memoria desasignada a menudo se reutiliza y la cantidad de valores de etiqueta diferentes es pequeña (menos de 16), no es raro encontrar varios candidatos probables y no hay forma de encontrar automáticamente la verdadera causa. Esta es la razón por la que a veces los informes de MTE enumeran múltiples causas potenciales.
Se recomienda que el desarrollador de la aplicación analice las posibles causas comenzando por la más probable. A menudo, es fácil filtrar las causas no relacionadas en función del seguimiento de la pila.
Modo asíncrono MTE
En el modo asíncrono ("asincrónico") de MTE, SIGSEGV falla con el código 8 (SEGV_MTEAERR).
Las fallas SEGV_MTEAERR no ocurren inmediatamente cuando un programa realiza un acceso a la memoria no válido. El problema se detecta poco después del evento y el programa finaliza en ese momento. Este punto suele ser la próxima llamada al sistema, pero también puede ser una interrupción del temporizador; en resumen, cualquier transición del espacio de usuario al kernel.
Las fallas SEGV_MTEAERR no conservan la dirección de memoria (siempre se muestra como "-------"). El rastreo corresponde al momento en que se detectó la condición (es decir, en la próxima llamada al sistema u otro cambio de contexto), y no cuando se realizó el acceso no válido.
Esto significa que el seguimiento "principal" en un bloqueo MTE asíncrono generalmente no es relevante . Por lo tanto, las fallas del modo asíncrono son mucho más difíciles de depurar que las fallas del modo de sincronización. Se entienden mejor si muestran la existencia de un error de memoria en el código cercano en el hilo dado. Los registros en la parte inferior del archivo de desecho pueden proporcionar una pista de lo que realmente sucedió. De lo contrario, el curso de acción recomendado es reproducir el error en el modo de sincronización y utilizar los mejores diagnósticos que proporciona el modo de sincronización.
Temas avanzados
Bajo el capó, el etiquetado de memoria funciona mediante la asignación de un valor de etiqueta aleatorio de 4 bits (0..15) a cada asignación de almacenamiento dinámico. Este valor se almacena en una región de metadatos especial que corresponde a la memoria de almacenamiento dinámico asignada. El mismo valor se asigna al byte más significativo del puntero del montón devuelto por funciones como malloc() o el operador new().
Cuando la verificación de etiquetas está habilitada en el proceso, la CPU compara automáticamente el byte superior del puntero con la etiqueta de memoria para cada acceso a la memoria. Si las etiquetas no coinciden, la CPU señala un error que provoca un bloqueo.
Debido al número limitado de posibles valores de etiqueta, este enfoque es probabilístico. Es probable que cualquier ubicación de memoria a la que no se deba acceder con un puntero determinado, como fuera de los límites o después de la desasignación ("puntero colgante"), tenga un valor de etiqueta diferente y provoque un bloqueo. Hay un ~7% de probabilidad de no detectar ningún error. Debido a que los valores de las etiquetas se asignan aleatoriamente, existe una probabilidad independiente de ~93 % de detectar el error la próxima vez que ocurra.
Los valores de la etiqueta se pueden ver en el campo de dirección de falla, así como en el volcado de registro, como se destaca a continuación. Esta sección se puede usar para verificar que las etiquetas estén configuradas correctamente, así como para ver otras asignaciones de memoria cercanas con el mismo valor de etiqueta, ya que pueden ser posibles causas del error más allá de las enumeradas en el informe. Esperamos que esto sea principalmente útil para las personas que trabajan en la implementación de MTE u otros componentes del sistema de bajo nivel, más que para los desarrolladores.
signal 11 (SIGSEGV), code 9 (SEGV_MTESERR), fault addr 0x0800007ae92853a0 Cause: [MTE]: Use After Free, 0 bytes into a 32-byte allocation at 0x7ae92853a0 x0 0000007cd94227cc x1 0000007cd94227cc x2 ffffffffffffffd0 x3 0000007fe81919c0 x4 0000007fe8191a10 x5 0000000000000004 x6 0000005400000051 x7 0000008700000021 x8 0800007ae92853a0 x9 0000000000000000 x10 0000007ae9285000 x11 0000000000000030 x12 000000000000000d x13 0000007cd941c858 x14 0000000000000054 x15 0000000000000000 x16 0000007cd940c0c8 x17 0000007cd93a1030 x18 0000007cdcac6000 x19 0000007fe8191c78 x20 0000005800eee5c4 x21 0000007fe8191c90 x22 0000000000000002 x23 0000000000000000 x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000 x28 0000000000000000 x29 0000007fe8191b70 lr 0000005800eee0bc sp 0000007fe8191b60 pc 0000005800eee0c0 pst 0000000060001000
También aparece una sección especial de "Etiquetas de memoria" en el informe de bloqueo que muestra etiquetas de memoria alrededor de la dirección de la falla. En el siguiente ejemplo, la etiqueta de puntero "4" no coincidía con la etiqueta de memoria "a".
Memory tags around the fault address (0x0400007b43063db5), one tag per 16 bytes: 0x7b43063500: 0 f 0 2 0 f 0 a 0 7 0 8 0 7 0 e 0x7b43063600: 0 9 0 8 0 5 0 e 0 f 0 c 0 f 0 4 0x7b43063700: 0 b 0 c 0 b 0 2 0 1 0 4 0 7 0 8 0x7b43063800: 0 b 0 c 0 3 0 a 0 3 0 6 0 b 0 a 0x7b43063900: 0 3 0 4 0 f 0 c 0 3 0 e 0 0 0 c 0x7b43063a00: 0 3 0 2 0 1 0 8 0 9 0 4 0 3 0 4 0x7b43063b00: 0 5 0 2 0 5 0 a 0 d 0 6 0 d 0 2 0x7b43063c00: 0 3 0 e 0 f 0 a 0 0 0 0 0 0 0 4 =>0x7b43063d00: 0 0 0 a 0 0 0 e 0 d 0 [a] 0 f 0 e 0x7b43063e00: 0 7 0 c 0 9 0 a 0 d 0 2 0 0 0 c 0x7b43063f00: 0 0 0 6 0 b 0 8 0 3 0 0 0 5 0 e 0x7b43064000: 0 d 0 2 0 7 0 a 0 7 0 a 0 d 0 8 0x7b43064100: 0 b 0 2 0 b 0 4 0 1 0 6 0 d 0 4 0x7b43064200: 0 1 0 6 0 f 0 2 0 f 0 6 0 5 0 c 0x7b43064300: 0 1 0 4 0 d 0 6 0 f 0 e 0 1 0 8 0x7b43064400: 0 f 0 4 0 3 0 2 0 1 0 2 0 5 0 6
Las secciones de un desecho que muestran el contenido de la memoria en torno a todos los valores de registro también muestran sus valores de etiqueta.
memory near x10 ([anon:scudo:primary]): 0000007b4304a000 7e82000000008101 000003e9ce8b53a0 .......~.S...... 0700007b4304a010 0000200000006001 0000000000000000 .`... .......... 0000007b4304a020 7c03000000010101 000003e97c61071e .......|..a|.... 0200007b4304a030 0c00007b4304a270 0000007ddc4fedf8 p..C{.....O.}... 0000007b4304a040 84e6000000008101 000003e906f7a9da ................ 0300007b4304a050 ffffffff00000042 0000000000000000 B............... 0000007b4304a060 8667000000010101 000003e9ea858f9e ......g......... 0400007b4304a070 0000000100000001 0000000200000002 ................ 0000007b4304a080 f5f8000000010101 000003e98a13108b ................ 0300007b4304a090 0000007dd327c420 0600007b4304a2b0 .'.}......C{... 0000007b4304a0a0 88ca000000010101 000003e93e5e5ac5 .........Z^>.... 0a00007b4304a0b0 0000007dcc4bc500 0300007b7304cb10 ..K.}......s{... 0000007b4304a0c0 0f9c000000010101 000003e9e1602280 ........."`..... 0900007b4304a0d0 0000007dd327c780 0700007b7304e2d0 ..'.}......s{... 0000007b4304a0e0 0d1d000000008101 000003e906083603 .........6...... 0a00007b4304a0f0 0000007dd327c3b8 0000000000000000 ..'.}...........