9 numaralı kodla (SEGV_MTESERR) veya 8 numaralı kodla (SEGV_MTEAERR) SIGSEGV kilitlenmeleri, bellek etiketleme hatasıdır. Bellek Etiketleme Uzantısı (MTE), Android 12 ve sonraki sürümlerde desteklenen bir Armv9 özelliğidir. MTE, etiketli belleğin donanım uygulamasıdır. Bellek güvenliği hatalarını tespit etmek ve azaltmak için ayrıntılı bellek koruması sağlar.
C/C++'ta malloc() veya operatör new() ya da benzer işlevlerin çağrısından döndürülen bir işaretçi, yalnızca ilgili ayırmanın sınırları içindeki belleğe erişmek için ve yalnızca ayırma etkinken (serbest bırakılmamış veya silinmemişken) kullanılabilir. Android'de MTE, bu kuralın ihlallerini tespit etmek için kullanılır. Bu ihlaller, kilitlenme raporlarında "Arabellek Taşması"/"Arabellek Alt Taşması" ve "Boşaltıldıktan Sonra Kullanım" sorunları olarak adlandırılır.
MTE'nin iki modu vardır: eşzamanlı (veya "sync") ve eşzamansız (veya "async"). İlk yöntem daha yavaş çalışır ancak daha doğru teşhisler sunar. İkincisi daha hızlı çalışır ancak yalnızca yaklaşık ayrıntılar verebilir. Teşhisler biraz farklı olduğundan her ikisini de ayrı ayrı ele alacağız.
Eşzamanlı mod MTE
MTE'nin eşzamanlı ("sync") modunda SIGSEGV, 9 koduyla (SEGV_MTESERR) kilitleniyor.
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)
Tüm MTE kilitlenme raporları, sorunun tespit edildiği noktanın normal kayıt dökümünü ve geri izlemesini içerir. MTE tarafından algılanan bir hatanın "Nedeni:" satırında, yukarıdaki örnekte olduğu gibi "[MTE]" ifadesinin yanı sıra daha fazla ayrıntı yer alır. Bu durumda, algılanan hata türü "Serbest bırakıldıktan sonra kullanma" idi ve "0x7ae92853a0 adresindeki 32 baytlık bir ayırmada 0 bayt" ifadesi, ayırmanın boyutunu ve adresini ve ayırmada erişmeye çalıştığımız ofseti bize bildirir.
MTE kilitlenme raporları, yalnızca algılama noktasından gelen geri izlemeyi değil, ek geri izlemeleri de içerir.
"Serbest Bırakıldıktan Sonra Kullanma" hataları, kilitlenme dökümüne "ayrılma nedeni" ve "ayrılma zamanı" bölümleri ekler. Bu bölümlerde, bu belleğin ayrıldığı andaki (kullanılmadan önce) yığın izlemeleri ve daha önce ayrıldığı zaman gösterilir. Bu bilgiler, hangi iş parçacığının ayırma/ayırma işlemini gerçekleştirdiğini de belirtir. Bu basit örnekte algılama, ayırma ve ayırma ipliklerinin üçü de aynıdır ancak gerçek dünyadaki daha karmaşık durumlarda bu durum her zaman geçerli değildir. Bu ipliklerin farklı olduğunu bilmek, eşzamanlılıkla ilgili bir hatayı bulma konusunda önemli bir ipucu olabilir.
"Arabellek Aşımı" ve "Arabellek Alt Aşımı" hataları, tanımı gereği henüz tahsisleri kaldırılmadığı için yalnızca ek bir "tahsis eden" yığın izlemesi sağlar (veya "Serbest Bırakıldıktan Sonra Kullanma" olarak görünür):
Cause: [MTE]: Buffer Overflow, 0 bytes right of a 32-byte allocation at 0x7ae92853a0 [...] backtrace: [...] allocated by thread 13949:
Burada "sağ" kelimesinin kullanıldığına dikkat edin: Bu, yanlış erişimin, ayırmanın sonundan kaç bayt sonra olduğunu size bildirdiğimiz anlamına gelir. Aşırı akışın "sol" olarak adlandırıldığını ve ayırmanın başlangıcından kaç bayt önce olduğunu belirttiğini unutmayın.
Birden fazla olası neden
Bazen SEGV_MTESERR raporları aşağıdaki satırı içerir:
Note: multiple potential causes for this crash were detected, listing them in decreasing order of likelihood.
Bu durum, hatanın kaynağı için birkaç iyi aday olduğunda ve gerçek nedeni belirleyemediğimizde ortaya çıkar. Bu tür en fazla 3 adayı olasılık sırasına göre yazdırır ve analizi kullanıcıya bırakırız.
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...]Yukarıdaki örnekte, aynı bellek adresinde, geçersiz bellek erişiminin hedefi olabilecek iki yeni atama tespit ettik. Bu durum, ayrımlar boş belleği yeniden kullandığında ortaya çıkabilir. Örneğin, yeni, boş, yeni, boş, yeni, boş, erişim gibi bir sıranız varsa bu durumla karşılaşabilirsiniz. En son tahsis önce yazdırılır.
Ayrıntılı neden belirleme kuralları
Bir kilitlenmenin "Nedeni", erişilen işaretçinin orijinal olarak türetildiği bellek tahsisini göstermelidir. Maalesef MTE donanımı, eşleşmeyen etikete sahip bir işaretçiyi bir ayırmaya çeviremez. Android, SEGV_MTESERR kilitlenmesinin nedenini açıklamak için aşağıdaki verileri analiz eder:
- Hata adresi (işaretçi etiketi dahil).
- Yığın izleme ve bellek etiketleri içeren son yığın ayırmalarının listesi.
- Yakındaki mevcut (canlı) ayırmalar ve bellek etiketleri.
Bellek etiketinin hata adresi etiketiyle eşleştiği hata adresinde yakın zamanda ayrılmış bellek, "Serbest Bırakıldıktan Sonra Kullanma" sorununun olası bir nedenidir.
Bellek etiketinin hata adresi etiketiyle eşleştiği yakındaki herhangi bir canlı bellek, olası bir "Arabellek Aşımı" (veya "Arabellek Alt Akışı") nedenidir.
Hataya zaman veya mekân açısından daha yakın olan tahsisler, uzak olanlardan daha olası kabul edilir.
Ayrılan bellek genellikle yeniden kullanıldığından ve farklı etiket değerlerinin sayısı az olduğundan (16'dan az) birkaç olası aday bulmak yaygındır ve asıl nedeni otomatik olarak bulmak mümkün değildir. Bu nedenle, MTE raporlarında bazen birden fazla olası neden listelenir.
Uygulama geliştiricinin, en olası nedenden başlayarak olası nedenleri incelemesi önerilir. Yığın izlemeye göre alakasız nedenleri filtrelemek genellikle kolaydır.
Eşzamansız mod MTE
MTE'nin zaman uyumsuz ("async") modunda SIGSEGV, 8 koduyla (SEGV_MTEAERR) kilitleniyor.
SEGV_MTEAERR hataları, bir program geçersiz bellek erişimi gerçekleştirdiğinde hemen gerçekleşmez. Sorun etkinlikten kısa bir süre sonra tespit edilir ve program bu noktada sonlandırılır. Bu nokta genellikle bir sonraki sistem çağrısıdır ancak zamanlayıcı kesintisi de olabilir. Kısacası, kullanıcı alanından çekirdek alanına geçişin herhangi bir noktası olabilir.
SEGV_MTEAERR hataları, bellek adresini korumaz (her zaman "-------" olarak gösterilir). Geri izleme, geçersiz erişimin yapıldığı ana değil, durumun algılandığı ana (ör. sonraki sistem çağrısında veya başka bir bağlam geçişinde) karşılık gelir.
Bu, asenkron MTE kilitlenmesinde "ana" geri izlemenin genellikle alakalı olmadığı anlamına gelir. Bu nedenle, ayarsız moddaki hatalarda hata ayıklama işlemi, senkronize moddaki hatalara kıyasla çok daha zordur. Bu mesajlar, belirli bir ileti dizisindeki yakın kodda bellek hatası olduğunu gösterir. Mezar taşı dosyasının alt kısmındaki günlükler, aslında ne olduğuna dair ipucu verebilir. Aksi takdirde, önerilen işlem, hatayı senkronizasyon modunda yeniden oluşturmak ve senkronizasyon modunun sunduğu daha iyi teşhisleri kullanmaktır.
İleri seviye konular
Bellek etiketleme, her yığın tahsisine rastgele bir 4 bitlik (0..15) etiket değeri atayarak çalışır. Bu değer, ayrılan yığın belleğine karşılık gelen özel bir meta veri bölgesinde saklanır. malloc() veya operator new() gibi işlevlerden döndürülen yığın işaretçisinin en önemli baytına da aynı değer atanır.
İşlemde etiket kontrolü etkinleştirildiğinde CPU, her bellek erişimi için işaretçinin üst baytını bellek etiketiyle otomatik olarak karşılaştırır. Etiketler eşleşmezse CPU, kilitlenmeye neden olan bir hata sinyali gönderir.
Olası etiket değerlerinin sayısı sınırlı olduğundan bu yaklaşım olasılıksaldır. Belirli bir işaretçiyle erişilmemesi gereken tüm bellek konumları (ör. sınırların dışında veya tahsis iptal edildikten sonra ("boş işaretçi")) farklı bir etiket değerine sahip olabilir ve kilitlenmeye neden olabilir. Hataların hiçbirinin algılanmama olasılığı yaklaşık% 7'dir. Etiket değerleri rastgele atandığından, hatanın bir sonraki seferde tespit edilme olasılığı bağımsız olarak yaklaşık% 93'tür.
Etiket değerleri, aşağıda vurgulandığı gibi hata adresi alanında ve kayıt dökümünde görülebilir. Bu bölüm, etiketlerin makul bir şekilde ayarlanıp ayarlanmadığını kontrol etmek ve raporda listelenenlerin dışında hatanın olası nedenleri olabileceğinden aynı etiket değerine sahip diğer yakın bellek tahsislerini görmek için kullanılabilir. Bunun geliştiriciler yerine daha çok MTE'nin veya diğer düşük düzey sistem bileşenlerinin uygulanmasıyla ilgili çalışanlar için yararlı olacağını umuyoruz.
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
Kilitlenme raporunda, hata adresinin etrafındaki bellek etiketlerini gösteren özel bir "Bellek etiketleri" bölümü de görünür. Aşağıdaki örnekte, "4" işaretçi etiketi "a" bellek etiketiyle eşleşmemiştir.
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
Bir mezar taşının, tüm kayıt değerlerinin etrafındaki bellek içeriklerini gösteren bölümleri, etiket değerlerini de gösterir.
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 ..'.}...........