linux-toradex.git/drivers/scsi/sg.c, branch v4.10

Fix missing sanity check in /dev/sg

2017-02-19T17:54:31+00:00

What happens is that a write to /dev/sg is given a request with non-zero
->iovec_count combined with zero ->dxfer_len.  Or with ->dxferp pointing
to an array full of empty iovecs.

Having write permission to /dev/sg shouldn't be equivalent to the
ability to trigger BUG_ON() while holding spinlocks...

Found by Dmitry Vyukov and syzkaller.

[ The BUG_ON() got changed to a WARN_ON_ONCE(), but this fixes the
  underlying issue.  - Linus ]

Signed-off-by: Al Viro 
Reported-by: Dmitry Vyukov 
Reviewed-by: Christoph Hellwig 
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds

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

2016-12-23T04:03:42+00:00

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.

Cc: stable@vger.kernel.org
Signed-off-by: Al Viro

scsi: sg: Use mult_frac, drop MULDIV macro

2016-08-31T02:18:59+00:00

The MULDIV macro is essentially a duplicate of the more standard
mult_frac macro. Replace use of MULDIV with mult_frac & drop the
duplication.

Signed-off-by: Paul Burton 
Acked-by: Douglas Gilbert 
Signed-off-by: Martin K. Petersen

scsi: sg: Avoid overflow when USER_HZ > HZ

2016-08-31T02:18:10+00:00

Calculating the maximum timeout that a user can set via the
SG_SET_TIMEOUT ioctl involves multiplying INT_MAX by USER_HZ/HZ. If
USER_HZ is larger than HZ then this results in an overflow when
performed as a 32 bit integer calculation, resulting in compiler
warnings such as the following:

  drivers/scsi/sg.c: In function 'sg_ioctl':
  drivers/scsi/sg.c:91:67: warning: integer overflow in expression [-Woverflow]
   #define MULDIV(X,MUL,DIV) ((((X % DIV) * MUL) / DIV) + ((X / DIV) * MUL))
                                                                     ^
  drivers/scsi/sg.c:887:14: note: in expansion of macro 'MULDIV'
     if (val >= MULDIV (INT_MAX, USER_HZ, HZ))
                ^
  drivers/scsi/sg.c:91:67: warning: integer overflow in expression [-Woverflow]
   #define MULDIV(X,MUL,DIV) ((((X % DIV) * MUL) / DIV) + ((X / DIV) * MUL))
                                                                     ^
  drivers/scsi/sg.c:888:13: note: in expansion of macro 'MULDIV'
         val = MULDIV (INT_MAX, USER_HZ, HZ);
               ^

Avoid this overflow by performing the (constant) arithmetic on 64 bit
integers, which ensures that overflow from multiplying the 32 bit values
cannot occur. When converting the result back to a 32 bit integer use
min_t to ensure that we don't simply truncate a value beyond INT_MAX to
a 32 bit integer, but instead use INT_MAX where the result was larger
than it. As the values are all compile time constant the 64 bit
arithmetic should have no runtime cost.

Signed-off-by: Paul Burton 
Acked-by: Douglas Gilbert 
Signed-off-by: Martin K. Petersen

sg: fix dxferp in from_to case

2016-03-10T01:41:04+00:00

One of the strange things that the original sg driver did was let the
user provide both a data-out buffer (it followed the sg_header+cdb)
_and_ specify a reply length greater than zero. What happened was that
the user data-out buffer was copied into some kernel buffers and then
the mid level was told a read type operation would take place with the
data from the device overwriting the same kernel buffers. The user would
then read those kernel buffers back into the user space.

From what I can tell, the above action was broken by commit fad7f01e61bf
("sg: set dxferp to NULL for READ with the older SG interface") in 2008
and syzkaller found that out recently.

Make sure that a user space pointer is passed through when data follows
the sg_header structure and command.  Fix the abnormal case when a
non-zero reply_len is also given.

Fixes: fad7f01e61bf737fe8a3740d803f000db57ecac6
Cc:  #v2.6.28+
Signed-off-by: Douglas Gilbert 
Reviewed-by: Ewan Milne 
Signed-off-by: Martin K. Petersen

drivers/scsi/sg.c: mark VMA as VM_IO to prevent migration

2016-02-03T16:28:43+00:00

Reduced testcase:

    #include 
    #include 
    #include 
    #include 

    #define SIZE 0x2000

    int main()
    {
        int fd;
        void *p;

        fd = open("/dev/sg0", O_RDWR);
        p = mmap(NULL, SIZE, PROT_EXEC, MAP_PRIVATE | MAP_LOCKED, fd, 0);
        mbind(p, SIZE, 0, NULL, 0, MPOL_MF_MOVE);
        return 0;
    }

We shouldn't try to migrate pages in sg VMA as we don't have a way to
update Sg_scatter_hold::pages accordingly from mm core.

Let's mark the VMA as VM_IO to indicate to mm core that the VMA is not
migratable.

Signed-off-by: Kirill A. Shutemov 
Reported-by: Dmitry Vyukov 
Acked-by: Vlastimil Babka 
Cc: Doug Gilbert 
Cc: David Rientjes 
Cc: Naoya Horiguchi 
Cc: "Kirill A. Shutemov" 
Cc: Shiraz Hashim 
Cc: Hugh Dickins 
Cc: Sasha Levin 
Cc: syzkaller 
Cc: Kostya Serebryany 
Cc: Alexander Potapenko 
Cc: James Bottomley 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

sg: Fix double-free when drives detach during SG_IO

2015-11-03T04:51:25+00:00

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

sg_start_req(): use import_iovec()

2015-04-12T02:27:14+00:00

Signed-off-by: Al Viro

sg_start_req(): make sure that there's not too many elements in iovec

2015-04-12T02:27:13+00:00

unfortunately, allowing an arbitrary 16bit value means a possibility of
overflow in the calculation of total number of pages in bio_map_user_iov() -
we rely on there being no more than PAGE_SIZE members of sum in the
first loop there.  If that sum wraps around, we end up allocating
too small array of pointers to pages and it's easy to overflow it in
the second loop.

X-Coverup: TINC (and there's no lumber cartel either)
Cc: stable@vger.kernel.org # way, way back
Signed-off-by: Al Viro

Merge branch 'iocb' into for-next

2015-04-12T02:24:41+00:00