{"vulnerability": "CVE-2024-45025", "sightings": [{"uuid": "c219e6d3-ce63-44b1-bd03-19d1c36f9500", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-45025", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"}, {"uuid": "145dd203-651c-4946-9875-1eff645e3ab1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-45025", "type": "published-proof-of-concept", "source": "https://t.me/cvedetector/5368", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-45025 - Linux Kernel bitmap corruption vulnerability in close_range().\", \n  \"Content\": \"CVE ID : CVE-2024-45025 \nPublished : Sept. 11, 2024, 4:15 p.m. | 16\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nfix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE  \n  \ncopy_fd_bitmaps(new, old, count) is expected to copy the first  \ncount/BITS_PER_LONG bits from old->full_fds_bits[] and fill  \nthe rest with zeroes.  What it does is copying enough words  \n(BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.  \nThat works fine, *if* all bits past the cutoff point are  \nclear.  Otherwise we are risking garbage from the last word  \nwe'd copied.  \n  \nFor most of the callers that is true - expand_fdtable() has  \ncount equal to old->max_fds, so there's no open descriptors  \npast count, let alone fully occupied words in ->open_fds[],  \nwhich is what bits in ->full_fds_bits[] correspond to.  \n  \nThe other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),  \nwhich is the smallest multiple of BITS_PER_LONG that covers all  \nopened descriptors below max_fds.  In the common case (copying on  \nfork()) max_fds is ~0U, so all opened descriptors will be below  \nit and we are fine, by the same reasons why the call in expand_fdtable()  \nis safe.  \n  \nUnfortunately, there is a case where max_fds is less than that  \nand where we might, indeed, end up with junk in ->full_fds_bits[] -  \nclose_range(from, to, CLOSE_RANGE_UNSHARE) with  \n * descriptor table being currently shared  \n * 'to' being above the current capacity of descriptor table  \n * 'from' being just under some chunk of opened descriptors.  \nIn that case we end up with observably wrong behaviour - e.g. spawn  \na child with CLONE_FILES, get all descriptors in range 0..127 open,  \nthen close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending  \nup with descriptor #128, despite #64 being observably not open.  \n  \nThe minimally invasive fix would be to deal with that in dup_fd().  \nIf this proves to add measurable overhead, we can go that way, but  \nlet's try to fix copy_fd_bitmaps() first.  \n  \n* new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).  \n* make copy_fd_bitmaps() take the bitmap size in words, rather than  \nbits; it's 'count' argument is always a multiple of BITS_PER_LONG,  \nso we are not losing any information, and that way we can use the  \nsame helper for all three bitmaps - compiler will see that count  \nis a multiple of BITS_PER_LONG for the large ones, so it'll generate  \nplain memcpy()+memset().  \n  \nReproducer added to tools/testing/selftests/core/close_range_test.c \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"11 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-11T18:41:20.000000Z"}]}