linux-stable.git/drivers/scsi, branch linux-3.10.y

scsi: scsi_dh_emc: return success in clariion_std_inquiry()

2017-11-02T09:46:03+00:00

commit 4d7d39a18b8b81511f0b893b7d2203790bf8a58b upstream.

We accidentally return an uninitialized variable on success.

Fixes: b6ff1b14cdf4 ("[SCSI] scsi_dh: Update EMC handler")
Signed-off-by: Dan Carpenter 
Reviewed-by: Hannes Reinecke 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Willy Tarreau

scsi: qla2xxx: Fix an integer overflow in sysfs code

2017-11-02T09:46:01+00:00

commit e6f77540c067b48dee10f1e33678415bfcc89017 upstream.

The value of "size" comes from the user.  When we add "start + size" it
could lead to an integer overflow bug.

It means we vmalloc() a lot more memory than we had intended.  I believe
that on 64 bit systems vmalloc() can succeed even if we ask it to
allocate huge 4GB buffers.  So we would get memory corruption and likely
a crash when we call ha->isp_ops->write_optrom() and ->read_optrom().

Only root can trigger this bug.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=194061

Cc: 
Fixes: b7cc176c9eb3 ("[SCSI] qla2xxx: Allow region-based flash-part accesses.")
Reported-by: shqking 
Signed-off-by: Dan Carpenter 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Willy Tarreau

scsi: qla2xxx: don't disable a not previously enabled PCI device

2017-11-02T06:16:26+00:00

commit ddff7ed45edce4a4c92949d3c61cd25d229c4a14 upstream.

When pci_enable_device() or pci_enable_device_mem() fail in
qla2x00_probe_one() we bail out but do a call to
pci_disable_device(). This causes the dev_WARN_ON() in
pci_disable_device() to trigger, as the device wasn't enabled
previously.

So instead of taking the 'probe_out' error path we can directly return
*iff* one of the pci_enable_device() calls fails.

Additionally rename the 'probe_out' goto label's name to the more
descriptive 'disable_device'.

Signed-off-by: Johannes Thumshirn 
Fixes: e315cd28b9ef ("[SCSI] qla2xxx: Code changes for qla data structure refactoring")
Cc: 
Reviewed-by: Bart Van Assche 
Reviewed-by: Giridhar Malavali 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Willy Tarreau

mvsas: fix misleading indentation

2017-06-20T12:04:29+00:00

commit 7789cd39274c51bf475411fe22a8ee7255082809 upstream.

Fix a smatch warning:
drivers/scsi/mvsas/mv_sas.c:740 mvs_task_prep() warn: curly braces intended?

The code is correct, the indention is misleading. When the device is not
ready we want to return SAS_PHY_DOWN. But current indentation makes it
look like we only do so in the else branch of if (mvi_dev).

Signed-off-by: Luis de Bethencourt 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Willy Tarreau

sd: get disk reference in sd_check_events()

2017-06-20T12:04:23+00:00

commit eb72d0bb84eee5d0dc3044fd17b75e7101dabb57 upstream.

sd_check_events() is called asynchronously, and might race
with device removal. So always take a disk reference when
processing the event to avoid the device being removed while
the event is processed.

Signed-off-by: Hannes Reinecke 
Reviewed-by: Ewan D. Milne 
Reviewed-by: Bart Van Assche 
Signed-off-by: Martin K. Petersen 
Cc: Jinpu Wang 
Signed-off-by: Jiri Slaby 
Signed-off-by: Willy Tarreau

sg: Fix double-free when drives detach during SG_IO

2017-06-20T12:04:14+00:00

commit f3951a3709ff50990bf3e188c27d346792103432 upstream.

In sg_common_write(), we free the block request and return -ENODEV if
the device is detached in the middle of the SG_IO ioctl().

Unfortunately, sg_finish_rem_req() also tries to free srp->rq, so we
end up freeing rq->cmd in the already free rq object, and then free
the object itself out from under the current user.

This ends up corrupting random memory via the list_head on the rq
object. The most common crash trace I saw is this:

  ------------[ cut here ]------------
  kernel BUG at block/blk-core.c:1420!
  Call Trace:
  [] blk_put_request+0x5b/0x80
  [] sg_finish_rem_req+0x6b/0x120 [sg]
  [] sg_common_write.isra.14+0x459/0x5a0 [sg]
  [] ? selinux_file_alloc_security+0x48/0x70
  [] sg_new_write.isra.17+0x195/0x2d0 [sg]
  [] sg_ioctl+0x644/0xdb0 [sg]
  [] do_vfs_ioctl+0x90/0x520
  [] ? file_has_perm+0x97/0xb0
  [] SyS_ioctl+0x91/0xb0
  [] tracesys+0xdd/0xe2
    RIP [] __blk_put_request+0x154/0x1a0

The solution is straightforward: just set srp->rq to NULL in the
failure branch so that sg_finish_rem_req() doesn't attempt to re-free
it.

Additionally, since sg_rq_end_io() will never be called on the object
when this happens, we need to free memory backing ->cmd if it isn't
embedded in the object itself.

KASAN was extremely helpful in finding the root cause of this bug.

Signed-off-by: Calvin Owens 
Acked-by: Douglas Gilbert 
Signed-off-by: Martin K. Petersen 
Acked-by: Johannes Thumshirn 
Signed-off-by: Jiri Slaby 
Signed-off-by: Willy Tarreau

qla2xxx: Fix crash due to null pointer access

2017-06-20T12:04:08+00:00

commit fc1ffd6cb38a1c1af625b9833c41928039e733f5 upstream.

During code inspection, while investigating following stack trace
seen on one of the test setup, we found out there was possibility
of memory leak becuase driver was not unwinding the stack properly.

This issue has not been reproduced in a test environment or on a
customer setup.

Here's stack trace that was seen.

[1469877.797315] Call Trace:
[1469877.799940]  [] qla2x00_mem_alloc+0xb09/0x10c0 [qla2xxx]
[1469877.806980]  [] qla2x00_probe_one+0x86a/0x1b50 [qla2xxx]
[1469877.814013]  [] ? __pm_runtime_resume+0x51/0xa0
[1469877.820265]  [] ? _raw_spin_lock_irqsave+0x25/0x90
[1469877.826776]  [] ? _raw_spin_unlock_irqrestore+0x6d/0x80
[1469877.833720]  [] ? preempt_count_sub+0xb1/0x100
[1469877.839885]  [] ? _raw_spin_unlock_irqrestore+0x4c/0x80
[1469877.846830]  [] local_pci_probe+0x4c/0xb0
[1469877.852562]  [] ? preempt_count_sub+0xb1/0x100
[1469877.858727]  [] pci_call_probe+0x89/0xb0

Signed-off-by: Quinn Tran 
Signed-off-by: Himanshu Madhani 
Reviewed-by: Christoph Hellwig 
[ bvanassche: Fixed spelling in patch description ]
Signed-off-by: Bart Van Assche 
Signed-off-by: Willy Tarreau

sg_write()/bsg_write() is not fit to be called under KERNEL_DS

2017-06-20T12:03:25+00:00

commit 128394eff343fc6d2f32172f03e24829539c5835 upstream.

Both damn things interpret userland pointers embedded into the payload;
worse, they are actually traversing those.  Leaving aside the bad
API design, this is very much _not_ safe to call with KERNEL_DS.
Bail out early if that happens.

Signed-off-by: Al Viro 
Signed-off-by: Willy Tarreau

scsi: sd: Fix capacity calculation with 32-bit sector_t

2017-06-20T12:03:23+00:00

commit 7c856152cb92f8eee2df29ef325a1b1f43161aff upstream.

We previously made sure that the reported disk capacity was less than
0xffffffff blocks when the kernel was not compiled with large sector_t
support (CONFIG_LBDAF). However, this check assumed that the capacity
was reported in units of 512 bytes.

Add a sanity check function to ensure that we only enable disks if the
entire reported capacity can be expressed in terms of sector_t.

Reported-by: Steve Magnani 
Cc: Bart Van Assche 
Reviewed-by: Bart Van Assche 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Willy Tarreau

scsi: sr: Sanity check returned mode data

2017-06-20T12:03:23+00:00

commit a00a7862513089f17209b732f230922f1942e0b9 upstream.

Kefeng Wang discovered that old versions of the QEMU CD driver would
return mangled mode data causing us to walk off the end of the buffer in
an attempt to parse it. Sanity check the returned mode sense data.

Reported-by: Kefeng Wang 
Tested-by: Kefeng Wang 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Willy Tarreau