0x00 前言

emmmmm 前一段时间部门转iot了,然后就开始做相关的东西了,写了一些c语言的东西,踩到一个一开始觉得有点玄学的坑.在arm64的平台上遇到了一个比较奇怪的bug.

0x01 起因

我的代码中有大概这样一个操作

1	struct test *t = my_malloc(sizeof(struct test));

my_malloc大概是malloc一个封装,代码大致是这样,它属于my_stdlib.h

1
2
3

void* my_malloc(param){
  return malloc(param);
}

然后就碰上一个有些奇怪的问题,调用my_malloc以后,返回的地址,访问时会报段错误,而实际查看它的内存信息的时候,像是被覆盖了.

实际malloc返回的地址
7f968511e0

而my_malloc返回后的地址变成了这样
ffffffff968511e0

大致情况看起来就是,前四个字节,像是被什么不知名的东西,覆盖掉了.

0x02 分析

起初确实是觉得是代码逻辑有什么问题,导致了溢出之类的,覆盖了这一部分的返回值,而后发现斌没有,在尝试使用gdb的单步调试的时候发现了更加奇怪的情况.

在bl跳转调用my_malloc后,其中bl跳转调用真正的malloc,以及最后my_malloc返回前,我都查看了x0寄存器的值,发现都没有问题,而后在my_malloc返回,走到外部调用它的函数的时候,返回值像是突然发生了变化,停在调用bl my_malloc之后时,查看x0寄存器,它的值仍然是正常了,尝试使用gdb修改pc指针,跳过bl后的语句,结果发现,返回给外部函数的值就正常了.

造成异常的语句,是一条汇编代码

1	sxtw x0, w0

它的作用是将w0的值进行符号扩展,再赋值给x0寄存器,w0为x0的低32位,sxtw的作用大致是在扩展为64位时,将原先符号位前面的数据填满左边,而零填满右边的数据.(我目前汇编这个不是太好,这里可能没有很透彻的理解这条汇编,具体可以看这里https://developer.arm.com/docs/100898/latest/data-processing-instructions)

这里大概分析一下这条语句在目前这个场景下实际执行的情况

首先x0原先的值,在调用完my_malloc的之后,变成了

高32位    低32位
0000007f 968511e0

而w0此时的值,即为x0的底32位
968511e0

sxtw将w0的符号位扩展,填满前32位,所以结果变成了这样

高32位    低32位
ffffffff 968511e0

到这里,就已经分析出来了报错的原因,即为多出来的这一条sxtw语句,导致了返回值变为了一个奇怪的值,不可访问,而后导致段错误,但是真正问题是,为什么会多出一条sxtw语句导致这样的问题.