linux-stable.git/drivers/staging, branch v4.4.69

staging: comedi: jr3_pci: cope with jiffies wraparound

2017-05-20T12:26:59+00:00

commit 8ec04a491825e08068e92bed0bba7821893b6433 upstream.

The timer expiry routine `jr3_pci_poll_dev()` checks for expiry by
checking whether the absolute value of `jiffies` (stored in local
variable `now`) is greater than the expected expiry time in jiffy units.
This will fail when `jiffies` wraps around.  Also, it seems to make
sense to handle the expiry one jiffy earlier than the current test.  Use
`time_after_eq()` to check for expiry.

Signed-off-by: Ian Abbott 
Signed-off-by: Greg Kroah-Hartman

staging: comedi: jr3_pci: fix possible null pointer dereference

2017-05-20T12:26:59+00:00

commit 45292be0b3db0b7f8286683b376e2d9f949d11f9 upstream.

For some reason, the driver does not consider allocation of the
subdevice private data to be a fatal error when attaching the COMEDI
device.  It tests the subdevice private data pointer for validity at
certain points, but omits some crucial tests.  In particular,
`jr3_pci_auto_attach()` calls `jr3_pci_alloc_spriv()` to allocate and
initialize the subdevice private data, but the same function
subsequently dereferences the pointer to access the `next_time_min` and
`next_time_max` members without checking it first.  The other missing
test is in the timer expiry routine `jr3_pci_poll_dev()`, but it will
crash before it gets that far.

Fix the bug by returning `-ENOMEM` from `jr3_pci_auto_attach()` as soon
as one of the calls to `jr3_pci_alloc_spriv()` returns `NULL`.  The
COMEDI core will subsequently call `jr3_pci_detach()` to clean up.

Signed-off-by: Ian Abbott 
Signed-off-by: Greg Kroah-Hartman

staging: gdm724x: gdm_mux: fix use-after-free on module unload

2017-05-20T12:26:59+00:00

commit b58f45c8fc301fe83ee28cad3e64686c19e78f1c upstream.

Make sure to deregister the USB driver before releasing the tty driver
to avoid use-after-free in the USB disconnect callback where the tty
devices are deregistered.

Fixes: 61e121047645 ("staging: gdm7240: adding LTE USB driver")
Cc: Won Kang 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

staging: vt6656: use off stack for out buffer USB transfers.

2017-05-20T12:26:59+00:00

commit 12ecd24ef93277e4e5feaf27b0b18f2d3828bc5e upstream.

Since 4.9 mandated USB buffers be heap allocated this causes the driver
to fail.

Since there is a wide range of buffer sizes use kmemdup to create
allocated buffer.

Signed-off-by: Malcolm Priestley 
Signed-off-by: Greg Kroah-Hartman

staging: vt6656: use off stack for in buffer USB transfers.

2017-05-20T12:26:58+00:00

commit 05c0cf88bec588a7cb34de569acd871ceef26760 upstream.

Since 4.9 mandated USB buffers to be heap allocated. This causes
the driver to fail.

Create buffer for USB transfers.

Signed-off-by: Malcolm Priestley 
Signed-off-by: Greg Kroah-Hartman

staging: emxx_udc: remove incorrect __init annotations

2017-05-14T11:32:58+00:00

commit 4f3445067d5f78fb8d1970b02610f85c2f377ea4 upstream.

The probe function is not marked __init, but some other functions
are. This leads to a warning on older compilers (e.g. gcc-4.3),
and can cause executing freed memory when built with those
compilers:

WARNING: drivers/staging/emxx_udc/emxx_udc.o(.text+0x2d78): Section mismatch in reference from the function nbu2ss_drv_probe() to the function .init.text:nbu2ss_drv_contest_init()

This removes the annotations.

Fixes: 33aa8d45a4fe ("staging: emxx_udc: Add Emma Mobile USB Gadget driver")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

staging: wlan-ng: add missing byte order conversion

2017-05-14T11:32:57+00:00

commit 2c474b8579e9b67ff72b2bcefce9f53c7f4469d4 upstream.

Conversion macros le16_to_cpu was removed and that caused new sparse warning

sparse output:
drivers/staging/wlan-ng/p80211netdev.c:241:44: warning: incorrect type in argument 2 (different base types)
drivers/staging/wlan-ng/p80211netdev.c:241:44:    expected unsigned short [unsigned] [usertype] fc
drivers/staging/wlan-ng/p80211netdev.c:241:44:    got restricted __le16 [usertype] fc

Fixes: 7ad82572348c ("staging:wlan-ng:Fix sparse warning")
Signed-off-by: Igor Pylypiv 
Signed-off-by: Greg Kroah-Hartman

IB/ehca: fix maybe-uninitialized warnings

2017-05-08T05:46:02+00:00

The driver causes two warnings about possibly uninitialized variables:

drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf':
drivers/infiniband/hw/ehca/ehca_mrmw.c:1908:4: warning: 'prev_pgaddr' may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/infiniband/hw/ehca/ehca_mrmw.c:1924:14: note: 'prev_pgaddr' was declared here
drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_reg_mr':
drivers/infiniband/hw/ehca/ehca_mrmw.c:2430:5: warning: 'hret' may be used uninitialized in this function [-Wmaybe-uninitialized]

The first one is definitely a false positive, the second one may or may not
be one. In both cases, adding an intialization is the safe and easy
workaround.

The driver was removed in mainline in commit e581d111dad3
("staging/rdma: remove deprecated ehca driver"), in linux-4.6.
In 4.4, the file is located in drivers/staging/rdma/ehca/ehca_mrmw.c,
and the fix still applies.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

staging/android/ion : fix a race condition in the ion driver

2017-04-30T03:49:29+00:00

commit 9590232bb4f4cc824f3425a6e1349afbe6d6d2b7 upstream.

There is a use-after-free problem in the ion driver.
This is caused by a race condition in the ion_ioctl()
function.

A handle has ref count of 1 and two tasks on different
cpus calls ION_IOC_FREE simultaneously.

cpu 0                                   cpu 1
-------------------------------------------------------
ion_handle_get_by_id()
(ref == 2)
                            ion_handle_get_by_id()
                            (ref == 3)

ion_free()
(ref == 2)

ion_handle_put()
(ref == 1)

                            ion_free()
                            (ref == 0 so ion_handle_destroy() is
                            called
                            and the handle is freed.)

                            ion_handle_put() is called and it
                            decreases the slub's next free pointer

The problem is detected as an unaligned access in the
spin lock functions since it uses load exclusive
 instruction. In some cases it corrupts the slub's
free pointer which causes a mis-aligned access to the
next free pointer.(kmalloc returns a pointer like
ffffc0745b4580aa). And it causes lots of other
hard-to-debug problems.

This symptom is caused since the first member in the
ion_handle structure is the reference count and the
ion driver decrements the reference after it has been
freed.

To fix this problem client->lock mutex is extended
to protect all the codes that uses the handle.

Signed-off-by: Eun Taik Lee 
Reviewed-by: Laura Abbott 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

index 7ff2a7ec871f..33b390e7ea31

staging: android: ashmem: lseek failed due to no FMODE_LSEEK.

2017-04-12T10:38:33+00:00

commit 97fbfef6bd597888485b653175fb846c6998b60c upstream.

vfs_llseek will check whether the file mode has
FMODE_LSEEK, no return failure. But ashmem can be
lseek, so add FMODE_LSEEK to ashmem file.

Comment From Greg Hackmann:
	ashmem_llseek() passes the llseek() call through to the backing
	shmem file.  91360b02ab48 ("ashmem: use vfs_llseek()") changed
	this from directly calling the file's llseek() op into a VFS
	layer call.  This also adds a check for the FMODE_LSEEK bit, so
	without that bit ashmem_llseek() now always fails with -ESPIPE.

Fixes: 91360b02ab48 ("ashmem: use vfs_llseek()")
Signed-off-by: Shuxiao Zhang 
Tested-by: Greg Hackmann 
Signed-off-by: Greg Kroah-Hartman