diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2020-12-19 13:03:12 -0800 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2020-12-19 13:03:12 -0800 |
commit | 467f8165a2b0e6accf3d0dd9c8089b1dbde29f7f (patch) | |
tree | 430c86173fec8ced14bedb83851f9fa476fa5cd6 /fs | |
parent | 3872f516aab34e3adeb7eda43b29c1ecd852cee1 (diff) | |
parent | 6abc20f8f879d891930f37186b19c9dc3ecc34dd (diff) |
Merge tag 'close-range-cloexec-unshare-v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux
Pull close_range fix from Christian Brauner:
"syzbot reported a bug when asking close_range() to unshare the file
descriptor table and making all fds close-on-exec.
If CLOSE_RANGE_UNSHARE the caller will receive a private file
descriptor table in case their file descriptor table is currently
shared before operating on the requested file descriptor range.
For the case where the caller has requested all file descriptors to be
actually closed via e.g. close_range(3, ~0U, CLOSE_RANGE_UNSHARE) the
kernel knows that the caller does not need any of the file descriptors
anymore and will optimize the close operation by only copying all
files in the range from 0 to 3 and no others.
However, if the caller requested CLOSE_RANGE_CLOEXEC together with
CLOSE_RANGE_UNSHARE the caller wants to still make use of the file
descriptors so the kernel needs to copy all of them and can't
optimize.
The original patch didn't account for this and thus could cause oopses
as evidenced by the syzbot report because it assumed that all fds had
been copied. Fix this by handling the CLOSE_RANGE_CLOEXEC case and
copying all fds if the two flags are specified together.
This should've been caught in the selftests but the original patch
didn't cover this case and I didn't catch it during review. So in
addition to the bugfix I'm also adding selftests. They will reliably
reproduce the bug on a non-fixed kernel and allows us to catch
regressions and verify correct behavior.
Note, the kernel selftest tree contained a bunch of changes that made
the original selftest fail to compile so there are small fixups in
here make them compile without warnings"
* tag 'close-range-cloexec-unshare-v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux:
selftests/core: add regression test for CLOSE_RANGE_UNSHARE | CLOSE_RANGE_CLOEXEC
selftests/core: add test for CLOSE_RANGE_UNSHARE | CLOSE_RANGE_CLOEXEC
selftests/core: handle missing syscall number for close_range
selftests/core: fix close_range_test build after XFAIL removal
close_range: unshare all fds for CLOSE_RANGE_UNSHARE | CLOSE_RANGE_CLOEXEC
Diffstat (limited to 'fs')
-rw-r--r-- | fs/file.c | 4 |
1 files changed, 3 insertions, 1 deletions
diff --git a/fs/file.c b/fs/file.c index 8434e0afecc7..c0b60961c672 100644 --- a/fs/file.c +++ b/fs/file.c @@ -694,8 +694,10 @@ int __close_range(unsigned fd, unsigned max_fd, unsigned int flags) * If the requested range is greater than the current maximum, * we're closing everything so only copy all file descriptors * beneath the lowest file descriptor. + * If the caller requested all fds to be made cloexec copy all + * of the file descriptors since they still want to use them. */ - if (max_fd >= cur_max) + if (!(flags & CLOSE_RANGE_CLOEXEC) && (max_fd >= cur_max)) max_unshare_fds = fd; ret = unshare_fd(CLONE_FILES, max_unshare_fds, &fds); |