summaryrefslogtreecommitdiffstats
path: root/fs/exportfs
diff options
context:
space:
mode:
authorEric Sandeen <sandeen@redhat.com>2019-10-02 16:17:54 -0500
committerLinus Torvalds <torvalds@linux-foundation.org>2019-10-03 14:21:35 -0700
commitcc3a7bfe62b947b423fcb2cfe89fcba92bf48fa3 (patch)
tree35fc83c3f92553cce868f9e1f31305a353485c98 /fs/exportfs
parentc1053cd122b23519322c8256ca24487e3b9695ce (diff)
downloadlinux-stable-cc3a7bfe62b947b423fcb2cfe89fcba92bf48fa3.tar.gz
linux-stable-cc3a7bfe62b947b423fcb2cfe89fcba92bf48fa3.tar.bz2
linux-stable-cc3a7bfe62b947b423fcb2cfe89fcba92bf48fa3.zip
vfs: Fix EOVERFLOW testing in put_compat_statfs64
Today, put_compat_statfs64() disallows nearly any field value over 2^32 if f_bsize is only 32 bits, but that makes no sense. compat_statfs64 is there for the explicit purpose of providing 64-bit fields for f_files, f_ffree, etc. And f_bsize is always only 32 bits. As a result, 32-bit userspace gets -EOVERFLOW for i.e. large file counts even with -D_FILE_OFFSET_BITS=64 set. In reality, only f_bsize and f_frsize can legitimately overflow (fields like f_type and f_namelen should never be large), so test only those fields. This bug was discussed at length some time ago, and this is the proposal Al suggested at https://lkml.org/lkml/2018/8/6/640. It seemed to get dropped amid the discussion of other related changes, but this part seems obviously correct on its own, so I've picked it up and sent it, for expediency. Fixes: 64d2ab32efe3 ("vfs: fix put_compat_statfs64() does not handle errors") Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs/exportfs')
0 files changed, 0 insertions, 0 deletions