kernel/linux.git/drivers/uio, branch v4.19.77

uio: Fix an Oops on load

2018-11-27T15:13:09+00:00

commit 432798195bbce1f8cd33d1c0284d0538835e25fb upstream. I was trying to solve a double free but I introduced a more serious NULL dereference bug. The problem is that if there is an IRQ which triggers immediately, then we need "info->uio_dev" but it's not set yet. This patch puts the original initialization back to how it was and just sets info->uio_dev to NULL on the error path so it should solve both the Oops and the double free. Fixes: f019f07ecf6a ("uio: potential double frees if __uio_register_device() fails") Reported-by: Mathias Thore Signed-off-by: Dan Carpenter Cc: stable Tested-by: Mathias Thore Signed-off-by: Greg Kroah-Hartman

uio: ensure class is registered before devices

2018-11-13T19:08:37+00:00

[ Upstream commit ae61cf5b9913027c6953a79ed3894da4f47061bd ] When both uio and the uio drivers are built in the kernel, it is possible for a driver to register devices before the uio class is registered. This may result in a NULL pointer dereference later on in get_device_parent() when accessing the class glue_dirs spinlock. The trace looks like that: Unable to handle kernel NULL pointer dereference at virtual address 00000140 [...] [] _raw_spin_lock+0x14/0x48 [] device_add+0x154/0x6a0 [] device_create_groups_vargs+0x120/0x128 [] device_create+0x54/0x60 [] __uio_register_device+0x120/0x4a8 [] jaguar2_pci_probe+0x2d4/0x558 [] local_pci_probe+0x3c/0xb8 [] pci_device_probe+0x11c/0x180 [] driver_probe_device+0x22c/0x2d8 [] __driver_attach+0xbc/0xc0 [] bus_for_each_dev+0x4c/0x98 [] driver_attach+0x20/0x28 [] bus_add_driver+0x1b8/0x228 [] driver_register+0x60/0xf8 [] __pci_register_driver+0x40/0x48 Return EPROBE_DEFER in that case so the driver can register the device later. Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

Merge tag 'char-misc-4.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc

2018-08-19T16:30:44+00:00

Pull UIO fix from Greg KH: "Here is a single UIO fix that I forgot to send before 4.18-final came out. It reverts a UIO patch that went in the 4.18 development window that was causing problems. This patch has been in linux-next for a while with no problems, I just forgot to send it earlier, or as part of the larger char/misc patch series from yesterday, my fault" * tag 'char-misc-4.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: Revert "uio: use request_threaded_irq instead"

Revert "uio: use request_threaded_irq instead"

2018-08-12T15:30:58+00:00

Since mutex lock in irq hanler is useless currently, here will remove it together with it. This reverts commit 9421e45f5ff3d558cf8b75a8cc0824530caf3453. Reported-by: james.r.harris@intel.com CC: Ahsan Atta Signed-off-by: Xiubo Li Signed-off-by: Greg Kroah-Hartman

uio: potential double frees if __uio_register_device() fails

2018-08-02T08:42:25+00:00

The uio_unregister_device() function assumes that if "info->uio_dev" is non-NULL that means "info" is fully allocated. Setting info->uio_de has to be the last thing in the function. In the current code, if request_threaded_irq() fails then we return with info->uio_dev set to non-NULL but info is not fully allocated and it can lead to double frees. Fixes: beafc54c4e2f ("UIO: Add the User IO core code") Signed-off-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman

uio: fix possible circular locking dependency

2018-08-02T08:14:26+00:00

The call trace: XXX/1910 is trying to acquire lock: (&mm->mmap_sem){++++++}, at: [] might_fault+0x57/0xb0 but task is already holding lock: (&idev->info_lock){+.+...}, at: [] uio_write+0x46/0x130 [uio] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&idev->info_lock){+.+...}: [] lock_acquire+0x99/0x1e0 [] mutex_lock_nested+0x93/0x410 [] uio_mmap+0x2d/0x170 [uio] [] mmap_region+0x428/0x650 [] do_mmap+0x3b8/0x4e0 [] vm_mmap_pgoff+0xd3/0x120 [] SyS_mmap_pgoff+0x1f1/0x270 [] SyS_mmap+0x22/0x30 [] system_call_fastpath+0x1c/0x21 -> #0 (&mm->mmap_sem){++++++}: [] __lock_acquire+0xdac/0x15f0 [] lock_acquire+0x99/0x1e0 [] might_fault+0x84/0xb0 [] uio_write+0xb4/0x130 [uio] [] vfs_write+0xc3/0x1f0 [] SyS_write+0x8a/0x100 [] system_call_fastpath+0x1c/0x21 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&idev->info_lock); lock(&mm->mmap_sem); lock(&idev->info_lock); lock(&mm->mmap_sem); *** DEADLOCK *** 1 lock held by XXX/1910: #0: (&idev->info_lock){+.+...}, at: [] uio_write+0x46/0x130 [uio] stack backtrace: CPU: 0 PID: 1910 Comm: XXX Kdump: loaded Not tainted #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017 Call Trace: [] dump_stack+0x19/0x1b [] print_circular_bug+0x1f9/0x207 [] check_prevs_add+0x957/0x960 [] __lock_acquire+0xdac/0x15f0 [] ? mark_held_locks+0xb9/0x140 [] lock_acquire+0x99/0x1e0 [] ? might_fault+0x57/0xb0 [] might_fault+0x84/0xb0 [] ? might_fault+0x57/0xb0 [] uio_write+0xb4/0x130 [uio] [] vfs_write+0xc3/0x1f0 [] ? fget_light+0xfc/0x510 [] SyS_write+0x8a/0x100 [] system_call_fastpath+0x1c/0x21 Signed-off-by: Xiubo Li Signed-off-by: Greg Kroah-Hartman

uio: pruss: fix error handling in probe

2018-08-02T08:14:26+00:00

There are two bugs here. First the error codes weren't set on several paths. And second, if the call to request_threaded_irq() inside uio_register_device() fails then it would lead to a double free when we call uio_unregister_device() inside pruss_cleanup(). Signed-off-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman

uio: add SPDX license tags

2018-07-21T13:41:20+00:00

For those without any license text present or short reference to GPL, add SPDX tag. Signed-off-by: Stephen Hemminger Signed-off-by: Greg Kroah-Hartman

uio: fix wrong return value from uio_mmap()

2018-07-21T06:45:24+00:00

uio_mmap has multiple fail paths to set return value to nonzero then goto out. However, it always returns *0* from the *out* at end, and this will mislead callers who check the return value of this function. Fixes: 57c5f4df0a5a0ee ("uio: fix crash after the device is unregistered") CC: Xiubo Li Signed-off-by: Hailong Liu Cc: stable Signed-off-by: Jiang Biao Signed-off-by: Greg Kroah-Hartman

uio: add SPDX license tag

2018-07-21T06:44:08+00:00

Replace short statement in comment with proper SPDX license tag. Signed-off-by: Stephen Hemminger Signed-off-by: Greg Kroah-Hartman