Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - fs防止文件描述符表分配超过 INT_MAX 当 sysctl_nr_open 设置为非常高的值时由 systemd 设置为 1073741816则尝试使用接近限制的文件描述符的进程可触发超过 INT_MAX 的大量内存分配尝试的警告中的 mm/slub.c: WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288 发生这种情况的原因是 kvmalloc_array() 和 kvmalloc() 检查请求的大小是否超过 INT_MAX 并发出分配未标记 __GFP_NOWARN 时的警告。特别是当 nr_open 设置为 1073741816 (0x3ffffff8) 且进程调用 dup2(oldfd, 1073741880) 时内核会尝试分配- 文件描述符数组1073741880 * 8 字节 = 8,589,935,040 字节 - 多个位图~400MB - 总分配大小更多信息包括 <unistd.h> #include<sys/resource.h> int main() { struct rlimit rlim = {1073741824, 1073741824};
    setrlimit(RLIMIT_NOFILE, &rlim); dup2(2, 1073741880); // 触发警告 return 0 3. 观察 dmesg at mm/slub.c:5027 中的警告。systemd 提交 a8b627a 引入了将 fs.nr_open 自动升级为可能的最大值。理由是具有内存控制组 (memcg) 的系统不再需要单独的文件描述符限制因为内存已得到正确计算。但是此更改忽略了 1. 无论 memcg 核算如何内核的分配函数仍然强制 INT_MAX 作为最大大小 2. 合法测试文件描述符限制的程序和测试可无意中触发大量分配 3. 生成的分配 (>8GB)不切实际且始终失败 systemd 的算法以 INT_MAX 开头并持续将值减半直到内核接受。在大多数系统上这会导致 nr_open 被设置为 1073741816 (0x3ffffff8)即文件描述符刚好低于 1GB。
    虽然在正常操作中进程很少使用接近此限制的文件描述符但某些 selftest如 tools/testing/selftests/core/unshare_test.c和测试文件描述符限制的程序可能会触发此问题。通过在 alloc_fdtable() 中添加检查确保请求的分配大小不超过 INT_MAX从而修复此问题。这会导致操作因 -EMFILE 而失败而不是触发内核警告，并避免不切实际的 >8GB 内存分配请求。 (CVE-2025-39756)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

检测

Linux Distros 未修补的漏洞：CVE-2025-39756

medium Nessus 插件 ID 264737

版本 1.2