diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2021-04-08 08:46:53 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2021-04-08 08:46:53 -0700 |
commit | 4ea51e0e37c890847eb2b402b01389ae099efec1 (patch) | |
tree | 17ae82c87ac95e1212c006e2406a7327e512975b /arch | |
parent | 035d80695fae55ed3e788cd8a62525657a43b924 (diff) | |
parent | 9b5b872215fe6d1ca6a1ef411f130bd58e269012 (diff) | |
download | lwn-4ea51e0e37c890847eb2b402b01389ae099efec1.tar.gz lwn-4ea51e0e37c890847eb2b402b01389ae099efec1.zip |
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