Crun容器运行时中getsubidrange函数的内存泄漏问题分析

问题背景

在Linux容器运行时crun中，存在一个潜在的内存泄漏问题，该问题主要出现在使用用户命名空间(user namespace)的场景下。当系统缺少/etc/passwd文件时，getsubidrange函数会进入无限循环的内存重分配(realloc)过程，最终导致内存耗尽(OOM)。

技术细节分析

该问题的核心在于getpwuid_r系统调用的错误处理逻辑。在crun的utils.c文件中，getsubidrange函数使用getpwuid_r来获取用户信息。根据POSIX标准，getpwuid_r在成功时返回0，在缓冲区不足时返回ERANGE，在其他错误情况下返回相应的错误码。

原始代码中存在一个逻辑缺陷：它只检查返回值是否小于0，而实际上getpwuid_r在错误情况下返回的是正数错误码(如ENOENT=2)。当/etc/passwd文件不存在时，函数会返回ENOENT，但代码错误地将其视为需要扩大缓冲区的情况，导致不断调用mremap进行内存重分配。

问题表现

在strace跟踪中可以观察到以下典型模式：

1. 系统尝试访问不存在的/etc/nsswitch.conf和/etc/passwd文件
2. 随后调用mremap进行内存重分配
3. 分配大小呈现指数增长(135168→266240→528384→1052672...)
4. 最终导致内存耗尽

解决方案

正确的处理方式应该是：

1. 当getpwuid_r返回0时，表示成功获取用户信息
2. 当返回ERANGE时，表示需要扩大缓冲区
3. 对于其他任何错误码，都应立即终止处理

修复方案是将错误检查条件从ret < 0改为ret != ERANGE，这样能正确处理所有错误情况，避免无限循环的内存分配。

最佳实践建议

对于容器运行时开发，在处理系统调用时应注意：

1. 仔细阅读每个系统调用的man page，了解其确切的返回值语义
2. 对错误码进行精确匹配，而非范围判断
3. 对于可能缺失的系统文件，应有适当的回退机制
4. 对内存分配操作设置合理的上限，防止失控增长

这个问题虽然出现在特定场景(缺少/etc/passwd)，但它揭示了在系统编程中正确处理错误返回值的重要性，特别是在容器这种对资源限制敏感的环境中。