CVE-2024-45025

Source
https://nvd.nist.gov/vuln/detail/CVE-2024-45025
Import Source
https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2024-45025.json
JSON Data
https://api.test.osv.dev/v1/vulns/CVE-2024-45025
Downstream
Related
Published
2024-09-11T15:13:57.732Z
Modified
2025-11-28T02:34:42.262238Z
Summary
fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE
Details

In the Linux kernel, the following vulnerability has been resolved:

fix bitmap corruption on closerange() with CLOSERANGE_UNSHARE

copyfdbitmaps(new, old, count) is expected to copy the first count/BITSPERLONG bits from old->fullfdsbits[] and fill the rest with zeroes. What it does is copying enough words (BITSTOLONGS(count/BITSPERLONG)), 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 - expandfdtable() has count equal to old->maxfds, so there's no open descriptors past count, let alone fully occupied words in ->openfds[], which is what bits in ->fullfds_bits[] correspond to.

The other caller (dupfd()) passes sanefdtablesize(oldfdt, maxfds), which is the smallest multiple of BITSPERLONG that covers all opened descriptors below maxfds. In the common case (copying on fork()) maxfds is ~0U, so all opened descriptors will be below it and we are fine, by the same reasons why the call in expandfdtable() is safe.

Unfortunately, there is a case where maxfds is less than that and where we might, indeed, end up with junk in ->fullfdsbits[] - closerange(from, to, CLOSERANGEUNSHARE) 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 CLONEFILES, get all descriptors in range 0..127 open, then closerange(64, ~0U, CLOSERANGEUNSHARE) 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 dupfd(). If this proves to add measurable overhead, we can go that way, but let's try to fix copyfd_bitmaps() first.

  • new helper: bitmapcopyandexpand(to, from, bitsto_copy, size).
  • make copyfdbitmaps() take the bitmap size in words, rather than bits; it's 'count' argument is always a multiple of BITSPERLONG, 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 BITSPERLONG for the large ones, so it'll generate plain memcpy()+memset().

Reproducer added to tools/testing/selftests/core/closerangetest.c

Database specific
{
    "cna_assigner": "Linux",
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/45xxx/CVE-2024-45025.json"
}
References

Affected packages

Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Affected ranges

Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
278a5fbaed89dacd04e9d052f4594ffd0e0585de
Fixed
fe5bf14881701119aeeda7cf685f3c226c7380df
Fixed
5053581fe5dfb09b58c65dd8462bf5dea71f41ff
Fixed
8cad3b2b3ab81ca55f37405ffd1315bcc2948058
Fixed
dd72ae8b0fce9c0bbe9582b9b50820f0407f8d8a
Fixed
c69d18f0ac7060de724511537810f10f29a27958
Fixed
9a2fa1472083580b6c66bdaf291f591e1170123a

Linux / Kernel

Package

Name
Kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
5.9.0
Fixed
5.10.225
Type
ECOSYSTEM
Events
Introduced
5.11.0
Fixed
5.15.166
Type
ECOSYSTEM
Events
Introduced
5.16.0
Fixed
6.1.107
Type
ECOSYSTEM
Events
Introduced
6.2.0
Fixed
6.6.48
Type
ECOSYSTEM
Events
Introduced
6.7.0
Fixed
6.10.7