linux-stable.git/fs, branch v4.1.41

fs/xattr.c: zero out memory copied to userspace in getxattr

2017-06-13T13:29:21+00:00

[ Upstream commit 81be3dee96346fbe08c31be5ef74f03f6b63cf68 ]

getxattr uses vmalloc to allocate memory if kzalloc fails.  This is
filled by vfs_getxattr and then copied to the userspace.  vmalloc,
however, doesn't zero out the memory so if the specific implementation
of the xattr handler is sloppy we can theoretically expose a kernel
memory.  There is no real sign this is really the case but let's make
sure this will not happen and use vzalloc instead.

Fixes: 779302e67835 ("fs/xattr.c:getxattr(): improve handling of allocation failures")
Link: http://lkml.kernel.org/r/20170306103327.2766-1-mhocko@kernel.org
Acked-by: Kees Cook 
Reported-by: Vlastimil Babka 
Signed-off-by: Michal Hocko 
Cc: 	[3.6+]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

f2fs: sanity check segment count

2017-06-13T13:29:21+00:00

[ Upstream commit b9dd46188edc2f0d1f37328637860bb65a771124 ]

F2FS uses 4 bytes to represent block address. As a result, supported
size of disk is 16 TB and it equals to 16 * 1024 * 1024 / 2 segments.

Signed-off-by: Jin Qian 
Signed-off-by: Jaegeuk Kim 
Signed-off-by: Sasha Levin

9p: fix a potential acl leak

2017-06-13T13:29:19+00:00

[ Upstream commit b5c66bab72a6a65edb15beb60b90d3cb84c5763b ]

posix_acl_update_mode() could possibly clear 'acl', if so we leak the
memory pointed by 'acl'.  Save this pointer before calling
posix_acl_update_mode() and release the memory if 'acl' really gets
cleared.

Link: http://lkml.kernel.org/r/1486678332-2430-1-git-send-email-xiyou.wangcong@gmail.com
Signed-off-by: Cong Wang 
Reported-by: Mark Salyzyn 
Reviewed-by: Jan Kara 
Reviewed-by: Greg Kurz 
Cc: Eric Van Hensbergen 
Cc: Ron Minnich 
Cc: Latchesar Ionkov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

timerfd: Protect the might cancel mechanism proper

2017-06-13T13:29:19+00:00

[ Upstream commit 1e38da300e1e395a15048b0af1e5305bd91402f6 ]

The handling of the might_cancel queueing is not properly protected, so
parallel operations on the file descriptor can race with each other and
lead to list corruptions or use after free.

Protect the context for these operations with a seperate lock.

The wait queue lock cannot be reused for this because that would create a
lock inversion scenario vs. the cancel lock. Replacing might_cancel with an
atomic (atomic_t or atomic bit) does not help either because it still can
race vs. the actual list operation.

Reported-by: Dmitry Vyukov 
Signed-off-by: Thomas Gleixner 
Cc: "linux-fsdevel@vger.kernel.org"
Cc: syzkaller 
Cc: Al Viro 
Cc: linux-fsdevel@vger.kernel.org
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1701311521430.3457@nanos
Signed-off-by: Thomas Gleixner 
Signed-off-by: Sasha Levin

f2fs: do more integrity verification for superblock

2017-06-13T13:29:18+00:00

[ Upstream commit 9a59b62fd88196844cee5fff851bee2cfd7afb6e ]

Do more sanity check for superblock during ->mount.

Signed-off-by: Chao Yu 
Signed-off-by: Jaegeuk Kim 
Signed-off-by: Sasha Levin

gfs2: avoid uninitialized variable warning

2017-06-13T13:29:17+00:00

[ Upstream commit 67893f12e5374bbcaaffbc6e570acbc2714ea884 ]

We get a bogus warning about a potential uninitialized variable
use in gfs2, because the compiler does not figure out that we
never use the leaf number if get_leaf_nr() returns an error:

fs/gfs2/dir.c: In function 'get_first_leaf':
fs/gfs2/dir.c:802:9: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized]
fs/gfs2/dir.c: In function 'dir_split_leaf':
fs/gfs2/dir.c:1021:8: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized]

Changing the 'if (!error)' to 'if (!IS_ERR_VALUE(error))' is
sufficient to let gcc understand that this is exactly the same
condition as in IS_ERR() so it can optimize the code path enough
to understand it.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Bob Peterson 
Signed-off-by: Sasha Levin

xfs: Fix missed holes in SEEK_HOLE implementation

2017-06-08T10:41:59+00:00

[ Upstream commit 5375023ae1266553a7baa0845e82917d8803f48c ]

XFS SEEK_HOLE implementation could miss a hole in an unwritten extent as
can be seen by the following command:

xfs_io -c "falloc 0 256k" -c "pwrite 0 56k" -c "pwrite 128k 8k"
       -c "seek -h 0" file
wrote 57344/57344 bytes at offset 0
56 KiB, 14 ops; 0.0000 sec (49.312 MiB/sec and 12623.9856 ops/sec)
wrote 8192/8192 bytes at offset 131072
8 KiB, 2 ops; 0.0000 sec (70.383 MiB/sec and 18018.0180 ops/sec)
Whence	Result
HOLE	139264

Where we can see that hole at offset 56k was just ignored by SEEK_HOLE
implementation. The bug is in xfs_find_get_desired_pgoff() which does
not properly detect the case when pages are not contiguous.

Fix the problem by properly detecting when found page has larger offset
than expected.

CC: stable@vger.kernel.org
Fixes: d126d43f631f996daeee5006714fed914be32368
Signed-off-by: Jan Kara 
Reviewed-by: Brian Foster 
Reviewed-by: Darrick J. Wong 
Signed-off-by: Darrick J. Wong 
Signed-off-by: Sasha Levin

xfs: fix off-by-one on max nr_pages in xfs_find_get_desired_pgoff()

2017-06-08T10:41:59+00:00

[ Upstream commit 8affebe16d79ebefb1d9d6d56a46dc89716f9453 ]

xfs_find_get_desired_pgoff() is used to search for offset of hole or
data in page range [index, end] (both inclusive), and the max number
of pages to search should be at least one, if end == index.
Otherwise the only page is missed and no hole or data is found,
which is not correct.

When block size is smaller than page size, this can be demonstrated
by preallocating a file with size smaller than page size and writing
data to the last block. E.g. run this xfs_io command on a 1k block
size XFS on x86_64 host.

  # xfs_io -fc "falloc 0 3k" -c "pwrite 2k 1k" \
  	    -c "seek -d 0" /mnt/xfs/testfile
  wrote 1024/1024 bytes at offset 2048
  1 KiB, 1 ops; 0.0000 sec (33.675 MiB/sec and 34482.7586 ops/sec)
  Whence  Result
  DATA    EOF

Data at offset 2k was missed, and lseek(2) returned ENXIO.

This is uncovered by generic/285 subtest 07 and 08 on ppc64 host,
where pagesize is 64k. Because a recent change to generic/285
reduced the preallocated file size to smaller than 64k.

Cc: stable@vger.kernel.org # v3.7+
Signed-off-by: Eryu Guan 
Reviewed-by: Jan Kara 
Reviewed-by: Darrick J. Wong 
Signed-off-by: Darrick J. Wong 
Signed-off-by: Sasha Levin

nfsd: encoders mustn't use unitialized values in error cases

2017-05-28T10:36:09+00:00

[ Upstream commit f961e3f2acae94b727380c0b74e2d3954d0edf79 ]

In error cases, lgp->lg_layout_type may be out of bounds; so we
shouldn't be using it until after the check of nfserr.

This was seen to crash nfsd threads when the server receives a LAYOUTGET
request with a large layout type.

GETDEVICEINFO has the same problem.

Reported-by: Ari Kauppi 
Reviewed-by: Christoph Hellwig 
Cc: stable@vger.kernel.org
Signed-off-by: J. Bruce Fields 
Signed-off-by: Sasha Levin

CIFS: add misssing SFM mapping for doublequote

2017-05-28T10:36:09+00:00

[ Upstream commit 85435d7a15294f9f7ef23469e6aaf7c5dfcc54f0 ]

SFM is mapping doublequote to 0xF020

Without this patch creating files with doublequote fails to Windows/Mac

Signed-off-by: Bjoern Jacke 
Signed-off-by: Steve French 
CC: stable 
Signed-off-by: Sasha Levin