Merge tag 'for-linus-2021-04-08' of git://git.kernel.org/pub/scm/linux/kernel/git...
authorLinus Torvalds <torvalds@linux-foundation.org>
Thu, 8 Apr 2021 15:46:53 +0000 (08:46 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Thu, 8 Apr 2021 15:46:53 +0000 (08:46 -0700)
commit4ea51e0e37c890847eb2b402b01389ae099efec1
tree17ae82c87ac95e1212c006e2406a7327e512975b
parent035d80695fae55ed3e788cd8a62525657a43b924
parent9b5b872215fe6d1ca6a1ef411f130bd58e269012
Merge tag 'for-linus-2021-04-08' of git://git./linux/kernel/git/brauner/linux

Pull close_range() fix from Christian Brauner:
 "Syzbot reported a bug in close_range.

  Debugging this showed we didn't recalculate the current maximum fd
  number for CLOSE_RANGE_UNSHARE | CLOSE_RANGE_CLOEXEC after we unshared
  the file descriptors table. As a result, max_fd could exceed the
  current fdtable maximum causing us to set excessive bits.

  As a concrete example, let's say the user requested everything from fd
  4 to ~0UL to be closed and their current fdtable size is 256 with
  their highest open fd being 4. With CLOSE_RANGE_UNSHARE the caller
  will end up with a new fdtable which has room for 64 file descriptors
  since that is the lowest fdtable size we accept. But now max_fd will
  still point to 255 and needs to be adjusted. Fix this by retrieving
  the correct maximum fd value in __range_cloexec().

  I've carried this fix for a little while but since there was no
  linux-next release over easter I waited until now.

  With this change close_range() can be further simplified but imho we
  are in no hurry to do that and so I'll defer this for the 5.13 merge
  window"

* tag 'for-linus-2021-04-08' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux:
  file: fix close_range() for unshare+cloexec