linux-stable.git/fs, branch v3.16.45

mm: larger stack guard gap, between vmas

2017-07-02T16:13:02+00:00

commit 1be7107fbe18eed3e319a6c3e83c78254b693acb upstream.

Stack guard page is a useful feature to reduce a risk of stack smashing
into a different mapping. We have been using a single page gap which
is sufficient to prevent having stack adjacent to a different mapping.
But this seems to be insufficient in the light of the stack usage in
userspace. E.g. glibc uses as large as 64kB alloca() in many commonly
used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX]
which is 256kB or stack strings with MAX_ARG_STRLEN.

This will become especially dangerous for suid binaries and the default
no limit for the stack size limit because those applications can be
tricked to consume a large portion of the stack and a single glibc call
could jump over the guard page. These attacks are not theoretical,
unfortunatelly.

Make those attacks less probable by increasing the stack guard gap
to 1MB (on systems with 4k pages; but make it depend on the page size
because systems with larger base pages might cap stack allocations in
the PAGE_SIZE units) which should cover larger alloca() and VLA stack
allocations. It is obviously not a full fix because the problem is
somehow inherent, but it should reduce attack space a lot.

One could argue that the gap size should be configurable from userspace,
but that can be done later when somebody finds that the new 1MB is wrong
for some special case applications.  For now, add a kernel command line
option (stack_guard_gap) to specify the stack gap size (in page units).

Implementation wise, first delete all the old code for stack guard page:
because although we could get away with accounting one extra page in a
stack vma, accounting a larger gap can break userspace - case in point,
a program run with "ulimit -S -v 20000" failed when the 1MB gap was
counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK
and strict non-overcommit mode.

Instead of keeping gap inside the stack vma, maintain the stack guard
gap as a gap between vmas: using vm_start_gap() in place of vm_start
(or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few
places which need to respect the gap - mainly arch_get_unmapped_area(),
and and the vma tree's subtree_gap support for that.

Original-patch-by: Oleg Nesterov 
Original-patch-by: Michal Hocko 
Signed-off-by: Hugh Dickins 
Acked-by: Michal Hocko 
Tested-by: Helge Deller  # parisc
Signed-off-by: Linus Torvalds 
[Hugh Dickins: Backported to 3.16]
Signed-off-by: Ben Hutchings

nfsd: stricter decoding of write-like NFSv2/v3 ops

2017-06-05T20:17:23+00:00

commit 13bf9fbff0e5e099e2b6f003a0ab8ae145436309 upstream.

The NFSv2/v3 code does not systematically check whether we decode past
the end of the buffer.  This generally appears to be harmless, but there
are a few places where we do arithmetic on the pointers involved and
don't account for the possibility that a length could be negative.  Add
checks to catch these.

Reported-by: Tuomas Haanpää 
Reported-by: Ari Kauppi 
Reviewed-by: NeilBrown 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Ben Hutchings

nfsd4: minor NFSv2/v3 write decoding cleanup

2017-06-05T20:17:23+00:00

commit db44bac41bbfc0c0d9dd943092d8bded3c9db19b upstream.

Use a couple shortcuts that will simplify a following bugfix.

Signed-off-by: J. Bruce Fields 
[bwh: Backported to 3.16: in nfs3svc_decode_writeargs(), dlen doesn't include
 tail]
Signed-off-by: Ben Hutchings

nfsd: check for oversized NFSv2/v3 arguments

2017-06-05T20:17:23+00:00

commit e6838a29ecb484c97e4efef9429643b9851fba6e upstream.

A client can append random data to the end of an NFSv2 or NFSv3 RPC call
without our complaining; we'll just stop parsing at the end of the
expected data and ignore the rest.

Encoded arguments and replies are stored together in an array of pages,
and if a call is too large it could leave inadequate space for the
reply.  This is normally OK because NFS RPC's typically have either
short arguments and long replies (like READ) or long arguments and short
replies (like WRITE).  But a client that sends an incorrectly long reply
can violate those assumptions.  This was observed to cause crashes.

Also, several operations increment rq_next_page in the decode routine
before checking the argument size, which can leave rq_next_page pointing
well past the end of the page array, causing trouble later in
svc_free_pages.

So, following a suggestion from Neil Brown, add a central check to
enforce our expectation that no NFSv2/v3 call has both a large call and
a large reply.

As followup we may also want to rewrite the encoding routines to check
more carefully that they aren't running off the end of the page array.

We may also consider rejecting calls that have any extra garbage
appended.  That would be safer, and within our rights by spec, but given
the age of our server and the NFS protocol, and the fact that we've
never enforced this before, we may need to balance that against the
possibility of breaking some oddball client.

Reported-by: Tuomas Haanpää 
Reported-by: Ari Kauppi 
Reviewed-by: NeilBrown 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Ben Hutchings

NFSv4: fix getacl ERANGE for some ACL buffer sizes

2017-06-05T20:17:16+00:00

commit ed92d8c137b7794c2c2aa14479298b9885967607 upstream.

We're not taking into account that the space needed for the (variable
length) attr bitmap, with the result that we'd sometimes get a spurious
ERANGE when the ACL data got close to the end of a page.

Just add in an extra page to make sure.

Signed-off-by: Weston Andros Adamson 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Anna Schumaker 
Signed-off-by: Ben Hutchings

NFSv4: fix getacl head length estimation

2017-06-05T20:17:15+00:00

commit 6682c14bbe505a8b912c57faf544f866777ee48d upstream.

Bitmap and attrlen follow immediately after the op reply header.  This
was an oversight from commit bf118a342f.

Consequences of this are just minor efficiency (extra calls to
xdr_shrink_bufhead).

Fixes: bf118a342f10 "NFSv4: include bitmap in nfsv4 get acl data"
Reviewed-by: Kinglong Mee 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Anna Schumaker 
Signed-off-by: Ben Hutchings

f2fs: add ovp valid_blocks check for bg gc victim to fg_gc

2017-06-05T20:17:15+00:00

commit e93b9865251a0503d83fd570e7d5a7c8bc351715 upstream.

For foreground gc, greedy algorithm should be adapted, which makes
this formula work well:

	(2 * (100 / config.overprovision + 1) + 6)

But currently, we fg_gc have a prior to select bg_gc victim segments to gc
first, these victims are selected by cost-benefit algorithm, we can't guarantee
such segments have the small valid blocks, which may destroy the f2fs rule, on
the worstest case, would consume all the free segments.

This patch fix this by add a filter in check_bg_victims, if segment's has # of
valid blocks over overprovision ratio, skip such segments.

Signed-off-by: Hou Pengyang 
Reviewed-by: Chao Yu 
Signed-off-by: Jaegeuk Kim 
[bwh: Backported to 3.16:
 - In get_victim_by_default(), use continue rather than goto
 - Adjust context]
Signed-off-by: Ben Hutchings

f2fs: use for_each_set_bit to simplify the code

2017-06-05T20:17:15+00:00

commit b65ee14818e67127aa242fe1dbd3711b9c095cc0 upstream.

This patch uses for_each_set_bit to simplify some codes in f2fs.

Signed-off-by: Chao Yu 
Signed-off-by: Jaegeuk Kim 
Signed-off-by: Ben Hutchings

fuse: add missing FR_FORCE

2017-06-05T20:17:13+00:00

commit 2e38bea99a80eab408adee27f873a188d57b76cb upstream.

fuse_file_put() was missing the "force" flag for the RELEASE request when
sending synchronously (fuseblk).

If this flag is not set, then a sync request may be interrupted before it
is dequeued by the userspace filesystem.  In this case the OPEN won't be
balanced with a RELEASE.

Signed-off-by: Miklos Szeredi 
Fixes: 5a18ec176c93 ("fuse: fix hang of single threaded fuseblk filesystem")
[bwh: Backported to 3.16:
 - "force" flag is a bitfield
 - Adjust context]
Signed-off-by: Ben Hutchings

NFSv4: Fix the underestimation of delegation XDR space reservation

2017-06-05T20:17:13+00:00

commit 5a1f6d9e9b803003271b40b67786ff46fa4eda01 upstream.

Account for the "space_limit" field in struct open_write_delegation4.

Fixes: 2cebf82883f4 ("NFSv4: Fix the underestimate of NFSv4 open request size")
Signed-off-by: Trond Myklebust 
Reviewed-by: Chuck Lever 
Signed-off-by: Anna Schumaker 
Signed-off-by: Ben Hutchings