CVE-2024-45025: Vulnerability in Linux Linux

Severity: mediumType: vulnerabilityCVE-2024-45025

In the Linux kernel, the following vulnerability has been resolved: fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE copy_fd_bitmaps(new, old, count) is expected to copy the first count/BITS_PER_LONG bits from old->full_fds_bits[] and fill the rest with zeroes. What it does is copying enough words (BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest. That works fine, *if* all bits past the cutoff point are clear. Otherwise we are risking garbage from the last word we'd copied. For most of the callers that is true - expand_fdtable() has count equal to old->max_fds, so there's no open descriptors past count, let alone fully occupied words in ->open_fds[], which is what bits in ->full_fds_bits[] correspond to. The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds), which is the smallest multiple of BITS_PER_LONG that covers all opened descriptors below max_fds. In the common case (copying on fork()) max_fds is ~0U, so all opened descriptors will be below it and we are fine, by the same reasons why the call in expand_fdtable() is safe. Unfortunately, there is a case where max_fds is less than that and where we might, indeed, end up with junk in ->full_fds_bits[] - close_range(from, to, CLOSE_RANGE_UNSHARE) with * descriptor table being currently shared * 'to' being above the current capacity of descriptor table * 'from' being just under some chunk of opened descriptors. In that case we end up with observably wrong behaviour - e.g. spawn a child with CLONE_FILES, get all descriptors in range 0..127 open, then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending up with descriptor #128, despite #64 being observably not open. The minimally invasive fix would be to deal with that in dup_fd(). If this proves to add measurable overhead, we can go that way, but let's try to fix copy_fd_bitmaps() first. * new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size). * make copy_fd_bitmaps() take the bitmap size in words, rather than bits; it's 'count' argument is always a multiple of BITS_PER_LONG, so we are not losing any information, and that way we can use the same helper for all three bitmaps - compiler will see that count is a multiple of BITS_PER_LONG for the large ones, so it'll generate plain memcpy()+memset(). Reproducer added to tools/testing/selftests/core/close_range_test.c

AI Analysis

Technical Summary

CVE-2024-45025 is a vulnerability identified in the Linux kernel related to improper handling of file descriptor bitmaps during the close_range() system call when used with the CLOSE_RANGE_UNSHARE flag. The core issue lies in the function copy_fd_bitmaps(), which is responsible for copying bits representing open file descriptors from an old bitmap to a new one. The function is expected to copy the first count/BITS_PER_LONG bits and zero out the rest. However, due to an implementation detail, it copies whole words (units of bits) and then zeroes out the remainder, which is safe only if all bits past the cutoff are clear. In certain edge cases, particularly when close_range() is called with CLOSE_RANGE_UNSHARE on a shared descriptor table and the 'to' parameter exceeds the current descriptor table capacity, this assumption fails. This leads to residual garbage bits in the bitmap, causing incorrect tracking of open file descriptors. For example, after closing descriptors in a range, a subsequent dup(0) call might incorrectly assign a descriptor number that should have been freed, potentially leading to descriptor leaks or unexpected behavior in file descriptor management. The vulnerability arises from the bitmap copy logic not properly handling partial words when the maximum file descriptor count is less than the full range of descriptors. The Linux kernel patch addresses this by introducing a new helper function bitmap_copy_and_expand() that correctly copies and zeroes bits, and by adjusting copy_fd_bitmaps() to take the bitmap size in words rather than bits, ensuring safe copying and zeroing. A reproducer test case has been added to the kernel selftests to validate the fix. This vulnerability affects Linux kernel versions identified by the commit hash 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and potentially other versions sharing this code path. No known exploits are currently reported in the wild.

Potential Impact

For European organizations, this vulnerability could lead to subtle but impactful issues in systems relying heavily on Linux kernel file descriptor management, especially those using close_range() with CLOSE_RANGE_UNSHARE in multi-threaded or containerized environments. The incorrect bitmap handling can cause file descriptor leaks or unexpected descriptor assignments, potentially leading to resource exhaustion or unpredictable application behavior. While this vulnerability does not directly allow privilege escalation or remote code execution, it can degrade system stability and reliability, which is critical for servers, cloud infrastructure, and embedded devices running Linux. Systems performing high volumes of process forking, descriptor sharing, or container management might be particularly affected. In regulated industries such as finance, healthcare, or critical infrastructure within Europe, such instability could violate compliance requirements or cause service disruptions. Furthermore, the subtle nature of the bug may complicate troubleshooting and incident response, increasing operational risk.

Mitigation Recommendations

European organizations should prioritize updating their Linux kernel to the patched version that includes the fix for CVE-2024-45025 as soon as it becomes available from their Linux distribution vendors. In the interim, system administrators should audit usage of close_range() with CLOSE_RANGE_UNSHARE, especially in custom or containerized applications, to identify and mitigate risky usage patterns. Monitoring for unusual file descriptor behavior or leaks in critical applications can help detect exploitation or impact. Additionally, organizations should enforce strict process isolation and limit the use of shared file descriptor tables where possible. For environments using container orchestration platforms like Kubernetes, ensuring that underlying nodes are patched and that container runtimes do not expose vulnerable kernel interfaces is essential. Finally, incorporating the reproducer test from the Linux kernel selftests into internal testing pipelines can help verify that systems are not affected post-patching.