接口安全编码：防止缓冲区溢出、整数溢出、空指针解引用

说实话，接口安全这块，我以前也吃过不少亏。刚入行那会儿，总觉得功能跑通了就行，什么溢出、空指针，都是理论上的东西。直到有一次，一个缓冲区溢出导致整个系统在客户现场崩溃，我才真正意识到——接口的防御能力，才是代码质量的底线。

今天咱们就聊聊接口设计中三个最要命的坑：缓冲区溢出、整数溢出、空指针解引用。这三个问题，说白了就是C语言的老三样，但直到现在，很多嵌入式项目里还在反复踩雷。

1. 缓冲区溢出：接口的第一杀手

缓冲区溢出有多常见？我参与过的代码审查中，几乎每三个模块就有一个存在潜在溢出风险。为什么会这样？因为很多开发者默认调用者会「乖乖听话」，传进来的参数长度一定够用。

但现实是——调用者可能传一个超长的字符串，可能传一个负数的长度，甚至可能传一个野指针。你的接口，必须能扛住这些「恶意」或「无意」的输入。

1.1 字符串拷贝的安全写法

先看一个典型的「危险接口」：

// 危险！没有长度限制
void copy_name(char *dest, const char *src) {
    strcpy(dest, src);  // 如果src比dest长，直接溢出
}

我在项目中见过类似的代码，当时那个模块负责处理网络数据包。攻击者只要发一个超长的包，就能让整个设备重启。嗯，后来我们改成了这样：

// 安全版本：明确指定目标缓冲区大小
#define MAX_NAME_LEN 64

int copy_name_safe(char *dest, size_t dest_size, const char *src) {
    if (dest == NULL || src == NULL) {
        return -1;  // 空指针检查
    }
    if (dest_size == 0) {
        return -2;  // 大小为0，无法拷贝
    }
    
    size_t src_len = strnlen(src, dest_size - 1);
    memcpy(dest, src, src_len);
    dest[src_len] = '\0';
    return 0;
}

1.2 格式化字符串的安全

还有一个容易被忽视的点——格式化字符串。我曾经在日志模块里看到这样的代码：

void log_message(const char *user_input) {
    char buffer[256];
    sprintf(buffer, user_input);  // 危险！用户输入可能包含%s等格式符
    // 输出buffer
}

如果用户输入的是 %s%s%s%s%s%s%s%s，会发生什么？栈上的数据会被当作地址读取，轻则崩溃，重则泄露敏感信息。正确的写法是：

void log_message_safe(const char *user_input) {
    char buffer[256];
    snprintf(buffer, sizeof(buffer), "%s", user_input);  // 固定格式，用户输入只作为数据
    // 输出buffer
}

2. 整数溢出：看不见的陷阱

整数溢出这个问题，说实话，比缓冲区溢出更隐蔽。缓冲区溢出至少会崩溃，你能很快发现。但整数溢出——它可能让程序「悄悄」地跑错逻辑，数据看起来也对，但就是结果不对。

我记得有一次排查一个通信协议栈的bug，数据包长度字段是16位无符号整数。接收方计算剩余缓冲区时，用了 remaining = total - received。如果 received > total，结果变成一个巨大的正数（因为无符号整数的回绕），然后memcpy就拷贝了超大量的数据……嗯，后果你懂的。

2.1 常见的整数溢出场景

溢出类型	示例	后果
无符号回绕	uint16_t a = 0; a -= 1; // 变成65535	长度检查失效，缓冲区溢出
有符号溢出	int32_t a = INT32_MAX; a += 1; // 变成负数	逻辑判断错误，死循环或越界
乘法溢出	size_t size = count * elem_size;	分配的内存过小，后续写入溢出

2.2 安全编码实践

对于整数运算，我建议遵循几个原则：

• 优先使用size_t：它无符号且足够大，适合表示大小和索引
• 运算前做范围检查：特别是加法和乘法
• 避免有符号和无符号混用：隐式转换会带来意想不到的结果

来看一个安全的长度计算接口：

#include <stdint.h>
#include <limits.h>

// 安全加法：检查是否溢出
int safe_add(size_t a, size_t b, size_t *result) {
    if (a > SIZE_MAX - b) {
        return -1;  // 溢出
    }
    *result = a + b;
    return 0;
}

// 安全乘法：检查是否溢出
int safe_mul(size_t a, size_t b, size_t *result) {
    if (a != 0 && b > SIZE_MAX / a) {
        return -1;  // 溢出
    }
    *result = a * b;
    return 0;
}

// 接口中使用
int process_data(const uint8_t *data, size_t len, size_t count) {
    size_t total_size;
    if (safe_mul(len, count, &total_size) != 0) {
        return -1;  // 拒绝处理
    }
    // 安全地分配和拷贝
    uint8_t *buffer = malloc(total_size);
    if (buffer == NULL) {
        return -2;
    }
    memcpy(buffer, data, total_size);
    // ...
}

3. 空指针解引用：最基础的错误

空指针解引用，听起来很基础对吧？但我在代码审查中，几乎每次都能抓到几个。为什么？因为很多开发者只在「明显可能为空」的地方做检查，却忽略了间接路径。

比如，一个函数返回了指针，调用者直接使用，没检查返回值。或者，一个结构体中的指针成员，在初始化之前就被访问了。这些场景，在复杂的嵌入式系统中特别常见。

3.1 接口层面的空指针防御

我个人的做法是：每个公开的接口，都在入口处做空指针检查。别嫌啰嗦，这是最低成本的防御。

// 接口定义
typedef struct {
    uint8_t *data;
    size_t   len;
} buffer_t;

// 安全接口：检查所有指针参数
int buffer_write(buffer_t *buf, const uint8_t *src, size_t count) {
    // 入口检查
    if (buf == NULL || src == NULL) {
        return -1;
    }
    if (buf->data == NULL) {
        return -2;  // 内部数据指针为空
    }
    if (count > buf->len) {
        return -3;  // 空间不足
    }
    
    memcpy(buf->data, src, count);
    return 0;
}

3.2 返回值检查的「契约」

接口设计时，要明确约定：什么情况下返回空指针？调用者必须检查吗？我建议所有可能返回NULL的接口，都在文档中显式说明，并且调用者必须检查。

举个例子：

// 接口契约：
// 返回值：成功返回有效指针，失败返回NULL
// 调用者必须检查返回值
buffer_t *buffer_create(size_t size) {
    if (size == 0 || size > MAX_BUFFER_SIZE) {
        return NULL;  // 参数无效
    }
    
    buffer_t *buf = (buffer_t *)malloc(sizeof(buffer_t));
    if (buf == NULL) {
        return NULL;  // 内存不足
    }
    
    buf->data = (uint8_t *)malloc(size);
    if (buf->data == NULL) {
        free(buf);
        return NULL;
    }
    
    buf->len = size;
    return buf;
}

// 调用者必须检查
buffer_t *my_buf = buffer_create(1024);
if (my_buf == NULL) {
    // 处理错误，不能继续使用
    return;
}
// 安全使用my_buf

4. 综合防御：一个安全接口的模板

说了这么多，咱们来总结一个安全接口的「标准模板」。你写接口时，可以照着这个框架来：

/**
 * @brief 安全处理数据
 * @param[out] out_buf  输出缓冲区，不能为NULL
 * @param[in]  out_size 输出缓冲区大小，必须大于0
 * @param[in]  in_data  输入数据，不能为NULL
 * @param[in]  in_len   输入数据长度，必须大于0
 * @return 0成功，负数表示错误码
 * @note 调用者必须确保out_buf和in_data有效
 */
int safe_process(uint8_t *out_buf, size_t out_size,
                 const uint8_t *in_data, size_t in_len) {
    // 1. 空指针检查
    if (out_buf == NULL || in_data == NULL) {
        return -1;
    }
    
    // 2. 大小检查（防止整数溢出）
    if (out_size == 0 || in_len == 0) {
        return -2;
    }
    if (in_len > out_size) {
        return -3;  // 缓冲区不足
    }
    
    // 3. 安全的内存操作
    memcpy(out_buf, in_data, in_len);
    
    // 4. 确保字符串终止（如果是字符串）
    if (out_size > in_len) {
        out_buf[in_len] = '\0';
    }
    
    return 0;
}

5. 知识体系总览

下面这张图，把接口安全编码的核心知识点串起来了。你写接口时，可以对照着检查：

这张图把三大安全问题、各自的典型场景、以及统一的防御策略串在了一起。你写接口时，可以把它当作一个检查清单——每个参数都问一遍：会不会溢出？会不会为空？会不会越界？