linux-stable.git/fs/xfs, branch v3.2.78

fs: create and use seq_show_option for escaping

2015-10-13T02:46:08+00:00

commit a068acf2ee77693e0bf39d6e07139ba704f461c3 upstream.

Many file systems that implement the show_options hook fail to correctly
escape their output which could lead to unescaped characters (e.g.  new
lines) leaking into /proc/mounts and /proc/[pid]/mountinfo files.  This
could lead to confusion, spoofed entries (resulting in things like
systemd issuing false d-bus "mount" notifications), and who knows what
else.  This looks like it would only be the root user stepping on
themselves, but it's possible weird things could happen in containers or
in other situations with delegated mount privileges.

Here's an example using overlay with setuid fusermount trusting the
contents of /proc/mounts (via the /etc/mtab symlink).  Imagine the use
of "sudo" is something more sneaky:

  $ BASE="ovl"
  $ MNT="$BASE/mnt"
  $ LOW="$BASE/lower"
  $ UP="$BASE/upper"
  $ WORK="$BASE/work/ 0 0
  none /proc fuse.pwn user_id=1000"
  $ mkdir -p "$LOW" "$UP" "$WORK"
  $ sudo mount -t overlay -o "lowerdir=$LOW,upperdir=$UP,workdir=$WORK" none /mnt
  $ cat /proc/mounts
  none /root/ovl/mnt overlay rw,relatime,lowerdir=ovl/lower,upperdir=ovl/upper,workdir=ovl/work/ 0 0
  none /proc fuse.pwn user_id=1000 0 0
  $ fusermount -u /proc
  $ cat /proc/mounts
  cat: /proc/mounts: No such file or directory

This fixes the problem by adding new seq_show_option and
seq_show_option_n helpers, and updating the vulnerable show_option
handlers to use them as needed.  Some, like SELinux, need to be open
coded due to unusual existing escape mechanisms.

[akpm@linux-foundation.org: add lost chunk, per Kees]
[keescook@chromium.org: seq_show_option should be using const parameters]
Signed-off-by: Kees Cook 
Acked-by: Serge Hallyn 
Acked-by: Jan Kara 
Acked-by: Paul Moore 
Cc: J. R. Okajima 
Signed-off-by: Kees Cook 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.2:
 - Drop changes to overlayfs, reiserfs
 - Drop vers option from cifs
 - ceph changes are all in one file
 - Adjust context]
Signed-off-by: Ben Hutchings

xfs: return errors from partial I/O failures to files

2015-10-13T02:46:07+00:00

commit c9eb256eda4420c06bb10f5e8fbdbe1a34bc98e0 upstream.

There is an issue with xfs's error reporting in some cases of I/O partially
failing and partially succeeding. Calls like fsync() can report success even
though not all I/O was successful in partial-failure cases such as one disk of
a RAID0 array being offline.

The issue can occur when there are more than one bio per xfs_ioend struct.
Each call to xfs_end_bio() for a bio completing will write a value to
ioend->io_error.  If a successful bio completes after any failed bio, no
error is reported do to it writing 0 over the error code set by any failed bio.
The I/O error information is now lost and when the ioend is completed
only success is reported back up the filesystem stack.

xfs_end_bio() should only set ioend->io_error in the case of BIO_UPTODATE
being clear.  ioend->io_error is initialized to 0 at allocation so only needs
to be updated by a failed bio. Also check that ioend->io_error is 0 so that
the first error reported will be the error code returned.

Signed-off-by: David Jeffery 
Reviewed-by: Dave Chinner 
Signed-off-by: Dave Chinner 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

xfs: Fix xfs_attr_leafblock definition

2015-10-13T02:46:06+00:00

commit ffeecc5213024ae663377b442eedcfbacf6d0c5d upstream.

struct xfs_attr_leafblock contains 'entries' array which is declared
with size 1 altough it can in fact contain much more entries. Since this
array is followed by further struct members, gcc (at least in version
4.8.3) thinks that the array has the fixed size of 1 element and thus
may optimize away all accesses beyond the end of array resulting in
non-working code. This problem was only observed with userspace code in
xfsprogs, however it's better to be safe in kernel as well and have
matching kernel and xfsprogs definitions.

Signed-off-by: Jan Kara 
Reviewed-by: Dave Chinner 
Signed-off-by: Dave Chinner 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings

xfs: ensure truncate forces zeroed blocks to disk

2015-05-09T22:16:20+00:00

commit 5885ebda878b47c4b4602d4b0410cb4b282af024 upstream.

A new fsync vs power fail test in xfstests indicated that XFS can
have unreliable data consistency when doing extending truncates that
require block zeroing. The blocks beyond EOF get zeroed in memory,
but we never force those changes to disk before we run the
transaction that extends the file size and exposes those blocks to
userspace. This can result in the blocks not being correctly zeroed
after a crash.

Because in-memory behaviour is correct, tools like fsx don't pick up
any coherency problems - it's not until the filesystem is shutdown
or the system crashes after writing the truncate transaction to the
journal but before the zeroed data in the page cache is flushed that
the issue is exposed.

Fix this by also flushing the dirty data in memory region between
the old size and new size when we've found blocks that need zeroing
in the truncate process.

Reported-by: Liu Bo 
Signed-off-by: Dave Chinner 
Reviewed-by: Brian Foster 
Signed-off-by: Dave Chinner 
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings

xfs: really fix the cursor leak in xfs_alloc_ag_vextent_near

2014-08-06T17:07:40+00:00

commit e3a746f5aab71f2dd0a83116772922fb37ae29d6 upstream.

The current cursor is reallocated when retrying the allocation, so
the existing cursor needs to be destroyed in both the restart and
the failure cases.

Signed-off-by: Dave Chinner 
Tested-by: Mike Snitzer 
Signed-off-by: Ben Myers 
Signed-off-by: Ben Hutchings

xfs: fix allocbt cursor leak in xfs_alloc_ag_vextent_near

2014-08-06T17:07:40+00:00

commit 76d095388b040229ea1aad7dea45be0cfa20f589 upstream.

When we fail to find an matching extent near the requested extent
specification during a left-right distance search in
xfs_alloc_ag_vextent_near, we fail to free the original cursor that
we used to look up the XFS_BTNUM_CNT tree and hence leak it.

Reported-by: Chris J Arges 
Signed-off-by: Dave Chinner 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Ben Myers 
Signed-off-by: Ben Hutchings

xfs: Account log unmount transaction correctly

2014-02-15T19:20:10+00:00

commit 3948659e30808fbaa7673bbe89de2ae9769e20a7 upstream.

There have been a few reports of this warning appearing recently:

XFS (dm-4): xlog_space_left: head behind tail
 tail_cycle = 129, tail_bytes = 20163072
 GH   cycle = 129, GH   bytes = 20162880

The common cause appears to be lots of freeze and unfreeze cycles,
and the output from the warnings indicates that we are leaking
around 8 bytes of log space per freeze/unfreeze cycle.

When we freeze the filesystem, we write an unmount record and that
uses xlog_write directly - a special type of transaction,
effectively. What it doesn't do, however, is correctly account for
the log space it uses. The unmount record writes an 8 byte structure
with a special magic number into the log, and the space this
consumes is not accounted for in the log ticket tracking the
operation. Hence we leak 8 bytes every unmount record that is
written.

Signed-off-by: Dave Chinner 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Ben Myers 
Signed-off-by: Ben Hutchings

xfs: underflow bug in xfs_attrlist_by_handle()

2014-01-03T04:33:35+00:00

commit 31978b5cc66b8ba8a7e8eef60b12395d41b7b890 upstream.

If we allocate less than sizeof(struct attrlist) then we end up
corrupting memory or doing a ZERO_PTR_SIZE dereference.

This can only be triggered with CAP_SYS_ADMIN.

Reported-by: Nico Golde 
Reported-by: Fabian Yamaguchi 
Signed-off-by: Dan Carpenter 
Reviewed-by: Dave Chinner 
Signed-off-by: Ben Myers 

(cherry picked from commit 071c529eb672648ee8ca3f90944bcbcc730b4c06)
Signed-off-by: Ben Hutchings

xfs: kill suid/sgid through the truncate path.

2013-06-19T01:16:40+00:00

commit 2962f5a5dcc56f69cbf62121a7be67cc15d6940b upstream.

XFS has failed to kill suid/sgid bits correctly when truncating
files of non-zero size since commit c4ed4243 ("xfs: split
xfs_setattr") introduced in the 3.1 kernel. Fix it.

Fix it.

Signed-off-by: Dave Chinner 
Reviewed-by: Brian Foster 
Signed-off-by: Ben Myers 

(cherry picked from commit 56c19e89b38618390addfc743d822f99519055c6)
Signed-off-by: Ben Hutchings

xfs: Fix possible use-after-free with AIO

2013-02-06T04:33:49+00:00

commit 4b05d09c18d9aa62d2e7fb4b057f54e5a38963f5 upstream.

Running AIO is pinning inode in memory using file reference. Once AIO
is completed using aio_complete(), file reference is put and inode can
be freed from memory. So we have to be sure that calling aio_complete()
is the last thing we do with the inode.

CC: xfs@oss.sgi.com
CC: Ben Myers 
Signed-off-by: Jan Kara 
Reviewed-by: Ben Myers 
Signed-off-by: Ben Myers 
Signed-off-by: Ben Hutchings