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

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

2017-06-13T13:29:21+00:00

[ Upstream commit b58f45c8fc301fe83ee28cad3e64686c19e78f1c ]

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: stable      # 3.12
Cc: Won Kang 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: emxx_udc: remove incorrect __init annotations

2017-06-13T13:29:20+00:00

[ Upstream commit 4f3445067d5f78fb8d1970b02610f85c2f377ea4 ]

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 
Signed-off-by: Sasha Levin

staging: wlan-ng: add missing byte order conversion

2017-06-13T13:29:20+00:00

[ Upstream commit 2c474b8579e9b67ff72b2bcefce9f53c7f4469d4 ]

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 
Signed-off-by: Sasha Levin

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

2017-06-13T13:29:17+00:00

[ Upstream commit 9590232bb4f4cc824f3425a6e1349afbe6d6d2b7 ]

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 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

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

2017-05-17T19:08:21+00:00

[ Upstream commit 97fbfef6bd597888485b653175fb846c6998b60c ]

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 
Cc: stable  # 3.18+
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: comedi: jr3_pci: cope with jiffies wraparound

2017-05-17T19:07:00+00:00

[ Upstream commit 8ec04a491825e08068e92bed0bba7821893b6433 ]

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.

Cc:  # 3.15+
Signed-off-by: Ian Abbott 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: comedi: jr3_pci: fix possible null pointer dereference

2017-05-17T19:07:00+00:00

[ Upstream commit 45292be0b3db0b7f8286683b376e2d9f949d11f9 ]

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.

Cc:  # 3.15+
Signed-off-by: Ian Abbott 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: rtl: fix possible NULL pointer dereference

2017-05-16T03:19:46+00:00

[ Upstream commit 6e017006022abfea5d2466cad936065f45763ad1 ]

gcc-7 detects that wlanhdr_to_ethhdr() in two drivers calls memcpy() with
a destination argument that an earlier function call may have set to NULL:

staging/rtl8188eu/core/rtw_recv.c: In function 'wlanhdr_to_ethhdr':
staging/rtl8188eu/core/rtw_recv.c:1318:2: warning: argument 1 null where non-null expected [-Wnonnull]
staging/rtl8712/rtl871x_recv.c: In function 'r8712_wlanhdr_to_ethhdr':
staging/rtl8712/rtl871x_recv.c:649:2: warning: argument 1 null where non-null expected [-Wnonnull]

I'm fixing this by adding a NULL pointer check and returning failure
from the function, which is hopefully already handled properly.

This seems to date back to when the drivers were originally added,
so backporting the fix to stable seems appropriate. There are other
related realtek drivers in the kernel, but none of them contain a
function with a similar name or produce this warning.

Cc: stable@vger.kernel.org
Fixes: 1cc18a22b96b ("staging: r8188eu: Add files for new driver - part 5")
Fixes: 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

staging: comedi: ni_mio_common: fix M Series ni_ai_insn_read() data mask

2017-01-13T01:56:53+00:00

[ Upstream commit 655c4d442d1213b617926cc6d54e2a9a793fb46b ]

For NI M Series cards, the Comedi `insn_read` handler for the AI
subdevice is broken due to ANDing the value read from the AI FIFO data
register with an incorrect mask.  The incorrect mask clears all but the
most significant bit of the sample data.  It should preserve all the
sample data bits.  Correct it.

Fixes: 817144ae7fda ("staging: comedi: ni_mio_common: remove unnecessary use of 'board->adbits'")
Signed-off-by: Ian Abbott 
Cc: 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

fs: Give dentry to inode_change_ok() instead of inode

2016-12-23T13:56:35+00:00

[ Upstream commit 31051c85b5e2aaaf6315f74c72a732673632a905 ]

inode_change_ok() will be resposible for clearing capabilities and IMA
extended attributes and as such will need dentry. Give it as an argument
to inode_change_ok() instead of an inode. Also rename inode_change_ok()
to setattr_prepare() to better relect that it does also some
modifications in addition to checks.

References: CVE-2015-1350
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jan Kara 
Signed-off-by: Philipp Hahn 
Signed-off-by: Sasha Levin