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

uio: fix a sleep-in-atomic-context bug in uio_dmem_genirq_irqcontrol()

2020-02-24T07:34:37+00:00

[ Upstream commit b74351287d4bd90636c3f48bc188c2f53824c2d4 ] The driver may sleep while holding a spinlock. The function call path (from bottom to top) in Linux 4.19 is: kernel/irq/manage.c, 523: synchronize_irq in disable_irq drivers/uio/uio_dmem_genirq.c, 140: disable_irq in uio_dmem_genirq_irqcontrol drivers/uio/uio_dmem_genirq.c, 134: _raw_spin_lock_irqsave in uio_dmem_genirq_irqcontrol synchronize_irq() can sleep at runtime. To fix this bug, disable_irq() is called without holding the spinlock. This bug is found by a static analysis tool STCheck written by myself. Signed-off-by: Jia-Ju Bai Link: https://lore.kernel.org/r/20191218094405.6009-1-baijiaju1990@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

driver: uio: fix possible use-after-free in __uio_register_device

2020-01-27T13:50:17+00:00

[ Upstream commit 221a1f4ac12d2ab46246c160b2e00d1b1160d5d9 ] In uio_dev_add_attributes() error handing case, idev is used after device_unregister(), in which 'idev' has been released, touch idev cause use-after-free. Fixes: a93e7b331568 ("uio: Prevent device destruction while fds are open") Signed-off-by: Liu Jian Reviewed-by: Hamish Martin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

driver: uio: fix possible memory leak in __uio_register_device

2020-01-27T13:50:16+00:00

[ Upstream commit 1a392b3de7c5747506b38fc14b2e79977d3c7770 ] 'idev' is malloced in __uio_register_device() and leak free it before leaving from the uio_get_minor() error handing case, it will cause memory leak. Fixes: a93e7b331568 ("uio: Prevent device destruction while fds are open") Signed-off-by: Liu Jian Reviewed-by: Hamish Martin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

vmbus: keep pointer to ring buffer page

2019-11-20T17:47:31+00:00

[ Upstream commit 52a42c2a90226dc61c99bbd0cb096deeb52c334b ] Avoid going from struct page to virt address (and back) by just keeping pointer to the allocated pages instead of virt address. Signed-off-by: Stephen Hemminger Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

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