如何在不依赖工具的情况下检测use-after-free场景中的悬空指针

数据老陈

2026-8-13

不依赖工具检测Use-After-Free悬空指针的方法

用空指针检查的方式来检测悬空指针是完全无效的，核心原因是悬空指针并非空指针。

空指针的常规检查代码是这样的：

int *p;
p = NULL;
if (!p)
{
    // 处理异常
}

但这种逻辑对free后的悬空指针完全不起作用——因为调用free()只会释放指针指向的内存，并不会把指针本身置为NULL。比如下面的代码：

int *p, *p2;
p = malloc(10);
free(p);
p2 = p;  // p2现在是悬空指针
if (!p2) // 检查失效，p2不为NULL
{
        fprintf(stderr, "p is invalid, can't do further operation with p\n");
        exit(EXIT_FAILURE);
}

甚至直接访问free后的指针，还能读出随机的垃圾值，比如这段代码：

int *p, *p2;
p = malloc(10);
free(p);
printf("value: %d\n", *p);

执行后会输出类似这样的随机值：

./a.out
value: 898138160

如果不依赖ASan这类内存检测工具，以下是几种可行的use-after-free悬空指针检测/预防方法：

free后手动置空指针
在调用free()后立即将指针赋值为NULL，之后就能用空指针检查来判断有效性。示例：
```
int *p = malloc(10);
free(p);
p = NULL; // 手动置空
if (!p) {
    // 指针已无效，禁止后续操作
}
```
但这种方法完全依赖严格的编码规范，必须保证每一次free后都执行置空操作，稍有遗漏就会出现问题。
维护指针有效性标记
为每个动态分配的指针搭配一个布尔标记，用来记录该指针是否仍处于有效状态。示例：
```
int *p = malloc(10);
int p_valid = 1; // 初始标记为有效

free(p);
p_valid = 0; // 释放后标记为无效

if (!p_valid) {
    fprintf(stderr, "p is invalid, can't do further operation with p\n");
    exit(EXIT_FAILURE);
}
```
这种方法需要额外维护状态，适合小型项目或特定模块，缺点是增加了代码复杂度，同样依赖编码时的严谨性。

自定义内存分配封装
封装一套自己的malloc和free接口，在内部统一维护指针的有效性状态。示例：

typedef struct {
    void *ptr;
    int valid;
} SafePtr;

SafePtr safe_malloc(size_t size) {
    SafePtr sp;
    sp.ptr = malloc(size);
    sp.valid = (sp.ptr != NULL);
    return sp;
}

void safe_free(SafePtr *sp) {
    if (sp->valid) {
        free(sp->ptr);
        sp->valid = 0;
        sp->ptr = NULL;
    }
}

使用时通过safe_free后的valid字段判断指针是否可用，这种方法能统一管理指针状态，减少人为失误，但要求项目全程使用这套封装接口。

内存区域标记法
在分配内存时额外预留空间写入特定标记值，释放后检查标记是否被篡改，以此判断指针是否失效。示例：
```
#define MARKER 0xDEADBEEF

// 多分配一个标记位的空间
int *p = malloc(sizeof(int) + sizeof(int));
*p = MARKER; // 写入标记
int *data_ptr = p + 1; // 实际用于存储数据的指针

// 使用data_ptr进行操作...

free(p);
// 后续检查标记
if (*p != MARKER) {
    // 指针指向的内存已被篡改，大概率已失效
}
```
这种方法可靠性较低：一是会占用额外内存，二是如果内存被重新分配并写入新数据，标记会被覆盖，无法检测到失效。仅适合特定场景下的临时验证。

需要注意的是，上述所有方法都无法100%杜绝use-after-free问题，它们都依赖编码规范或额外的状态维护，无法像ASan这类工具那样从底层精准检测非法内存访问。最稳妥的方式还是结合静态代码分析工具，同时养成严谨的内存管理编码习惯。

内容的提问来源于stack exchange，提问作者Bubba