linux.git/fs/ioctl.c, branch v5.8

fs: remove the access_ok() check in ioctl_fiemap

2020-06-04T03:16:55+00:00

access_ok just checks we are fed a proper user pointer.  We also do that
in copy_to_user itself, so no need to do this early.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Ritesh Harjani 
Reviewed-by: Darrick J. Wong 
Link: https://lore.kernel.org/r/20200523073016.2944131-9-hch@lst.de
Signed-off-by: Theodore Ts'o

fs: handle FIEMAP_FLAG_SYNC in fiemap_prep

2020-06-04T03:16:55+00:00

By moving FIEMAP_FLAG_SYNC handling to fiemap_prep we ensure it is
handled once instead of duplicated, but can still be done under fs locks,
like xfs/iomap intended with its duplicate handling.  Also make sure the
error value of filemap_write_and_wait is propagated to user space.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Amir Goldstein 
Reviewed-by: Darrick J. Wong 
Link: https://lore.kernel.org/r/20200523073016.2944131-8-hch@lst.de
Signed-off-by: Theodore Ts'o

fs: move fiemap range validation into the file systems instances

2020-06-04T03:16:55+00:00

Replace fiemap_check_flags with a fiemap_prep helper that also takes the
inode and mapped range, and performs the sanity check and truncation
previously done in fiemap_check_range.  This way the validation is inside
the file system itself and thus properly works for the stacked overlayfs
case as well.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Amir Goldstein 
Reviewed-by: Darrick J. Wong 
Link: https://lore.kernel.org/r/20200523073016.2944131-7-hch@lst.de
Signed-off-by: Theodore Ts'o

fs: move the fiemap definitions out of fs.h

2020-06-04T03:16:55+00:00

No need to pull the fiemap definitions into almost every file in the
kernel build.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Ritesh Harjani 
Reviewed-by: Darrick J. Wong 
Link: https://lore.kernel.org/r/20200523073016.2944131-5-hch@lst.de
Signed-off-by: Theodore Ts'o

fs: mark __generic_block_fiemap static

2020-06-04T03:16:54+00:00

There is no caller left outside of ioctl.c.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Ritesh Harjani 
Reviewed-by: Jan Kara 
Reviewed-by: Darrick J. Wong 
Link: https://lore.kernel.org/r/20200523073016.2944131-4-hch@lst.de
Signed-off-by: Theodore Ts'o

fibmap: Warn and return an error in case of block > INT_MAX

2020-04-30T14:57:46+00:00

We better warn the fibmap user and not return a truncated and therefore
an incorrect block map address if the bmap() returned block address
is greater than INT_MAX (since user supplied integer pointer).

It's better to pr_warn() all user of ioctl_fibmap() and return a proper
error code rather than silently letting a FS corruption happen if the
user tries to fiddle around with the returned block map address.

We fix this by returning an error code of -ERANGE and returning 0 as the
block mapping address in case if it is > INT_MAX.

Now iomap_bmap() could be called from either of these two paths.
Either when a user is calling an ioctl_fibmap() interface to get
the block mapping address or by some filesystem via use of bmap()
internal kernel API.
bmap() kernel API is well equipped with handling of u64 addresses.

WARN condition in iomap_bmap_actor() was mainly added to warn all
the fibmap users. But now that we have directly added this warning
for all fibmap users and also made sure to return 0 as block map address
in case if addr > INT_MAX.
So we can now remove this logic from iomap_bmap_actor().

Signed-off-by: Ritesh Harjani 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Jan Kara 
Reviewed-by: Darrick J. Wong 
Signed-off-by: Darrick J. Wong

Merge tag 'compat-ioctl-fix' of git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground

2020-02-08T21:44:41+00:00

Pull compat-ioctl fix from Arnd Bergmann:
 "One patch in the compat-ioctl series broke 32-bit rootfs for multiple
  people testing on 64-bit kernels. Let's fix it in -rc1 before others
  run into the same issue"

* tag 'compat-ioctl-fix' of git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground:
  compat_ioctl: fix FIONREAD on devices

Merge branch 'work.misc' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs

2020-02-08T21:04:49+00:00

Pull misc vfs updates from Al Viro:

 - bmap series from cmaiolino

 - getting rid of convolutions in copy_mount_options() (use a couple of
   copy_from_user() instead of the __get_user() crap)

* 'work.misc' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  saner copy_mount_options()
  fibmap: Reject negative block numbers
  fibmap: Use bmap instead of ->bmap method in ioctl_fibmap
  ecryptfs: drop direct calls to ->bmap
  cachefiles: drop direct usage of ->bmap method.
  fs: Enable bmap() function to properly return errors

compat_ioctl: fix FIONREAD on devices

2020-02-08T17:02:54+00:00

My final cleanup patch for sys_compat_ioctl() introduced a regression on
the FIONREAD ioctl command, which is used for both regular and special
files, but only works on regular files after my patch, as I had missed
the warning that Al Viro put into a comment right above it.

Change it back so it can work on any file again by moving the implementation
to do_vfs_ioctl() instead.

Fixes: 77b9040195de ("compat_ioctl: simplify the implementation")
Reported-and-tested-by: Christian Zigotzky 
Reported-and-tested-by: youling257 
Signed-off-by: Arnd Bergmann

fibmap: Reject negative block numbers

2020-02-03T13:05:58+00:00

FIBMAP receives an integer from userspace which is then implicitly converted
into sector_t to be passed to bmap(). No check is made to ensure userspace
didn't send a negative block number, which can end up in an underflow, and
returning to userspace a corrupted block address.

As a side-effect, the underflow caused by a negative block here, will
trigger the WARN() in iomap_bmap_actor(), which is how this issue was
first discovered.

Reviewed-by: Christoph Hellwig 
Signed-off-by: Carlos Maiolino 
Signed-off-by: Al Viro