CVE-2024-45025

NameCVE-2024-45025
DescriptionIn 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
SourceCVE (at NVD; CERT, LWN, oss-sec, fulldisc, Red Hat, Ubuntu, Gentoo, SUSE bugzilla/CVE, GitHub advisories/code/issues, web search, more)
ReferencesDLA-3912-1, DSA-5782-1, ELA-1219-1

Vulnerable and fixed packages

The table below lists information on source packages.

Source PackageReleaseVersionStatus
linux (PTS)jessie, jessie (lts)3.16.84-1vulnerable
stretch (security)4.9.320-2vulnerable
stretch (lts), stretch4.9.320-3vulnerable
buster (security), buster, buster (lts)4.19.316-1vulnerable
bullseye5.10.223-1vulnerable
bullseye (security)5.10.226-1fixed
bookworm6.1.115-1fixed
bookworm (security)6.1.112-1fixed
trixie6.11.7-1fixed
sid6.11.9-1fixed
linux-5.10 (PTS)jessie, jessie (lts)5.10.226-1~deb8u1fixed
stretch (lts), stretch5.10.226-1~deb9u1fixed
buster, buster (lts)5.10.226-1~deb10u1fixed
buster (security)5.10.218-1~deb10u1vulnerable

The information below is based on the following data on fixed versions.

PackageTypeReleaseFixed VersionUrgencyOriginDebian Bugs
linuxsourcejessie(unfixed)end-of-life
linuxsourcestretch(unfixed)end-of-life
linuxsourcebuster(unfixed)end-of-life
linuxsourcebullseye5.10.226-1DLA-3912-1
linuxsourcebookworm6.1.112-1DSA-5782-1
linuxsource(unstable)6.10.7-1
linux-5.10sourcejessie5.10.226-1~deb8u1ELA-1219-1
linux-5.10sourcestretch5.10.226-1~deb9u1ELA-1219-1
linux-5.10sourcebuster5.10.226-1~deb10u1ELA-1219-1

Notes

https://git.kernel.org/linus/9a2fa1472083580b6c66bdaf291f591e1170123a (6.11-rc4)

Search for package or bug name: Reporting problems