summaryrefslogtreecommitdiff
path: root/arch
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2021-04-08 18:46:53 +0300
committerLinus Torvalds <torvalds@linux-foundation.org>2021-04-08 18:46:53 +0300
commit4ea51e0e37c890847eb2b402b01389ae099efec1 (patch)
tree17ae82c87ac95e1212c006e2406a7327e512975b /arch
parent035d80695fae55ed3e788cd8a62525657a43b924 (diff)
parent9b5b872215fe6d1ca6a1ef411f130bd58e269012 (diff)
downloadlinux-4ea51e0e37c890847eb2b402b01389ae099efec1.tar.xz
Merge tag 'for-linus-2021-04-08' of git://git.kernel.org/pub/scm/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
Diffstat (limited to 'arch')
0 files changed, 0 insertions, 0 deletions