__stack_chk_fail问题分析

fengzhishang_meteor

已于 2023-07-03 10:54:21 修改

阅读量1.3k

点赞数

分类专栏： C Program Language 文章标签： SIGABRT _stack_chk_fail Powered by 金山文档

于 2023-02-24 12:00:06 首次发布

本文链接：https://blog.csdn.net/davion_zhang/article/details/129196840

版权

C Program Language 专栏收录该内容

17 篇文章 1 订阅

订阅专栏

一、问题

进程收到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  000000731f60b4f0
    x4  0000000000808080  x5  0000000000808080  x6  0000000000808080  x7  0000000000000030
    x8  00000000000000f0  x9  9c790c62d7456e2d  x10 0000000000000001  x11 0000000000000000
    x12 fffffff0ffffffdf  x13 000002bd7a90a09e  x14 0031c42fbe3a7800  x15 0000000034155555
    x16 00000073a2b9fb38  x17 00000073a2b77d40  x18 000000731ea16000  x19 00000000000003a5
    x20 00000000000016a8  x21 00000000ffffffff  x22 00000073a47d949a  x23 00000000000003fb
    x24 000000731f60be20  x25 00000073a47d9000  x26 000000731f60b5b0  x27 00000000000003fc
    x28 00000000000003fc  x29 000000731f60b590
    sp  000000731f60b4d0  lr  00000073a2b295bc  pc  00000073a2b295e8

backtrace:
      #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, #0x50
   39614:    d11043ff     sub    sp, sp, #0x410
   39618:    d53bd058     mrs    x24, tpidr_el0
   3961c:    f9401708     ldr    x8, [x24,#40]
   39620:    b00001f9     adrp    x25, 76000 <configServiceClient@@Base>
   39624:    2a0203f4     mov    w20, w2
   39628:    aa0103f5     mov    x21, x1
   3962c:    f81a03a8     stur    x8, [x29,#-96]
   39630:    b944a336     ldr    w22, [x25,#1184]
   39634:    0b0202c8     add    w8, w22, w2
   39638:    7110051f     cmp    w8, #0x401
   3963c:    540001ab     b.lt    39670 <_ZN3pvr14StationService15StationLogPrintEPci@@Base+0x78>
   39640:    b00001e0     adrp    x0, 76000 <configServiceClient@@Base>
   39644:    91027800     add    x0, x0, #0x9e
   39648:    321603e2     orr    w2, wzr, #0x400
   3964c:    2a1f03e1     mov    w1, wzr
   39650:    9400cafc     bl    6c240 <memset@plt>
   39654:    b0ffff80     adrp    x0, 2a000 <gyroLSB@@Base-0x3e4c>
   39658:    91102000     add    x0, x0, #0x408
   3965c:    2a1603e1     mov    w1, w22
   39660:    2a1403e2     mov    w2, w20
   39664:    9400cacf     bl    6c1a0 <_Z8pr_debugPKcz@plt>
   39668:    2a1f03f6     mov    w22, wzr
   3966c:    b904a33f     str    wzr, [x25,#1184]
   39670:    b00001f3     adrp    x19, 76000 <configServiceClient@@Base>
   39674:    91027a73     add    x19, x19, #0x9e
   39678:    8b36c260     add    x0, x19, w22, sxtw
   3967c:    93407e82     sxtw    x2, w20
   39680:    aa1503e1     mov    x1, x21
   39684:    9400cb6f     bl    6c440 <memcpy@plt>
   39688:    b944a328     ldr    w8, [x25,#1184]
   3968c:    910003e0     mov    x0, sp
   39690:    321603e2     orr    w2, wzr, #0x400
   39694:    2a1f03e1     mov    w1, wzr
   39698:    0b14011c     add    w28, w8, w20
   3969c:    b904a33c     str    w28, [x25,#1184]
   396a0:    910003fa     mov    x26, sp
   396a4:    9400cae7     bl    6c240 <memset@plt>
   396a8:    7100079f     cmp    w28, #0x1
   396ac:    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, xzr
   396bc:    aa1f03fb     mov    x27, xzr
   396c0:    91062294     add    x20, x20, #0x188
   396c4:    9108deb5     add    x21, x21, #0x237
   396c8:    aa1303f6     mov    x22, x19
   396cc:    8b1b0269     add    x9, x19, x27
   396d0:    3940012a     ldrb    w10, [x9]
   396d4:    7100295f     cmp    w10, #0xa
   396d8:    54000040     b.eq    396e0 <_ZN3pvr14StationService15StationLogPrintEPci@@Base+0xe8>
   396dc:    3500038a     cbnz    w10, 3974c <_ZN3pvr14StationService15StationLogPrintEPci@@Base+0x154>
   396e0:    cb160137     sub    x23, x9, x22
   396e4:    f10006ff     cmp    x23, #0x1
   396e8:    5400030b     b.lt    39748 <_ZN3pvr14StationService15StationLogPrintEPci@@Base+0x150>
   396ec:    910003e0     mov    x0, sp
   396f0:    321603e2     orr    w2, wzr, #0x400
   396f4:    2a1f03e1     mov    w1, wzr
   396f8:    9400cad2     bl    6c240 <memset@plt>
   396fc:    910003e0     mov    x0, sp
   39700:    321603e1     orr    w1, wzr, #0x400
   39704:    321603e2     orr    w2, wzr, #0x400
   39708:    aa1403e3     mov    x3, x20
   3970c:    aa1503e4     mov    x4, x21
   39710:    940007d4     bl    3b660 <_ZN3pvr14StationService23set_camerafps_to_configE12camera_fps_t@@Base+0x114>
   39714:    93407c08     sxtw    x8, w0
   39718:    8b0802fc     add    x28, x23, x8
   3971c:    f110039f     cmp    x28, #0x400
   39720:    540004ec     b.gt    397bc <_ZN3pvr14StationService15StationLogPrintEPci@@Base+0x1c4>
   39724:    8b080340     add    x0, x26, x8
   39728:    aa1603e1     mov    x1, x22
   3972c:    aa1703e2     mov    x2, x23
   39730:    9400cb44     bl    6c440 <memcpy@plt>
   39734:    910003e1     mov    x1, sp
   39738:    aa1403e0     mov    x0, x20
   3973c:    383ccb5f     strb    wzr, [x26,w28,sxtw]
   39740:    9400cb44     bl    6c450 <_ZN3pvr9pr_keylogEPKcz@plt>
   39744:    b944a33c     ldr    w28, [x25,#1184]
   39748:    91000768     add    x8, x27, #0x1
   3974c:    9100077b     add    x27, x27, #0x1
   39750:    93407f89     sxtw    x9, w28
   39754:    eb09037f     cmp    x27, x9
   39758:    8b080276     add    x22, x19, x8
   3975c:    54fffb8b     b.lt    396cc <_ZN3pvr14StationService15StationLogPrintEPci@@Base+0xd4>
   39760:    b40002e8     cbz    x8, 397bc <_ZN3pvr14StationService15StationLogPrintEPci@@Base+0x1c4>
   39764:    eb09011f     cmp    x8, x9
   39768:    540001ea     b.ge    397a4 <_ZN3pvr14StationService15StationLogPrintEPci@@Base+0x1ac>
   3976c:    4b080388     sub    w8, w28, w8
   39770:    93407d02     sxtw    x2, w8
   39774:    321603e3     orr    w3, wzr, #0x400
   39778:    aa1303e0     mov    x0, x19
   3977c:    aa1603e1     mov    x1, x22
   39780:    b904a328     str    w8, [x25,#1184]
   39784:    321603f4     orr    w20, wzr, #0x400
   39788:    9400cb36     bl    6c460 <__memcpy_chk@plt>
   3978c:    b984a328     ldrsw    x8, [x25,#1184]
   39790:    2a1f03e1     mov    w1, wzr
   39794:    8b080260     add    x0, x19, x8
   39798:    cb080282     sub    x2, x20, x8
   3979c:    9400caa9     bl    6c240 <memset@plt>
   397a0:    14000007     b    397bc <_ZN3pvr14StationService15StationLogPrintEPci@@Base+0x1c4>
   397a4:    b00001e0     adrp    x0, 76000 <configServiceClient@@Base>
   397a8:    91027800     add    x0, x0, #0x9e
   397ac:    321603e2     orr    w2, wzr, #0x400
   397b0:    2a1f03e1     mov    w1, wzr
   397b4:    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, x9
   397c8:    54000121     b.ne    397ec <_ZN3pvr14StationService15StationLogPrintEPci@@Base+0x1f4>
   397cc:    911043ff     add    sp, sp, #0x410
   397d0:    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],#96
   397e8:    d65f03c0     ret
   397ec:    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 1024
    static 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，造成越界访问。

fengzhishang_meteor

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
__stack_chk_fail问题分析

再说一下，canary破坏很大可能是memset memcpy越界修改造成的，而且是栈中的变量，如下static概率就比较小，因为static变量不在栈中，所以，大概率是tmp这个数组。，canary存放位置如下，如果func1函数中有越界操作，很可能会修改到canary，stack_chk_fail检测canary就会失败。所以大概率问题出现在32行的memcpy，p2-p1可能越界了，因为tmp与stlog大小一样，tmp在开头加了一断字符，p2-p1+l。发生了缓冲区溢出，canary被破坏。
复制链接

扫一扫