linux-stable.git/drivers/uio, branch v4.19.2

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

uio: fix crash after the device is unregistered

2018-07-07T14:57:35+00:00

For the target_core_user use case, after the device is unregistered
it maybe still opened in user space, then the kernel will crash, like:

[  251.163692] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[  251.163820] IP: [] show_name+0x23/0x40 [uio]
[  251.163965] PGD 8000000062694067 PUD 62696067 PMD 0
[  251.164097] Oops: 0000 [#1] SMP
...
[  251.165605]  e1000 mptscsih mptbase drm_panel_orientation_quirks dm_mirror dm_region_hash dm_log dm_mod
[  251.166014] CPU: 0 PID: 13380 Comm: tcmu-runner Kdump: loaded Not tainted 3.10.0-916.el7.test.x86_64 #1
[  251.166381] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
[  251.166747] task: ffff971eb91db0c0 ti: ffff971e9e384000 task.ti: ffff971e9e384000
[  251.167137] RIP: 0010:[]  [] show_name+0x23/0x40 [uio]
[  251.167563] RSP: 0018:ffff971e9e387dc8  EFLAGS: 00010282
[  251.167978] RAX: 0000000000000000 RBX: ffff971e9e3f8000 RCX: ffff971eb8368d98
[  251.168408] RDX: ffff971e9e3f8000 RSI: ffffffffc0738084 RDI: ffff971e9e3f8000
[  251.168856] RBP: ffff971e9e387dd0 R08: ffff971eb8bc0018 R09: 0000000000000000
[  251.169296] R10: 0000000000001000 R11: ffffffffa09d444d R12: ffffffffa1076e80
[  251.169750] R13: ffff971e9e387f18 R14: 0000000000000001 R15: ffff971e9cfb1c80
[  251.170213] FS:  00007ff37d175880(0000) GS:ffff971ebb600000(0000) knlGS:0000000000000000
[  251.170693] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  251.171248] CR2: 0000000000000008 CR3: 00000000001f6000 CR4: 00000000003607f0
[  251.172071] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  251.172640] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  251.173236] Call Trace:
[  251.173789]  [] dev_attr_show+0x23/0x60
[  251.174356]  [] ? mutex_lock+0x12/0x2f
[  251.174892]  [] sysfs_kf_seq_show+0xcf/0x1f0
[  251.175433]  [] kernfs_seq_show+0x26/0x30
[  251.175981]  [] seq_read+0x110/0x3f0
[  251.176609]  [] kernfs_fop_read+0xf5/0x160
[  251.177158]  [] vfs_read+0x9f/0x170
[  251.177707]  [] SyS_read+0x7f/0xf0
[  251.178268]  [] system_call_fastpath+0x1c/0x21
[  251.178823] Code: 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 53 48 89 d3 e8 7e 96 56 e0 48 8b 80 d8 02 00 00 48 89 df 48 c7 c6 84 80 73 c0 <48> 8b 50 08 31 c0 e8 e2 67 44 e0 5b 48 98 5d c3 0f 1f 00 66 2e
[  251.180115] RIP  [] show_name+0x23/0x40 [uio]
[  251.180820]  RSP 
[  251.181473] CR2: 0000000000000008

CC: Hamish Martin 
CC: Mike Christie 
Reviewed-by: Hamish Martin 
Signed-off-by: Xiubo Li 
Signed-off-by: Greg Kroah-Hartman