linux-stable.git/drivers/md, branch v3.16.65

dm ioctl: harden copy_params()'s copy_from_user() from malicious users

2019-02-11T17:53:38+00:00

commit 800a7340ab7dd667edf95e74d8e4f23a17e87076 upstream.

In copy_params(), the struct 'dm_ioctl' is first copied from the user
space buffer 'user' to 'param_kernel' and the field 'data_size' is
checked against 'minimum_data_size' (size of 'struct dm_ioctl' payload
up to its 'data' member).  If the check fails, an error code EINVAL will be
returned.  Otherwise, param_kernel->data_size is used to do a second copy,
which copies from the same user-space buffer to 'dmi'.  After the second
copy, only 'dmi->data_size' is checked against 'param_kernel->data_size'.
Given that the buffer 'user' resides in the user space, a malicious
user-space process can race to change the content in the buffer between
the two copies.  This way, the attacker can inject inconsistent data
into 'dmi' (versus previously validated 'param_kernel').

Fix redundant copying of 'minimum_data_size' from user-space buffer by
using the first copy stored in 'param_kernel'.  Also remove the
'data_size' check after the second copy because it is now unnecessary.

Signed-off-by: Wenwen Wang 
Signed-off-by: Mike Snitzer 
Signed-off-by: Ben Hutchings

bcache: fix miss key refill->end in writeback

2019-02-11T17:53:29+00:00

commit 2d6cb6edd2c7fb4f40998895bda45006281b1ac5 upstream.

refill->end record the last key of writeback, for example, at the first
time, keys (1,128K) to (1,1024K) are flush to the backend device, but
the end key (1,1024K) is not included, since the bellow code:
	if (bkey_cmp(k, refill->end) >= 0) {
		ret = MAP_DONE;
		goto out;
	}
And in the next time when we refill writeback keybuf again, we searched
key start from (1,1024K), and got a key bigger than it, so the key
(1,1024K) missed.
This patch modify the above code, and let the end key to be included to
the writeback key buffer.

Signed-off-by: Tang Junhui 
Signed-off-by: Coly Li 
Signed-off-by: Jens Axboe 
Signed-off-by: Ben Hutchings

bcache: fix wrong cache_misses statistics

2019-02-11T17:53:29+00:00

commit c157313791a999646901b3e3c6888514ebc36d62 upstream.

Currently, Cache missed IOs are identified by s->cache_miss, but actually,
there are many situations that missed IOs are not assigned a value for
s->cache_miss in cached_dev_cache_miss(), for example, a bypassed IO
(s->iop.bypass = 1), or the cache_bio allocate failed. In these situations,
it will go to out_put or out_submit, and s->cache_miss is null, which leads
bch_mark_cache_accounting() to treat this IO as a hit IO.

[ML: applied by 3-way merge]

Signed-off-by: tang.junhui 
Reviewed-by: Michael Lyle 
Reviewed-by: Coly Li 
Signed-off-by: Jens Axboe 
Signed-off-by: Ben Hutchings

dm cache: destroy migration_cache if cache target registration failed

2018-12-16T22:09:39+00:00

commit c7cd55504a5b0fc826a2cd9540845979d24ae542 upstream.

Commit 7e6358d244e47 ("dm: fix various targets to dm_register_target
after module __init resources created") inadvertently introduced this
bug when it moved dm_register_target() after the call to KMEM_CACHE().

Fixes: 7e6358d244e47 ("dm: fix various targets to dm_register_target after module __init resources created")
Signed-off-by: Shenghui Wang 
Signed-off-by: Mike Snitzer 
Signed-off-by: Ben Hutchings

bcache: add separate workqueue for journal_write to avoid deadlock

2018-12-16T22:09:27+00:00

commit 0f843e65d9eef4936929bb036c5f771fb261eea4 upstream.

After write SSD completed, bcache schedules journal_write work to
system_wq, which is a public workqueue in system, without WQ_MEM_RECLAIM
flag. system_wq is also a bound wq, and there may be no idle kworker on
current processor. Creating a new kworker may unfortunately need to
reclaim memory first, by shrinking cache and slab used by vfs, which
depends on bcache device. That's a deadlock.

This patch create a new workqueue for journal_write with WQ_MEM_RECLAIM
flag. It's rescuer thread will work to avoid the deadlock.

Signed-off-by: Guoju Fang 
Signed-off-by: Coly Li 
Signed-off-by: Jens Axboe 
Signed-off-by: Ben Hutchings

bcache: do not assign in if condition in bcache_init()

2018-12-16T22:09:27+00:00

commit 16c1fdf4cfd6c0091e59b93ec2cb7e99973f8244 upstream.

Fixes an error condition reported by checkpatch.pl which is caused by
assigning a variable in an if condition.

Signed-off-by: Florian Schmaus 
Signed-off-by: Coly Li 
Signed-off-by: Jens Axboe 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

bcache: explicitly destroy mutex while exiting

2018-12-16T22:09:27+00:00

commit 330a4db89d39a6b43f36da16824eaa7a7509d34d upstream.

mutex_destroy does nothing most of time, but it's better to call
it to make the code future proof and it also has some meaning
for like mutex debug.

As Coly pointed out in a previous review, bcache_exit() may not be
able to handle all the references properly if userspace registers
cache and backing devices right before bch_debug_init runs and
bch_debug_init failes later. So not exposing userspace interface
until everything is ready to avoid that issue.

Signed-off-by: Liang Chen 
Reviewed-by: Michael Lyle 
Reviewed-by: Coly Li 
Reviewed-by: Eric Wheeler 
Signed-off-by: Jens Axboe 
Signed-off-by: Ben Hutchings

bcache: Remove deprecated create_workqueue

2018-12-16T22:09:26+00:00

commit 81baf90af2dcc8259e99e2f236024524b55313fc upstream.

alloc_workqueue replaces deprecated create_workqueue().

Dedicated workqueues have been used since bcache_wq and moving_gc_wq
are workqueues for writes and are being used on a memory reclaim path.
WQ_MEM_RECLAIM has been set to ensure forward progress under memory
pressure.
Since there are only a fixed number of work items, explicit concurrency
limit is unnecessary here.

Signed-off-by: Bhaktipriya Shridhar 
Acked-by: Tejun Heo 
Signed-off-by: Jens Axboe 
Signed-off-by: Ben Hutchings

bcache: don't embed 'return' statements in closure macros

2018-12-16T22:09:26+00:00

commit 77b5a08427e87514c33730afc18cd02c9475e2c3 upstream.

This is horribly confusing, it breaks the flow of the code without
it being apparent in the caller.

Signed-off-by: Jens Axboe 
Acked-by: Christoph Hellwig 
Signed-off-by: Ben Hutchings

dm: disable CRYPTO_TFM_REQ_MAY_SLEEP to fix a GFP_KERNEL recursion deadlock

2018-12-16T22:09:12+00:00

commit 432061b3da64e488be3403124a72a9250bbe96d4 upstream.

There's a XFS on dm-crypt deadlock, recursing back to itself due to the
crypto subsystems use of GFP_KERNEL, reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=200835

* dm-crypt calls crypt_convert in xts mode
* init_crypt from xts.c calls kmalloc(GFP_KERNEL)
* kmalloc(GFP_KERNEL) recurses into the XFS filesystem, the filesystem
	tries to submit some bios and wait for them, causing a deadlock

Fix this by updating both the DM crypt and integrity targets to no
longer use the CRYPTO_TFM_REQ_MAY_SLEEP flag, which will change the
crypto allocations from GFP_KERNEL to GFP_ATOMIC, therefore they can't
recurse into a filesystem.  A GFP_ATOMIC allocation can fail, but
init_crypt() in xts.c handles the allocation failure gracefully - it
will fall back to preallocated buffer if the allocation fails.

The crypto API maintainer says that the crypto API only needs to
allocate memory when dealing with unaligned buffers and therefore
turning CRYPTO_TFM_REQ_MAY_SLEEP off is safe (see this discussion:
https://www.redhat.com/archives/dm-devel/2018-August/msg00195.html )

Signed-off-by: Mikulas Patocka 
Signed-off-by: Mike Snitzer 
[bwh: Backported to 3.16:
 - Drop change to crypt_alloc_req_aead() in dm-crypt
 - Drop changes to dm-integrity
 - Adjust context]
Signed-off-by: Ben Hutchings