The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - fs: Prevent file descriptor table allocations exceeding INT_MAX When sysctl_nr_open is set to a very high     value (for example, 1073741816 as set by systemd), processes attempting to use file descriptors near the     limit can trigger massive memory allocation attempts that exceed INT_MAX, resulting in a WARNING in     mm/slub.c: WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288 This happens     because kvmalloc_array() and kvmalloc() check if the requested size exceeds INT_MAX and emit a warning     when the allocation is not flagged with __GFP_NOWARN. Specifically, when nr_open is set to 1073741816     (0x3ffffff8) and a process calls dup2(oldfd, 1073741880), the kernel attempts to allocate: - File     descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes - Multiple bitmaps: ~400MB - Total allocation     size: > 8GB (exceeding INT_MAX = 2,147,483,647) Reproducer: 1. Set /proc/sys/fs/nr_open to 1073741816: #     echo 1073741816 > /proc/sys/fs/nr_open 2. Run a program that uses a high file descriptor: #include     <unistd.h> #include <sys/resource.h> int main() { struct rlimit rlim = {1073741824, 1073741824};
    setrlimit(RLIMIT_NOFILE, &rlim); dup2(2, 1073741880); // Triggers the warning return 0; } 3. Observe     WARNING in dmesg at mm/slub.c:5027 systemd commit a8b627a introduced automatic bumping of fs.nr_open to     the maximum possible value. The rationale was that systems with memory control groups (memcg) no longer     need separate file descriptor limits since memory is properly accounted. However, this change overlooked     that: 1. The kernel's allocation functions still enforce INT_MAX as a maximum size regardless of memcg     accounting 2. Programs and tests that legitimately test file descriptor limits can inadvertently trigger     massive allocations 3. The resulting allocations (>8GB) are impractical and will always fail systemd's     algorithm starts with INT_MAX and keeps halving the value until the kernel accepts it. On most systems,     this results in nr_open being set to 1073741816 (0x3ffffff8), which is just under 1GB of file descriptors.
    While processes rarely use file descriptors near this limit in normal operation, certain selftests (like     tools/testing/selftests/core/unshare_test.c) and programs that test file descriptor limits can trigger     this issue. Fix this by adding a check in alloc_fdtable() to ensure the requested allocation size does not     exceed INT_MAX. This causes the operation to fail with -EMFILE instead of triggering a kernel warning and     avoids the impractical >8GB memory allocation request. (CVE-2025-39756)

Note that Nessus relies on the presence of the package as reported by the vendor.

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - fsINT_MAX を超えるファイル記述子テーブル割り当てを防ぎます。sysctl_nr_open が非常に高い値に設定されている場合例systemd で設定されている 1073741816、制限に近いファイル記述子を使用しようとするプロセスが INT_MAX を超える大量のメモリ割り当てを発生させ、 mm/slub.cの警告で警告CPU0 PID44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288 これは、リクエストされたサイズがINT_MAXを超えてエミットするかどうかをkvmalloc_array()とkvmalloc()がチェックするために発生します。割り当てが __GFP_NOWARN でフラグが立てられていない場合、警告が表示されます。具体的には、nr_open が 1073741816 (0x3ffffff8) に設定され、プロセスが dup2oldfd、1073741880を呼び出すとき、カーネルは割り当てを試みます。- ファイル記述子の配列1073741880 * 8 バイト = 8,589,935,040 bytes - 複数のビットマップ〜400MB - 合計割り当てサイズ> 8GBINT_MAX = 2,147,483,647 を実行include <unistd.h> #include<sys/resource.h> int main() { struct rlimit rlim = {1073741824, 1073741824};
    setrlimit(RLIMIT_NOFILE, &rlim); dup2(2, 1073741880); // 警告リターン 0 を発生させます} 3. mm/slub.c:5027 systemd コミット a8b627a の dmesg の警告に従い、fs.nr_open の可能な最大値への自動更新を導入しました。その理由は、メモリが適切に説明されるため、メモリコントロールグループmemcgを備えたシステムでは個別のファイル記述子の制限はもはや必要ないということでした。しかし、この変更は次の内容を見落としていました1. カーネルの割り当て関数は、依然として memcg アカウンティングにかかわらず最大サイズとして INT_MAX を強制します 2. ファイル記述子の制限を正当にテストするプログラムおよびテストは、不注意に大量の割り当てを発生させる可能性があります 3。その結果生じる割り当て>8GBは です。実行的でないと常に失敗します。systemd のアルゴリズムは INT_MAX で始まり、カーネルが受け入れるまで値を半分に減らし続けます。ほとんどのシステムで、これにより nr_open は 1073741816 (0x3ffffff8) に設定され、ファイル記述子は 1GB 未満になります。
    プロセスが通常の操作でこの制限の近くでファイル記述子を使用することはほとんどありませんが、特定のセルフテストtools/testing/selftests/core/unshare_test.c などやファイル記述子の制限をテストするプログラムでは、この問題が発生する可能性があります。alloc_fdtable() にチェックを追加し、リクエストされた割り当てサイズが INT_MAX を超えないようにすることで、これを修正します。これにより、カーネル警告をトリガーする代わりに -EMFILE で操作が失敗し、非実用的な >8GB メモリ割り当てリクエストが回避されます。 (CVE-2025-39756)

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - fs防止超過 INT_MAX 的檔案描述符號表格配置將 sysctl_nr_open 設為非常高的值 (例如 systemd 設定的 1073741816) 時嘗試使用接近限制的檔案描述符號的處理程序會觸發超過 INT_MAX 的大量記憶體配置嘗試進而導致在 mm/slub.c 的警告中警告 CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288配置未以 __GFP_NOWARN 標示時顯示警告。具體而言當 nr_open 設為 1073741816 (0x3ffffff8) 且處理程序呼叫 dup2(oldfd, 1073741880) 時核心會嘗試配置- 檔案描述符號陣列1073741880 * 8 位元組 = 8,589,935,040 位元組 - 多個點陣圖~400MB - 總配置大小> 8GB (超過 INT_MAX = 2,147,483,647) 複製者1. Set /proc/sys/fs/nr_open to 1073741816# echo 1073741816 > /proc/sys/fs/nr_open 2. 執行使用高檔案描述符號的程式#包含 <unistd.h> #include<sys/resource.h> int main() { struct rlimit rlim = {1073741824, 1073741824};
    setrlimit(RLIMIT_NOFILE, &rlim); dup2(2, 1073741880) // 觸發警告傳回 0 3. 請注意 dmesg at mm/slub.c:5027 systemd commit 中的警告 a8b627a 引入了將 fs.nr_open 自動升級為可能的最大值。理由是具有記憶體控制群組 (memcg) 的系統不再需要個別檔案描述符號限制因為記憶體已得到妥善考量。不過此變更會忽略不切實際且一律失敗。systemd 的演算法從 INT_MAX 開始並持續將該值減半直到核心接受為止。在大多數係統上這會導致 nr_open 設為 1073741816 (0x3ffffff8)其剛好小於 1GB 的檔案描述符號。
    雖然處理程序在正常作業中很少使用接近此限制的檔案描述符號但某些自我測試 (例如 tools/testing/selftests/core/unshare_test.c) 和測試檔案描述符號限制的程式可能會觸發此問題。在 alloc_fdtable() 中新增檢查以修正此問題以確保要求的配置大小不會超過 INT_MAX。這會造成作業以 -EMFILE 失敗而非觸發核心警告並可避免不切實際的 >8GB 記憶體配置要求。 (CVE-2025-39756)

請注意，Nessus 依賴供應商報告的套件存在。

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 依赖供应商报告的程序包是否存在进行判断。

ID	Name	Product	Family	Published	Updated	Severity
264737	Linux Distros Unpatched Vulnerability : CVE-2025-39756	Nessus	Misc.	9/14/2025	9/16/2025	medium
264737	Linux Distros のパッチ未適用の脆弱性: CVE-2025-39756	Nessus	Misc.	9/14/2025	9/16/2025	medium
264737	Linux Distros 未修補的弱點：CVE-2025-39756	Nessus	Misc.	9/14/2025	9/16/2025	medium
264737	Linux Distros 未修补的漏洞：CVE-2025-39756	Nessus	Misc.	9/14/2025	9/16/2025	medium

Detections

Analytics

Plugins Search

medium

medium

medium

medium