{"id":"CVE-2025-39756","title":"fs: Prevent file descriptor table allocations exceeding INT_MAX","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nfs: Prevent file descriptor table allocations exceeding INT_MAX\n\nWhen sysctl_nr_open is set to a very high value (for example, 1073741816\nas set by systemd), processes …","severity":"none","vendor":"Linux","product":"Linux","affected":["Linux >= 9cfe015aa424b3c003baba3841a60dd9b5ad319b < b4159c5a90c03f8acd3de345a7f5fc63b0909818","Linux >= 9cfe015aa424b3c003baba3841a60dd9b5ad319b < f95638a8f22eba307dceddf5aef9ae2326bbcf98","Linux >= 9cfe015aa424b3c003baba3841a60dd9b5ad319b < 749528086620f8012b83ae032a80f6ffa80c45cd","Linux >= 9cfe015aa424b3c003baba3841a60dd9b5ad319b < 628fc28f42d979f36dbf75a6129ac7730e30c04e","Linux >= 9cfe015aa424b3c003baba3841a60dd9b5ad319b < 237e416eb62101f21b28c9e6e564d10efe1ecc6f","Linux >= 9cfe015aa424b3c003baba3841a60dd9b5ad319b < d4f9351243c17865a8cdbe6b3ccd09d0b13a7bcc","Linux >= 9cfe015aa424b3c003baba3841a60dd9b5ad319b < 9f61fa6a2a89a610120bc4e5d24379c667314b5c","Linux >= 9cfe015aa424b3c003baba3841a60dd9b5ad319b < dfd1f4ea98c3bd3a03d12169b5b2daa1f0a3e4ae","Linux >= 9cfe015aa424b3c003baba3841a60dd9b5ad319b < 04a2c4b4511d186b0fce685da21085a5d4acd370","Linux 2.6.25"],"published":"2025-09-11","updated":"2026-09-08","sourceUpdated":"2026-09-08T08:42:12.107Z","source":"CVEORG","sourceUrl":"https://www.cve.org/CVERecord?id=CVE-2025-39756","references":[{"url":"https://git.kernel.org/stable/c/b4159c5a90c03f8acd3de345a7f5fc63b0909818"},{"url":"https://git.kernel.org/stable/c/f95638a8f22eba307dceddf5aef9ae2326bbcf98"},{"url":"https://git.kernel.org/stable/c/749528086620f8012b83ae032a80f6ffa80c45cd"},{"url":"https://git.kernel.org/stable/c/628fc28f42d979f36dbf75a6129ac7730e30c04e"},{"url":"https://git.kernel.org/stable/c/237e416eb62101f21b28c9e6e564d10efe1ecc6f"},{"url":"https://git.kernel.org/stable/c/d4f9351243c17865a8cdbe6b3ccd09d0b13a7bcc"},{"url":"https://git.kernel.org/stable/c/9f61fa6a2a89a610120bc4e5d24379c667314b5c"},{"url":"https://git.kernel.org/stable/c/dfd1f4ea98c3bd3a03d12169b5b2daa1f0a3e4ae"},{"url":"https://git.kernel.org/stable/c/04a2c4b4511d186b0fce685da21085a5d4acd370"}],"tags":["cve.org"],"epss":0.00177,"epssPercentile":0.07503,"ingestedAt":"2026-09-08T15:33:26.997Z","slug":"CVE-2025-39756","body":"## Overview\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs: Prevent file descriptor table allocations exceeding INT_MAX\n\nWhen sysctl_nr_open is set to a very high value (for example, 1073741816\nas set by systemd), processes attempting to use file descriptors near\nthe limit can trigger massive memory allocation attempts that exceed\nINT_MAX, resulting in a WARNING in mm/slub.c:\n\n  WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288\n\nThis happens because kvmalloc_array() and kvmalloc() check if the\nrequested size exceeds INT_MAX and emit a warning when the allocation is\nnot flagged with __GFP_NOWARN.\n\nSpecifically, when nr_open is set to 1073741816 (0x3ffffff8) and a\nprocess calls dup2(oldfd, 1073741880), the kernel attempts to allocate:\n- File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes\n- Multiple bitmaps: ~400MB\n- Total allocation size: > 8GB (exceeding INT_MAX = 2,147,483,647)\n\nReproducer:\n1. Set /proc/sys/fs/nr_open to 1073741816:\n   # echo 1073741816 > /proc/sys/fs/nr_open\n\n2. Run a program that uses a high file descriptor:\n   #include <unistd.h>\n   #include <sys/resource.h>\n\n   int main() {\n       struct rlimit rlim = {1073741824, 1073741824};\n       setrlimit(RLIMIT_NOFILE, &rlim);\n       dup2(2, 1073741880);  // Triggers the warning\n       return 0;\n   }\n\n3. Observe WARNING in dmesg at mm/slub.c:5027\n\nsystemd commit a8b627a introduced automatic bumping of fs.nr_open to the\nmaximum possible value. The rationale was that systems with memory\ncontrol groups (memcg) no longer need separate file descriptor limits\nsince memory is properly accounted. However, this change overlooked\nthat:\n\n1. The kernel's allocation functions still enforce INT_MAX as a maximum\n   size regardless of memcg accounting\n2. Programs and tests that legitimately test file descriptor limits can\n   inadvertently trigger massive allocations\n3. The resulting allocations (>8GB) are impractical and will always fail\n\nsystemd's algorithm starts with INT_MAX and keeps halving the value\nuntil the kernel accepts it. On most systems, this results in nr_open\nbeing set to 1073741816 (0x3ffffff8), which is just under 1GB of file\ndescriptors.\n\nWhile processes rarely use file descriptors near this limit in normal\noperation, certain selftests (like\ntools/testing/selftests/core/unshare_test.c) and programs that test file\ndescriptor limits can trigger this issue.\n\nFix this by adding a check in alloc_fdtable() to ensure the requested\nallocation size does not exceed INT_MAX. This causes the operation to\nfail with -EMFILE instead of triggering a kernel warning and avoids the\nimpractical >8GB memory allocation request.\n\n## Affected\n\n- `Linux >= 9cfe015aa424b3c003baba3841a60dd9b5ad319b < b4159c5a90c03f8acd3de345a7f5fc63b0909818`\n- `Linux >= 9cfe015aa424b3c003baba3841a60dd9b5ad319b < f95638a8f22eba307dceddf5aef9ae2326bbcf98`\n- `Linux >= 9cfe015aa424b3c003baba3841a60dd9b5ad319b < 749528086620f8012b83ae032a80f6ffa80c45cd`\n- `Linux >= 9cfe015aa424b3c003baba3841a60dd9b5ad319b < 628fc28f42d979f36dbf75a6129ac7730e30c04e`\n- `Linux >= 9cfe015aa424b3c003baba3841a60dd9b5ad319b < 237e416eb62101f21b28c9e6e564d10efe1ecc6f`\n- `Linux >= 9cfe015aa424b3c003baba3841a60dd9b5ad319b < d4f9351243c17865a8cdbe6b3ccd09d0b13a7bcc`\n- `Linux >= 9cfe015aa424b3c003baba3841a60dd9b5ad319b < 9f61fa6a2a89a610120bc4e5d24379c667314b5c`\n- `Linux >= 9cfe015aa424b3c003baba3841a60dd9b5ad319b < dfd1f4ea98c3bd3a03d12169b5b2daa1f0a3e4ae`\n- `Linux >= 9cfe015aa424b3c003baba3841a60dd9b5ad319b < 04a2c4b4511d186b0fce685da21085a5d4acd370`\n- `Linux 2.6.25`\n\n## Remediation\n\nRefer to the linked advisories for vendor-supplied fixes and affected version ranges.","depth":"sunlit","depthScore":3,"depthScoreParts":{"impact":2.8,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[]}