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
References
Configurations
Configuration 1 (hide)
|
History
13 Sep 2024, 16:30
Type | Values Removed | Values Added |
---|---|---|
CPE | cpe:2.3:o:linux:linux_kernel:6.11:rc1:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.11:rc3:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.11:rc2:*:*:*:*:*:* |
|
Summary |
|
|
CVSS |
v2 : v3 : |
v2 : unknown
v3 : 5.5 |
First Time |
Linux linux Kernel
Linux |
|
References | () https://git.kernel.org/stable/c/5053581fe5dfb09b58c65dd8462bf5dea71f41ff - Patch | |
References | () https://git.kernel.org/stable/c/8cad3b2b3ab81ca55f37405ffd1315bcc2948058 - Patch | |
References | () https://git.kernel.org/stable/c/9a2fa1472083580b6c66bdaf291f591e1170123a - Patch | |
References | () https://git.kernel.org/stable/c/c69d18f0ac7060de724511537810f10f29a27958 - Patch | |
References | () https://git.kernel.org/stable/c/dd72ae8b0fce9c0bbe9582b9b50820f0407f8d8a - Patch | |
References | () https://git.kernel.org/stable/c/e807487a1d5fd5d941f26578ae826ca815dbfcd6 - Patch | |
References | () https://git.kernel.org/stable/c/ee501f827f3db02d4e599afbbc1a7f8b792d05d7 - Patch | |
References | () https://git.kernel.org/stable/c/fe5bf14881701119aeeda7cf685f3c226c7380df - Patch | |
CWE | CWE-787 |
11 Sep 2024, 16:15
Type | Values Removed | Values Added |
---|---|---|
New CVE |
Information
Published : 2024-09-11 16:15
Updated : 2024-09-13 16:30
NVD link : CVE-2024-45025
Mitre link : CVE-2024-45025
CVE.ORG link : CVE-2024-45025
JSON object : View
Products Affected
linux
- linux_kernel
CWE
CWE-787
Out-of-bounds Write