一、问题
进程收到SIGABRT信号异常退出，异常调用栈显示__stack_chk_fail
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'Pico/A7H10/PICOA7H10:10/5.5.0/smartcm.1676912090:userdebug/dev-keys'
Revision: '0'
ABI: 'arm64'
Timestamp: 2023-02-23 10:39:19+0800
pid: 933, ppid: -1, tid: 5800, name: pvrmanager >>> /system/bin/stationservice <<<
uid: 0
signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
Abort message: 'stack corruption detected (-fstack-protector)'x0 0000000000000000 x1 00000000000016a8 x2 0000000000000006 x3 000000731f60b4f0x4 0000000000808080 x5 0000000000808080 x6 0000000000808080 x7 0000000000000030x8 00000000000000f0 x9 9c790c62d7456e2d x10 0000000000000001 x11 0000000000000000x12 fffffff0ffffffdf x13 000002bd7a90a09e x14 0031c42fbe3a7800 x15 0000000034155555x16 00000073a2b9fb38 x17 00000073a2b77d40 x18 000000731ea16000 x19 00000000000003a5x20 00000000000016a8 x21 00000000ffffffff x22 00000073a47d949a x23 00000000000003fbx24 000000731f60be20 x25 00000073a47d9000 x26 000000731f60b5b0 x27 00000000000003fcx28 00000000000003fc x29 000000731f60b590sp 000000731f60b4d0 lr 00000073a2b295bc pc 00000073a2b295e8backtrace:#00 pc 00000000000895e8 /apex/com.android.runtime/lib64/bionic/libc.so (abort+160) (BuildId: 02b3bc38eb77bdc99f28c0fc3f17de65)#01 pc 00000000000d7168 /apex/com.android.runtime/lib64/bionic/libc.so (__stack_chk_fail+20) (BuildId: 02b3bc38eb77bdc99f28c0fc3f17de65)#02 pc 0000000000037844 /system/lib64/libstationopticsservice.so (pvr::StationService::StationLogPrint(char*, int)+500) (BuildId: 9943b2f8208bbfbec5bb6dacaab00482)#03 pc 00000000000375a8 /system/lib64/libstationopticsservice.so (pvr::MCULogProcess::MCULogProcessFunc()+168) (BuildId: 9943b2f8208bbfbec5bb6dacaab00482)#04 pc 0000000000048b44 /system/lib64/libstationopticsservice.so (_ZNSt3__114__thread_proxyINS_5tupleIJNS_10unique_ptrINS_15__thread_structENS_14default_deleteIS3_EEEEMN3pvr13MCULogProcessEFvvEPS8_EEEEEPvSD_+60) (BuildId: 9943b2f8208bbfbec5bb6dacaab00482)#05 pc 00000000000ecce4 /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+36) (BuildId: 02b3bc38eb77bdc99f28c0fc3f17de65)#06 pc 000000000008b064 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: 02b3bc38eb77bdc99f28c0fc3f17de65)
二、分析
原因分析： __stack_chk_fail说明发生了缓冲区溢出，canary被破坏。这说明代码设置GCC编译选项fstack-protector，开启了栈保护机制canary，canary存放位置如下，如果func1函数中有越界操作，很可能会修改到canary，stack_chk_fail检测canary就会失败
反汇编后找到对应函数的汇编代码，定位到+500处
00000000000395f8 <_ZN3pvr14StationService15StationLogPrintEPci@@Base>:395f8: a9ba6ffc stp x28, x27, [sp,#-96]!395fc: a90167fa stp x26, x25, [sp,#16]39600: a9025ff8 stp x24, x23, [sp,#32]39604: a90357f6 stp x22, x21, [sp,#48]39608: a9044ff4 stp x20, x19, [sp,#64]3960c: a9057bfd stp x29, x30, [sp,#80]39610: 910143fd add x29, sp, #0x5039614: d11043ff sub sp, sp, #0x41039618: d53bd058 mrs x24, tpidr_el03961c: f9401708 ldr x8, [x24,#40]39620: b00001f9 adrp x25, 76000 <configServiceClient@@Base>39624: 2a0203f4 mov w20, w239628: aa0103f5 mov x21, x13962c: f81a03a8 stur x8, [x29,#-96]39630: b944a336 ldr w22, [x25,#1184]39634: 0b0202c8 add w8, w22, w239638: 7110051f cmp w8, #0x4013963c: 540001ab b.lt 39670 <_ZN3pvr14StationService15StationLogPrintEPci@@Base+0x78>39640: b00001e0 adrp x0, 76000 <configServiceClient@@Base>39644: 91027800 add x0, x0, #0x9e39648: 321603e2 orr w2, wzr, #0x4003964c: 2a1f03e1 mov w1, wzr39650: 9400cafc bl 6c240 <memset@plt>39654: b0ffff80 adrp x0, 2a000 <gyroLSB@@Base-0x3e4c>39658: 91102000 add x0, x0, #0x4083965c: 2a1603e1 mov w1, w2239660: 2a1403e2 mov w2, w2039664: 9400cacf bl 6c1a0 <_Z8pr_debugPKcz@plt>39668: 2a1f03f6 mov w22, wzr3966c: b904a33f str wzr, [x25,#1184]39670: b00001f3 adrp x19, 76000 <configServiceClient@@Base>39674: 91027a73 add x19, x19, #0x9e39678: 8b36c260 add x0, x19, w22, sxtw3967c: 93407e82 sxtw x2, w2039680: aa1503e1 mov x1, x2139684: 9400cb6f bl 6c440 <memcpy@plt>39688: b944a328 ldr w8, [x25,#1184]3968c: 910003e0 mov x0, sp39690: 321603e2 orr w2, wzr, #0x40039694: 2a1f03e1 mov w1, wzr39698: 0b14011c add w28, w8, w203969c: b904a33c str w28, [x25,#1184]396a0: 910003fa mov x26, sp396a4: 9400cae7 bl 6c240 <memset@plt>396a8: 7100079f cmp w28, #0x1396ac: 5400088b b.lt 397bc <_ZN3pvr14StationService15StationLogPrintEPci@@Base+0x1c4>396b0: 90ffff94 adrp x20, 29000 <gyroLSB@@Base-0x4e4c>396b4: f0ffff75 adrp x21, 28000 <gyroLSB@@Base-0x5e4c>396b8: aa1f03e8 mov x8, xzr396bc: aa1f03fb mov x27, xzr396c0: 91062294 add x20, x20, #0x188396c4: 9108deb5 add x21, x21, #0x237396c8: aa1303f6 mov x22, x19396cc: 8b1b0269 add x9, x19, x27396d0: 3940012a ldrb w10, [x9]396d4: 7100295f cmp w10, #0xa396d8: 54000040 b.eq 396e0 <_ZN3pvr14StationService15StationLogPrintEPci@@Base+0xe8>396dc: 3500038a cbnz w10, 3974c <_ZN3pvr14StationService15StationLogPrintEPci@@Base+0x154>396e0: cb160137 sub x23, x9, x22396e4: f10006ff cmp x23, #0x1396e8: 5400030b b.lt 39748 <_ZN3pvr14StationService15StationLogPrintEPci@@Base+0x150>396ec: 910003e0 mov x0, sp396f0: 321603e2 orr w2, wzr, #0x400396f4: 2a1f03e1 mov w1, wzr396f8: 9400cad2 bl 6c240 <memset@plt>396fc: 910003e0 mov x0, sp39700: 321603e1 orr w1, wzr, #0x40039704: 321603e2 orr w2, wzr, #0x40039708: aa1403e3 mov x3, x203970c: aa1503e4 mov x4, x2139710: 940007d4 bl 3b660 <_ZN3pvr14StationService23set_camerafps_to_configE12camera_fps_t@@Base+0x114>39714: 93407c08 sxtw x8, w039718: 8b0802fc add x28, x23, x83971c: f110039f cmp x28, #0x40039720: 540004ec b.gt 397bc <_ZN3pvr14StationService15StationLogPrintEPci@@Base+0x1c4>39724: 8b080340 add x0, x26, x839728: aa1603e1 mov x1, x223972c: aa1703e2 mov x2, x2339730: 9400cb44 bl 6c440 <memcpy@plt>39734: 910003e1 mov x1, sp39738: aa1403e0 mov x0, x203973c: 383ccb5f strb wzr, [x26,w28,sxtw]39740: 9400cb44 bl 6c450 <_ZN3pvr9pr_keylogEPKcz@plt>39744: b944a33c ldr w28, [x25,#1184]39748: 91000768 add x8, x27, #0x13974c: 9100077b add x27, x27, #0x139750: 93407f89 sxtw x9, w2839754: eb09037f cmp x27, x939758: 8b080276 add x22, x19, x83975c: 54fffb8b b.lt 396cc <_ZN3pvr14StationService15StationLogPrintEPci@@Base+0xd4>39760: b40002e8 cbz x8, 397bc <_ZN3pvr14StationService15StationLogPrintEPci@@Base+0x1c4>39764: eb09011f cmp x8, x939768: 540001ea b.ge 397a4 <_ZN3pvr14StationService15StationLogPrintEPci@@Base+0x1ac>3976c: 4b080388 sub w8, w28, w839770: 93407d02 sxtw x2, w839774: 321603e3 orr w3, wzr, #0x40039778: aa1303e0 mov x0, x193977c: aa1603e1 mov x1, x2239780: b904a328 str w8, [x25,#1184]39784: 321603f4 orr w20, wzr, #0x40039788: 9400cb36 bl 6c460 <__memcpy_chk@plt>3978c: b984a328 ldrsw x8, [x25,#1184]39790: 2a1f03e1 mov w1, wzr39794: 8b080260 add x0, x19, x839798: cb080282 sub x2, x20, x83979c: 9400caa9 bl 6c240 <memset@plt>397a0: 14000007 b 397bc <_ZN3pvr14StationService15StationLogPrintEPci@@Base+0x1c4>397a4: b00001e0 adrp x0, 76000 <configServiceClient@@Base>397a8: 91027800 add x0, x0, #0x9e397ac: 321603e2 orr w2, wzr, #0x400397b0: 2a1f03e1 mov w1, wzr397b4: 9400caa3 bl 6c240 <memset@plt>397b8: b904a33f str wzr, [x25,#1184]397bc: f9401708 ldr x8, [x24,#40]397c0: f85a03a9 ldur x9, [x29,#-96]397c4: eb09011f cmp x8, x9397c8: 54000121 b.ne 397ec <_ZN3pvr14StationService15StationLogPrintEPci@@Base+0x1f4>397cc: 911043ff add sp, sp, #0x410397d0: a9457bfd ldp x29, x30, [sp,#80]397d4: a9444ff4 ldp x20, x19, [sp,#64]397d8: a94357f6 ldp x22, x21, [sp,#48]397dc: a9425ff8 ldp x24, x23, [sp,#32]397e0: a94167fa ldp x26, x25, [sp,#16]397e4: a8c66ffc ldp x28, x27, [sp],#96397e8: d65f03c0 ret397ec: 9400ca75 bl 6c1c0 <__stack_chk_fail@plt>
确实是__stack_chk_fail执行出现了问题
397ec: 9400ca75 bl 6c1c0 <__stack_chk_fail@plt>
再说一下，canary破坏很大可能是memset memcpy越界修改造成的，而且是栈中的变量，如下static概率就比较小，因为static变量不在栈中，所以，大概率是tmp这个数组
void StationService::StationLogPrint(char *buf, int len) {
#define STTAG "STLOG"
#define BUF_MAX_LEN 1024static char stlog[BUF_MAX_LEN] = {0};static int stlen = 0;station_debug_info_t buffer;memset(&buffer, 0, sizeof(buffer));buffer.type = (perf_test_t)STATION_LOG_INFO;if (stlen + len > BUF_MAX_LEN) {memset(stlog, 0, BUF_MAX_LEN);pr_debug("STLOG: stlen:%d, len:%d, err, drop!", stlen, len);stlen = 0;}memcpy(stlog + stlen, buf ,len);stlen += len;char tmp[BUF_MAX_LEN] = {0};char *p1 = stlog;char *p2 = p1;for (int i = 0; i < stlen; i++) {if ('\n' == *(stlog + i) || '\0' == *(stlog + i)) {p2 = stlog + i;if ((p2 - p1) > 0) {memset(tmp, 0, sizeof(tmp));int l = snprintf(tmp, sizeof(tmp), "%s", STTAG);if (l + (p2 - p1) > BUF_MAX_LEN) {return;}// pr_err("01%s, l:%d, len:%d, stlen:%d, (p2 - p1):%d", __FUNCTION__, l, len, stlen, (p2 - p1));memcpy(tmp + l, p1, (p2 - p1));l += p2 - p1;tmp[l] = '\0';pr_keylog("%s", tmp);}p1 = p2 + 1;}}if (p1 == stlog) {return;}if (p1 - stlog >= stlen) {memset(stlog, 0, sizeof(stlog));stlen = 0;} else {stlen -= p1 - stlog;memcpy(stlog, p1, stlen);memset(stlog + stlen, 0, sizeof(stlog) - stlen);}
}所以大概率问题出现在32行的memcpy，p2-p1可能越界了，因为tmp与stlog大小一样，tmp在开头加了一断字符，p2-p1+l
很有可能大于BUF_MAX_LEN，造成越界访问。
