From: Linus Torvalds Date: Thu, 8 Apr 2021 15:46:53 +0000 (-0700) Subject: Merge tag 'for-linus-2021-04-08' of git://git.kernel.org/pub/scm/linux/kernel/git... X-Git-Url: http://git.maquefel.me/?a=commitdiff_plain;h=4ea51e0e37c890847eb2b402b01389ae099efec1;p=linux.git 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 --- 4ea51e0e37c890847eb2b402b01389ae099efec1