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: 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/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 依賴供應商報告的套件存在。

The remote Debian 12 host has packages installed that are affected by multiple vulnerabilities as referenced in the dsa-6009 advisory.

    - -------------------------------------------------------------------------     Debian Security Advisory DSA-6009-1                   security@debian.org     https://www.debian.org/security/                     Salvatore Bonaccorso     September 22, 2025                    https://www.debian.org/security/faq
    - -------------------------------------------------------------------------

    Package        : linux     CVE ID         : CVE-2024-47704 CVE-2024-57924 CVE-2024-58240 CVE-2025-23143                      CVE-2025-23160 CVE-2025-37931 CVE-2025-37968 CVE-2025-38322                      CVE-2025-38347 CVE-2025-38491 CVE-2025-38502 CVE-2025-38552                      CVE-2025-38614 CVE-2025-38670 CVE-2025-38676 CVE-2025-38677                      CVE-2025-38679 CVE-2025-38680 CVE-2025-38681 CVE-2025-38683                      CVE-2025-38684 CVE-2025-38685 CVE-2025-38687 CVE-2025-38691                      CVE-2025-38693 CVE-2025-38694 CVE-2025-38695 CVE-2025-38696                      CVE-2025-38697 CVE-2025-38698 CVE-2025-38699 CVE-2025-38700                      CVE-2025-38701 CVE-2025-38702 CVE-2025-38706 CVE-2025-38707                      CVE-2025-38708 CVE-2025-38711 CVE-2025-38712 CVE-2025-38713                      CVE-2025-38714 CVE-2025-38715 CVE-2025-38721 CVE-2025-38723                      CVE-2025-38724 CVE-2025-38725 CVE-2025-38727 CVE-2025-38728                      CVE-2025-38729 CVE-2025-38732 CVE-2025-38735 CVE-2025-38736                      CVE-2025-39673 CVE-2025-39675 CVE-2025-39676 CVE-2025-39681                      CVE-2025-39682 CVE-2025-39683 CVE-2025-39684 CVE-2025-39685                      CVE-2025-39686 CVE-2025-39687 CVE-2025-39689 CVE-2025-39691                      CVE-2025-39692 CVE-2025-39693 CVE-2025-39694 CVE-2025-39697                      CVE-2025-39701 CVE-2025-39702 CVE-2025-39703 CVE-2025-39706                      CVE-2025-39709 CVE-2025-39710 CVE-2025-39713 CVE-2025-39714                      CVE-2025-39715 CVE-2025-39716 CVE-2025-39718 CVE-2025-39719                      CVE-2025-39724 CVE-2025-39736 CVE-2025-39737 CVE-2025-39738                      CVE-2025-39742 CVE-2025-39743 CVE-2025-39749 CVE-2025-39751                      CVE-2025-39752 CVE-2025-39756 CVE-2025-39757 CVE-2025-39759                      CVE-2025-39760 CVE-2025-39766 CVE-2025-39770 CVE-2025-39772                      CVE-2025-39773 CVE-2025-39776 CVE-2025-39782 CVE-2025-39783                      CVE-2025-39787 CVE-2025-39788 CVE-2025-39790 CVE-2025-39794                      CVE-2025-39795 CVE-2025-39798 CVE-2025-39800 CVE-2025-39801                      CVE-2025-39806 CVE-2025-39808 CVE-2025-39812 CVE-2025-39813                      CVE-2025-39817 CVE-2025-39819 CVE-2025-39823 CVE-2025-39824                      CVE-2025-39825 CVE-2025-39826 CVE-2025-39827 CVE-2025-39828                      CVE-2025-39835 CVE-2025-39838 CVE-2025-39839 CVE-2025-39841                      CVE-2025-39842 CVE-2025-39843 CVE-2025-39844 CVE-2025-39845                      CVE-2025-39846 CVE-2025-39847 CVE-2025-39848 CVE-2025-39849                      CVE-2025-39853 CVE-2025-39857 CVE-2025-39860 CVE-2025-39864                      CVE-2025-39865 CVE-2025-39866 CVE-2025-40300

    Several vulnerabilities have been discovered in the Linux kernel that     may lead to a privilege escalation, denial of service or information     leaks.

    For the oldstable distribution (bookworm), these problems have been fixed     in version 6.1.153-1.

    We recommend that you upgrade your linux packages.

    For the detailed security status of linux please refer to its security     tracker page at:
    https://security-tracker.debian.org/tracker/linux

    Further information about Debian Security Advisories, how to apply     these updates to your system and frequently asked questions can be     found at: https://www.debian.org/security/

    Mailing list: debian-security-announce@lists.debian.org

Tenable has extracted the preceding description block directly from the Debian security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

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.

An update of the linux package has been released.

ID	名前	製品	ファミリー	公開日	更新日	深刻度
264737	Linux Distros のパッチ未適用の脆弱性: CVE-2025-39756	Nessus	Misc.	2025/9/14	2025/9/20	medium
264737	Linux Distros 未修补的漏洞：CVE-2025-39756	Nessus	Misc.	2025/9/14	2025/9/20	medium
264737	Linux Distros 未修補的弱點：CVE-2025-39756	Nessus	Misc.	2025/9/14	2025/9/20	medium
265709	Debian dsa-6009 : affs-modules-6.1.0-37-4kc-malta-di - security update	Nessus	Debian Local Security Checks	2025/9/22	2025/9/22	medium
264737	Linux Distros Unpatched Vulnerability : CVE-2025-39756	Nessus	Misc.	2025/9/14	2025/9/20	medium
265433	Photon OS 4.0: Linux PHSA-2025-4.0-0864	Nessus	PhotonOS Local Security Checks	2025/9/19	2025/9/19	high

検出

プラグインの検索

medium

medium

medium

medium

medium

high