linux-stable.git/drivers/block, branch v4.9.76

nbd: fix use-after-free of rq/bio in the xmit path

2018-01-10T08:29:52+00:00

commit 429a787be6793554ee02aacc7e1f11ebcecc4453 upstream.

For writes, we can get a completion in while we're still iterating
the request and bio chain. If that happens, we're reading freed
memory and we can crash.

Break out after the last segment and avoid having the iterator
read freed memory.

Reviewed-by: Josef Bacik 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

nbd: set queue timeout properly

2017-12-25T13:23:41+00:00

[ Upstream commit f8586855031a1d6b243f013c3082631346fddfad ]

We can't just set the timeout on the tagset, we have to set it on the
queue as it would have been setup already at this point.

Signed-off-by: Josef Bacik 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

zram: set physical queue limits to avoid array out of bounds accesses

2017-12-14T08:28:21+00:00

[ Upstream commit 0bc315381fe9ed9fb91db8b0e82171b645ac008f ]

zram can handle at most SECTORS_PER_PAGE sectors in a bio's bvec. When using
the NVMe over Fabrics loopback target which potentially sends a huge bulk of
pages attached to the bio's bvec this results in a kernel panic because of
array out of bounds accesses in zram_decompress_page().

Signed-off-by: Johannes Thumshirn 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Sergey Senozhatsky 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

rbd: use GFP_NOIO for parent stat and data requests

2017-11-15T14:53:20+00:00

commit 1e37f2f84680fa7f8394fd444b6928e334495ccc upstream.

rbd_img_obj_exists_submit() and rbd_img_obj_parent_read_full() are on
the writeback path for cloned images -- we attempt a stat on the parent
object to see if it exists and potentially read it in to call copyup.
GFP_NOIO should be used instead of GFP_KERNEL here.

Link: http://tracker.ceph.com/issues/22014
Signed-off-by: Ilya Dryomov 
Reviewed-by: David Disseldorp 
Signed-off-by: Greg Kroah-Hartman

skd: Submit requests to firmware before triggering the doorbell

2017-09-27T12:39:21+00:00

commit 5fbd545cd3fd311ea1d6e8be4cedddd0ee5684c7 upstream.

Ensure that the members of struct skd_msg_buf have been transferred
to the PCIe adapter before the doorbell is triggered. This patch
avoids that I/O fails sporadically and that the following error
message is reported:

(skd0:STM000196603:[0000:00:09.0]): Completion mismatch comp_id=0x0000 skreq=0x0400 new=0x0000

Signed-off-by: Bart Van Assche 
Cc: Christoph Hellwig 
Cc: Hannes Reinecke 
Cc: Johannes Thumshirn 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

skd: Avoid that module unloading triggers a use-after-free

2017-09-27T12:39:21+00:00

commit 7277cc67b3916eed47558c64f9c9c0de00a35cda upstream.

Since put_disk() triggers a disk_release() call and since that
last function calls blk_put_queue() if disk->queue != NULL, clear
the disk->queue pointer before calling put_disk(). This avoids
that unloading the skd kernel module triggers the following
use-after-free:

WARNING: CPU: 8 PID: 297 at lib/refcount.c:128 refcount_sub_and_test+0x70/0x80
refcount_t: underflow; use-after-free.
CPU: 8 PID: 297 Comm: kworker/8:1 Not tainted 4.11.10-300.fc26.x86_64 #1
Workqueue: events work_for_cpu_fn
Call Trace:
 dump_stack+0x63/0x84
 __warn+0xcb/0xf0
 warn_slowpath_fmt+0x5a/0x80
 refcount_sub_and_test+0x70/0x80
 refcount_dec_and_test+0x11/0x20
 kobject_put+0x1f/0x50
 blk_put_queue+0x15/0x20
 disk_release+0xae/0xf0
 device_release+0x32/0x90
 kobject_release+0x67/0x170
 kobject_put+0x2b/0x50
 put_disk+0x17/0x20
 skd_destruct+0x5c/0x890 [skd]
 skd_pci_probe+0x124d/0x13a0 [skd]
 local_pci_probe+0x42/0xa0
 work_for_cpu_fn+0x14/0x20
 process_one_work+0x19e/0x470
 worker_thread+0x1dc/0x4a0
 kthread+0x125/0x140
 ret_from_fork+0x25/0x30

Signed-off-by: Bart Van Assche 
Cc: Christoph Hellwig 
Cc: Hannes Reinecke 
Cc: Johannes Thumshirn 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

xen-blkfront: use a right index when checking requests

2017-08-25T00:12:20+00:00

commit b15bd8cb37598afb2963f7eb9e2de468d2d60a2f upstream.

Since commit d05d7f40791c ("Merge branch 'for-4.8/core' of
git://git.kernel.dk/linux-block") and 3fc9d690936f ("Merge branch
'for-4.8/drivers' of git://git.kernel.dk/linux-block"), blkfront_resume()
has been using an index for iterating ring_info to check request when
iterating blk_shadow in an inner loop. This seems to have been
accidentally introduced during the massive rewrite of the block layer
macros in the commits.

This may cause crash like this:

[11798.057074] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048
[11798.058832] IP: [] blkfront_resume+0x10a/0x610
....
[11798.061063] Call Trace:
[11798.061063]  [] xenbus_dev_resume+0x53/0x140
[11798.061063]  [] ? xenbus_dev_probe+0x150/0x150
[11798.061063]  [] dpm_run_callback+0x3e/0x110
[11798.061063]  [] device_resume+0x88/0x190
[11798.061063]  [] dpm_resume+0x100/0x2d0
[11798.061063]  [] dpm_resume_end+0x11/0x20
[11798.061063]  [] do_suspend+0xe8/0x1a0
[11798.061063]  [] shutdown_handler+0xfd/0x130
[11798.061063]  [] ? split+0x110/0x110
[11798.061063]  [] xenwatch_thread+0x86/0x120
[11798.061063]  [] ? prepare_to_wait_event+0x110/0x110
[11798.061063]  [] kthread+0xd7/0xf0
[11798.061063]  [] ? kfree+0x121/0x170
[11798.061063]  [] ? kthread_park+0x60/0x60
[11798.061063]  [] ?  call_usermodehelper_exec_work+0xb0/0xb0
[11798.061063]  [] ?  call_usermodehelper_exec_async+0x13a/0x140
[11798.061063]  [] ret_from_fork+0x25/0x30

Use the right index in the inner loop.

Fixes: d05d7f40791c ("Merge branch 'for-4.8/core' of git://git.kernel.dk/linux-block")
Fixes: 3fc9d690936f ("Merge branch 'for-4.8/drivers' of git://git.kernel.dk/linux-block")
Signed-off-by: Munehisa Kamata 
Reviewed-by: Thomas Friebel 
Reviewed-by: Eduardo Valentin 
Reviewed-by: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Konrad Rzeszutek Wilk 
Reviewed-by: Roger Pau Monne 
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

virtio_blk: fix panic in initialization error path

2017-08-11T15:49:36+00:00

[ Upstream commit 6bf6b0aa3da84a3d9126919a94c49c0fb7ee2fb3 ]

If blk_mq_init_queue() returns an error, it gets assigned to
vblk->disk->queue. Then, when we call put_disk(), we end up calling
blk_put_queue() with the ERR_PTR, causing a bad dereference. Fix it by
only assigning to vblk->disk->queue on success.

Signed-off-by: Omar Sandoval 
Reviewed-by: Jeff Moyer 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

nbd: blk_mq_init_queue returns an error code on failure, not NULL

2017-08-11T15:49:36+00:00

[ Upstream commit 25b4acfc7de0fc4da3bfea3a316f7282c6fbde81 ]

Additionally, don't assign directly to disk->queue, otherwise
blk_put_queue (called via put_disk) will choke (panic) on the errno
stored there.

Bug found by code inspection after Omar found a similar issue in
virtio_blk.  Compile-tested only.

Signed-off-by: Jeff Moyer 
Reviewed-by: Omar Sandoval 
Reviewed-by: Josef Bacik 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

xen/blkback: don't free be structure too early

2017-07-05T12:40:20+00:00

commit 71df1d7ccad1c36f7321d6b3b48f2ea42681c363 upstream.

The be structure must not be freed when freeing the blkif structure
isn't done. Otherwise a use-after-free of be when unmapping the ring
used for communicating with the frontend will occur in case of a
late call of xenblk_disconnect() (e.g. due to an I/O still active
when trying to disconnect).

Signed-off-by: Juergen Gross 
Tested-by: Steven Haigh 
Acked-by: Roger Pau Monné 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman