- Sep 22, 2020
-
-
Jiri Olsa authored
stable inclusion from linux-4.19.130 commit 98abe944f93faf19c3707f8f188df5073e5668f8 -------------------------------- [ Upstream commit 9b38cc70 ] Ziqian reported lockup when adding retprobe on _raw_spin_lock_irqsave. My test was also able to trigger lockdep output: ============================================ WARNING: possible recursive locking detected 5.6.0-rc6+ #6 Not tainted -------------------------------------------- sched-messaging/2767 is trying to acquire lock: ffffffff9a492798 (&(kretprobe_table_locks[i].lock)){-.-.}, at: kretprobe_hash_lock+0x52/0xa0 but task is already holding lock: ffffffff9a491a18 (&(kretprobe_table_locks[i].lock)){-.-.}, at: kretprobe_trampoline+0x0/0x50 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(kretprobe_table_locks[i].lock)); lock(&(kretprobe_table_locks[i].lock)); *** DEADLOCK *** May be due to missing lock nesting notation 1 lock held by sched-messaging/2767: #0: ffffffff9a491a18 (&(kretprobe_table_locks[i].lock)){-.-.}, at: kretprobe_trampoline+0x0/0x50 stack backtrace: CPU: 3 PID: 2767 Comm: sched-messaging Not tainted 5.6.0-rc6+ #6 Call Trace: dump_stack+0x96/0xe0 __lock_acquire.cold.57+0x173/0x2b7 ? native_queued_spin_lock_slowpath+0x42b/0x9e0 ? lockdep_hardirqs_on+0x590/0x590 ? __lock_acquire+0xf63/0x4030 lock_acquire+0x15a/0x3d0 ? kretprobe_hash_lock+0x52/0xa0 _raw_spin_lock_irqsave+0x36/0x70 ? kretprobe_hash_lock+0x52/0xa0 kretprobe_hash_lock+0x52/0xa0 trampoline_handler+0xf8/0x940 ? kprobe_fault_handler+0x380/0x380 ? find_held_lock+0x3a/0x1c0 kretprobe_trampoline+0x25/0x50 ? lock_acquired+0x392/0xbc0 ? _raw_spin_lock_irqsave+0x50/0x70 ? __get_valid_kprobe+0x1f0/0x1f0 ? _raw_spin_unlock_irqrestore+0x3b/0x40 ? finish_task_switch+0x4b9/0x6d0 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 The code within the kretprobe handler checks for probe reentrancy, so we won't trigger any _raw_spin_lock_irqsave probe in there. The problem is in outside kprobe_flush_task, where we call: kprobe_flush_task kretprobe_table_lock raw_spin_lock_irqsave _raw_spin_lock_irqsave where _raw_spin_lock_irqsave triggers the kretprobe and installs kretprobe_trampoline handler on _raw_spin_lock_irqsave return. The kretprobe_trampoline handler is then executed with already locked kretprobe_table_locks, and first thing it does is to lock kretprobe_table_locks ;-) the whole lockup path like: kprobe_flush_task kretprobe_table_lock raw_spin_lock_irqsave _raw_spin_lock_irqsave ---> probe triggered, kretprobe_trampoline installed ---> kretprobe_table_locks locked kretprobe_trampoline trampoline_handler kretprobe_hash_lock(current, &head, &flags); <--- deadlock Adding kprobe_busy_begin/end helpers that mark code with fake probe installed to prevent triggering of another kprobe within this code. Using these helpers in kprobe_flush_task, so the probe recursion protection check is hit and the probe is never set to prevent above lockup. Link: http://lkml.kernel.org/r/158927059835.27680.7011202830041561604.stgit@devnote2 Fixes: ef53d9c5 ("kprobes: improve kretprobe scalability with hashed locking") Cc: Ingo Molnar <mingo@kernel.org> Cc: "Gustavo A . R . Silva" <gustavoars@kernel.org> Cc: Anders Roxell <anders.roxell@linaro.org> Cc: "Naveen N . Rao" <naveen.n.rao@linux.ibm.com> Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> Cc: David Miller <davem@davemloft.net> Cc: Ingo Molnar <mingo@elte.hu> Cc: Peter Zijlstra <peterz@infradead.org> Cc: stable@vger.kernel.org Reported-by:
"Ziqian SUN (Zamir)" <zsun@redhat.com> Acked-by:
Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Theodore Ts'o authored
stable inclusion from linux-4.19.130 commit 5dbb625573abf67b9f7d6992c8e3f57acaef5946 -------------------------------- [ Upstream commit 829b37b8 ] Trying to change dax mount options when remounting could allow mount options to be enabled for a small amount of time, and then the mount option change would be reverted. In the case of "mount -o remount,dax", this can cause a race where files would temporarily treated as DAX --- and then not. Cc: stable@kernel.org Reported-by:
<syzbot+bca9799bf129256190da@syzkaller.appspotmail.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Sasha Levin authored
stable inclusion from linux-4.19.130 commit 051bf267b1fabba8a585a185eb816bf0006bdae6 -------------------------------- [ Upstream commit cfb3c85a ] Fix the bug when calculating the physical block number of the first block in the split extent. This bug will cause xfstests shared/298 failure on ext4 with bigalloc enabled occasionally. Ext4 error messages indicate that previously freed blocks are being freed again, and the following fsck will fail due to the inconsistency of block bitmap and bg descriptor. The following is an example case: 1. First, Initialize a ext4 filesystem with cluster size '16K', block size '4K', in which case, one cluster contains four blocks. 2. Create one file (e.g., xxx.img) on this ext4 filesystem. Now the extent tree of this file is like: ... 36864:[0]4:220160 36868:[0]14332:145408 51200:[0]2:231424 ... 3. Then execute PUNCH_HOLE fallocate on this file. The hole range is like: .. ext4_ext_remove_space: dev 254,16 ino 12 since 49506 end 49506 depth 1 ext4_ext_remove_space: dev 254,16 ino 12 since 49544 end 49546 depth 1 ext4_ext_remove_space: dev 254,16 ino 12 since 49605 end 49607 depth 1 ... 4. Then the extent tree of this file after punching is like ... 49507:[0]37:158047 49547:[0]58:158087 ... 5. Detailed procedure of punching hole [49544, 49546] 5.1. The block address space: ``` lblk ~49505 49506 49507~49543 49544~49546 49547~ ---------+------+-------------+----------------+-------- extent | hole | extent | hole | extent ---------+------+-------------+----------------+-------- pblk ~158045 158046 158047~158083 158084~158086 158087~ ``` 5.2. The detailed layout of cluster 39521: ``` cluster 39521 <-------------------------------> hole extent <----------------------><-------- lblk 49544 49545 49546 49547 +-------+-------+-------+-------+ | | | | | +-------+-------+-------+-------+ pblk 158084 1580845 158086 158087 ``` 5.3. The ftrace output when punching hole [49544, 49546]: - ext4_ext_remove_space (start 49544, end 49546) - ext4_ext_rm_leaf (start 49544, end 49546, last_extent [49507(158047), 40], partial [pclu 39522 lblk 0 state 2]) - ext4_remove_blocks (extent [49507(158047), 40], from 49544 to 49546, partial [pclu 39522 lblk 0 state 2] - ext4_free_blocks: (block 158084 count 4) - ext4_mballoc_free (extent 1/6753/1) 5.4. Ext4 error message in dmesg: EXT4-fs error (device vdb): mb_free_blocks:1457: group 1, block 158084:freeing already freed block (bit 6753); block bitmap corrupt. EXT4-fs error (device vdb): ext4_mb_generate_buddy:747: group 1, block bitmap and bg descriptor inconsistent: 19550 vs 19551 free clusters In this case, the whole cluster 39521 is freed mistakenly when freeing pblock 158084~158086 (i.e., the first three blocks of this cluster), although pblock 158087 (the last remaining block of this cluster) has not been freed yet. The root cause of this isuue is that, the pclu of the partial cluster is calculated mistakenly in ext4_ext_remove_space(). The correct partial_cluster.pclu (i.e., the cluster number of the first block in the next extent, that is, lblock 49597 (pblock 158086)) should be 39521 rather than 39522. Fixes: f4226d9e ("ext4: fix partial cluster initialization") Signed-off-by:
Jeffle Xu <jefflexu@linux.alibaba.com> Reviewed-by:
Eric Whitney <enwlinux@gmail.com> Cc: stable@kernel.org # v3.19+ Link: https://lore.kernel.org/r/1590121124-37096-1-git-send-email-jefflexu@linux.alibaba.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Tom Rix authored
stable inclusion from linux-4.19.130 commit cd80735a43a9c8fd5e883f8313e3ba7b27167310 -------------------------------- commit 65de5096 upstream. Clang's static analysis tool reports these double free memory errors. security/selinux/ss/services.c:2987:4: warning: Attempt to free released memory [unix.Malloc] kfree(bnames[i]); ^~~~~~~~~~~~~~~~ security/selinux/ss/services.c:2990:2: warning: Attempt to free released memory [unix.Malloc] kfree(bvalues); ^~~~~~~~~~~~~~ So improve the security_get_bools error handling by freeing these variables and setting their return pointers to NULL and the return len to 0 Cc: stable@vger.kernel.org Signed-off-by:
Tom Rix <trix@redhat.com> Acked-by:
Stephen Smalley <stephen.smalley.work@gmail.com> Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Will Deacon authored
stable inclusion from linux-4.19.130 commit a39340ab12b3234dc9b74cc878d1f6bc81dc97bd -------------------------------- [ Upstream commit 24ebec25 ] Unprivileged memory accesses generated by the so-called "translated" instructions (e.g. STTR) at EL1 can cause EL0 watchpoints to fire unexpectedly if kernel debugging is enabled. In such cases, the hw_breakpoint logic will invoke the user overflow handler which will typically raise a SIGTRAP back to the current task. This is futile when returning back to the kernel because (a) the signal won't have been delivered and (b) userspace can't handle the thing anyway. Avoid invoking the user overflow handler for watchpoints triggered by kernel uaccess routines, and instead single-step over the faulting instruction as we would if no overflow handler had been installed. (Fixes tag identifies the introduction of unprivileged memory accesses, which exposed this latent bug in the hw_breakpoint code) Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: James Morse <james.morse@arm.com> Fixes: 57f4959b ("arm64: kernel: Add support for User Access Override") Reported-by:
Luis Machado <luis.machado@linaro.org> Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Jann Horn authored
stable inclusion from linux-4.19.130 commit c1d9c6995d83e63c41eb982d25cbc415e3f004f0 -------------------------------- [ Upstream commit acaab733 ] The zlib inflate code has an old micro-optimization based on the assumption that for pre-increment memory accesses, the compiler will generate code that fits better into the processor's pipeline than what would be generated for post-increment memory accesses. This optimization was already removed in upstream zlib in 2016: https://github.com/madler/zlib/commit/9aaec95e8211 This optimization causes UB according to C99, which says in section 6.5.6 "Additive operators": "If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined". This UB is not only a theoretical concern, but can also cause trouble for future work on compiler-based sanitizers. According to the zlib commit, this optimization also is not optimal anymore with modern compilers. Replace uses of OFF, PUP and UP_UNALIGNED with their definitions in the POSTINC case, and remove the macro definitions, just like in the upstream patch. Signed-off-by:
Jann Horn <jannh@google.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Cc: Mikhail Zaslonko <zaslonko@linux.ibm.com> Link: http://lkml.kernel.org/r/20200507123112.252723-1-jannh@google.com Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Qiushi Wu authored
stable inclusion from linux-4.19.130 commit 1a98e4ef324d4735b0a8240717b4e2d1bb9adfd8 -------------------------------- [ Upstream commit aa8ba13c ] kobject_init_and_add() takes reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Thus, replace kfree() by kobject_put() to fix this issue. Previous commit "b8eb7183" fixed a similar problem. Fixes: 7b96953b ("vfio: Mediated device Core driver") Signed-off-by:
Qiushi Wu <wu000273@umn.edu> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Reviewed-by:
Kirti Wankhede <kwankhede@nvidia.com> Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Marc Zyngier authored
stable inclusion from linux-4.19.130 commit ff6136914a9b0704f3495d22624571dd9de162bd -------------------------------- [ Upstream commit 0414b93e ] On a system that uses the internal DWC MSI widget, I get this warning from debugfs when CONFIG_GENERIC_IRQ_DEBUGFS is selected: debugfs: File ':soc:pcie@fc000000' in directory 'domains' already present! This is due to the fact that the DWC MSI code tries to register two IRQ domains for the same firmware node, without telling the low level code how to distinguish them (by setting a bus token). This further confuses debugfs which tries to create corresponding files for each domain. Fix it by tagging the inner domain as DOMAIN_BUS_NEXUS, which is the closest thing we have as to "generic MSI". Link: https://lore.kernel.org/r/20200501113921.366597-1-maz@kernel.org Signed-off-by:
Marc Zyngier <maz@kernel.org> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by:
Jingoo Han <jingoohan1@gmail.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Hannes Reinecke authored
stable inclusion from linux-4.19.130 commit 4ad7add5077880f232190962f309907d4f8e74f3 -------------------------------- [ Upstream commit 489dc0f0 ] The only case where dmz_get_zone_for_reclaim() cannot return a zone is if the respective lists are empty. So we should just return a simple NULL value here as we really don't have an error code which would make sense. Signed-off-by:
Hannes Reinecke <hare@suse.de> Reviewed-by:
Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Feng Tang authored
stable inclusion from linux-4.19.130 commit 1d9c47a329a3045fbb761d10aa2930f8811011dc -------------------------------- [ Upstream commit 7c47a219 ] We met mulitple times of failure of staring bmc-watchdog, due to the runtime memory allocation failure of order 4. bmc-watchdog: page allocation failure: order:4, mode:0x40cc0(GFP_KERNEL|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0-1 CPU: 1 PID: 2571 Comm: bmc-watchdog Not tainted 5.5.0-00045-g7d6bb61d6188c #1 Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.00.01.0015.110720180833 11/07/2018 Call Trace: dump_stack+0x66/0x8b warn_alloc+0xfe/0x160 __alloc_pages_slowpath+0xd3e/0xd80 __alloc_pages_nodemask+0x2f0/0x340 kmalloc_order+0x18/0x70 kmalloc_order_trace+0x1d/0xb0 ipmi_create_user+0x55/0x2c0 [ipmi_msghandler] ipmi_open+0x72/0x110 [ipmi_devintf] chrdev_open+0xcb/0x1e0 do_dentry_open+0x1ce/0x380 path_openat+0x305/0x14f0 do_filp_open+0x9b/0x110 do_sys_open+0x1bd/0x250 do_syscall_64+0x5b/0x1f0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Using vzalloc/vfree for creating ipmi_user heals the problem Thanks to Stephen Rothwell for finding the vmalloc.h inclusion issue. Signed-off-by:
Feng Tang <feng.tang@intel.com> Signed-off-by:
Corey Minyard <cminyard@mvista.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Rob Herring authored
stable inclusion from linux-4.19.130 commit 5d78c4a343f4e89b47b27d382b117ce70a1138a5 -------------------------------- [ Upstream commit 1b54ae83 ] If device_register() has an error, we should bail out of pci_register_host_bridge() rather than continuing on. Fixes: 37d6a0a6 ("PCI: Add pci_register_host_bridge() interface") Link: https://lore.kernel.org/r/20200513223859.11295-1-robh@kernel.org Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Kuppuswamy Sathyanarayanan authored
drivers: base: Fix NULL pointer exception in __platform_driver_probe() if a driver developer is foolish stable inclusion from linux-4.19.130 commit cd74de676af119f4110be9f828f22da953dd94b0 -------------------------------- [ Upstream commit 388bcc6e ] If platform bus driver registration is failed then, accessing platform bus spin lock (&drv->driver.bus->p->klist_drivers.k_lock) in __platform_driver_probe() without verifying the return value __platform_driver_register() can lead to NULL pointer exception. So check the return value before attempting the spin lock. One such example is below: For a custom usecase, I have intentionally failed the platform bus registration and I expected all the platform device/driver registrations to fail gracefully. But I came across this panic issue. [ 1.331067] BUG: kernel NULL pointer dereference, address: 00000000000000c8 [ 1.331118] #PF: supervisor write access in kernel mode [ 1.331163] #PF: error_code(0x0002) - not-present page [ 1.331208] PGD 0 P4D 0 [ 1.331233] Oops: 0002 [#1] PREEMPT SMP [ 1.331268] CPU: 3 PID: 1 Comm: swapper/0 Tainted: G W 5.6.0-00049-g670d35fb0144 #165 [ 1.331341] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 [ 1.331406] RIP: 0010:_raw_spin_lock+0x15/0x30 [ 1.331588] RSP: 0000:ffffc9000001be70 EFLAGS: 00010246 [ 1.331632] RAX: 0000000000000000 RBX: 00000000000000c8 RCX: 0000000000000001 [ 1.331696] RDX: 0000000000000001 RSI: 0000000000000092 RDI: 0000000000000000 [ 1.331754] RBP: 00000000ffffffed R08: 0000000000000501 R09: 0000000000000001 [ 1.331817] R10: ffff88817abcc520 R11: 0000000000000670 R12: 00000000ffffffed [ 1.331881] R13: ffffffff82dbc268 R14: ffffffff832f070a R15: 0000000000000000 [ 1.331945] FS: 0000000000000000(0000) GS:ffff88817bd80000(0000) knlGS:0000000000000000 [ 1.332008] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.332062] CR2: 00000000000000c8 CR3: 000000000681e001 CR4: 00000000003606e0 [ 1.332126] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1.332189] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1.332252] Call Trace: [ 1.332281] __platform_driver_probe+0x92/0xee [ 1.332323] ? rtc_dev_init+0x2b/0x2b [ 1.332358] cmos_init+0x37/0x67 [ 1.332396] do_one_initcall+0x7d/0x168 [ 1.332428] kernel_init_freeable+0x16c/0x1c9 [ 1.332473] ? rest_init+0xc0/0xc0 [ 1.332508] kernel_init+0x5/0x100 [ 1.332543] ret_from_fork+0x1f/0x30 [ 1.332579] CR2: 00000000000000c8 [ 1.332616] ---[ end trace 3bd87f12e9010b87 ]--- [ 1.333549] note: swapper/0[1] exited with preempt_count 1 [ 1.333592] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 [ 1.333736] Kernel Offset: disabled Note, this can only be triggered if a driver errors out from this call, which should never happen. If it does, the driver needs to be fixed. Signed-off-by:
Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Link: https://lore.kernel.org/r/20200408214003.3356-1-sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Simon Arlott authored
stable inclusion from linux-4.19.130 commit 5d41879d2ea51b1dd37798d5fdb597d55359caed -------------------------------- [ Upstream commit 6555781b ] If the cdrom fails to be registered then the device minor should be deallocated. Link: https://lore.kernel.org/r/072dac4b-8402-4de8-36bd-47e7588969cd@0882a8b5-c6c3-11e9-b005-00805fc181fe Signed-off-by:
Simon Arlott <simon@octiron.net> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Qian Cai authored
stable inclusion from linux-4.19.130 commit 78914f1689701e997a17891644117539d6c103cf -------------------------------- [ Upstream commit 3e63b94b ] vfio_pci_disable() calls vfio_config_free() but forgets to call free_perm_bits() resulting in memory leaks, unreferenced object 0xc000000c4db2dee0 (size 16): comm "qemu-kvm", pid 4305, jiffies 4295020272 (age 3463.780s) hex dump (first 16 bytes): 00 00 ff 00 ff ff ff ff ff ff ff ff ff ff 00 00 ................ backtrace: [<00000000a6a4552d>] alloc_perm_bits+0x58/0xe0 [vfio_pci] [<00000000ac990549>] vfio_config_init+0xdf0/0x11b0 [vfio_pci] init_pci_cap_msi_perm at drivers/vfio/pci/vfio_pci_config.c:1125 (inlined by) vfio_msi_cap_len at drivers/vfio/pci/vfio_pci_config.c:1180 (inlined by) vfio_cap_len at drivers/vfio/pci/vfio_pci_config.c:1241 (inlined by) vfio_cap_init at drivers/vfio/pci/vfio_pci_config.c:1468 (inlined by) vfio_config_init at drivers/vfio/pci/vfio_pci_config.c:1707 [<000000006db873a1>] vfio_pci_open+0x234/0x700 [vfio_pci] [<00000000630e1906>] vfio_group_fops_unl_ioctl+0x8e0/0xb84 [vfio] [<000000009e34c54f>] ksys_ioctl+0xd8/0x130 [<000000006577923d>] sys_ioctl+0x28/0x40 [<000000006d7b1cf2>] system_call_exception+0x114/0x1e0 [<0000000008ea7dd5>] system_call_common+0xf0/0x278 unreferenced object 0xc000000c4db2e330 (size 16): comm "qemu-kvm", pid 4305, jiffies 4295020272 (age 3463.780s) hex dump (first 16 bytes): 00 ff ff 00 ff ff ff ff ff ff ff ff ff ff 00 00 ................ backtrace: [<000000004c71914f>] alloc_perm_bits+0x44/0xe0 [vfio_pci] [<00000000ac990549>] vfio_config_init+0xdf0/0x11b0 [vfio_pci] [<000000006db873a1>] vfio_pci_open+0x234/0x700 [vfio_pci] [<00000000630e1906>] vfio_group_fops_unl_ioctl+0x8e0/0xb84 [vfio] [<000000009e34c54f>] ksys_ioctl+0xd8/0x130 [<000000006577923d>] sys_ioctl+0x28/0x40 [<000000006d7b1cf2>] system_call_exception+0x114/0x1e0 [<0000000008ea7dd5>] system_call_common+0xf0/0x278 Fixes: 89e1f7d4 ("vfio: Add PCI device driver") Signed-off-by:
Qian Cai <cai@lca.pw> [aw: rolled in follow-up patch] Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Ard Biesheuvel authored
stable inclusion from linux-4.19.130 commit f7ec605600a3cbed562049600d9a668cb34f6978 -------------------------------- [ Upstream commit d09ddd81 ] When resizing a BAR, pci_reassign_bridge_resources() is invoked to bring the bridge windows of parent bridges in line with the new BAR assignment. This assumes the device whose BAR is being resized lives on a subordinate bus, but this is not necessarily the case. A device may live on the root bus, in which case dev->bus->self is NULL, and passing a NULL pci_dev pointer to pci_reassign_bridge_resources() will cause it to crash. So let's make the call to pci_reassign_bridge_resources() conditional on whether dev->bus->self is non-NULL in the first place. Fixes: 8bb705e3 ("PCI: Add pci_resize_resource() for resizing BARs") Link: https://lore.kernel.org/r/20200421162256.26887-1-ardb@kernel.org Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Corey Minyard authored
stable inclusion from linux-4.19.37 commit dacdbc115d23f1e4dbc091440bd5cdcdc01173b6 -------------------------------- commit 3b9a9072 upstream. free_user() could be called in atomic context. This patch pushed the free operation off into a workqueue. Example: BUG: sleeping function called from invalid context at kernel/workqueue.c:2856 in_atomic(): 1, irqs_disabled(): 0, pid: 177, name: ksoftirqd/27 CPU: 27 PID: 177 Comm: ksoftirqd/27 Not tainted 4.19.25-3 #1 Hardware name: AIC 1S-HV26-08/MB-DPSB04-06, BIOS IVYBV060 10/21/2015 Call Trace: dump_stack+0x5c/0x7b ___might_sleep+0xec/0x110 __flush_work+0x48/0x1f0 ? try_to_del_timer_sync+0x4d/0x80 _cleanup_srcu_struct+0x104/0x140 free_user+0x18/0x30 [ipmi_msghandler] ipmi_free_recv_msg+0x3a/0x50 [ipmi_msghandler] deliver_response+0xbd/0xd0 [ipmi_msghandler] deliver_local_response+0xe/0x30 [ipmi_msghandler] handle_one_recv_msg+0x163/0xc80 [ipmi_msghandler] ? dequeue_entity+0xa0/0x960 handle_new_recv_msgs+0x15c/0x1f0 [ipmi_msghandler] tasklet_action_common.isra.22+0x103/0x120 __do_softirq+0xf8/0x2d7 run_ksoftirqd+0x26/0x50 smpboot_thread_fn+0x11d/0x1e0 kthread+0x103/0x140 ? sort_range+0x20/0x20 ? kthread_destroy_worker+0x40/0x40 ret_from_fork+0x1f/0x40 Fixes: 77f82696 ("ipmi: fix use-after-free of user->release_barrier.rda") Reported-by:
Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Signed-off-by:
Corey Minyard <cminyard@mvista.com> Cc: stable@vger.kernel.org # 5.0 Cc: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Yang Yingliang authored
hulk inclusion category: bugfix bugzilla: 5499 CVE: NA --------------------------- cleanup_srcu_struct_quiesced won't free memory if work_pending() is true, and it will cause a memory leak, so revert it and using mainline patch instead. Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Douglas Anderson authored
stable inclusion from linux-4.19.129 commit 262c6e883e057ea186186f80f2e6e3fd614f7bd0 -------------------------------- commit b5945214 upstream. cpu_pm_notify() is basically a wrapper of notifier_call_chain(). notifier_call_chain() doesn't initialize *nr_calls to 0 before it starts incrementing it--presumably it's up to the callers to do this. Unfortunately the callers of cpu_pm_notify() don't init *nr_calls. This potentially means you could get too many or two few calls to CPU_PM_ENTER_FAILED or CPU_CLUSTER_PM_ENTER_FAILED depending on the luck of the stack. Let's fix this. Fixes: ab10023e ("cpu_pm: Add cpu power management notifiers") Cc: stable@vger.kernel.org Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200504104917.v6.3.I2d44fc0053d019f239527a4e5829416714b7e299@changeid Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Eric Biggers authored
stable inclusion from linux-4.19.129 commit 8f3f5ba25e2b811be915c1d86cf8d7847287339d -------------------------------- commit 08adf452 upstream. 'igrab(d_inode(dentry->d_parent))' without holding dentry->d_lock is broken because without d_lock, d_parent can be concurrently changed due to a rename(). Then if the old directory is immediately deleted, old d_parent->inode can be NULL. That causes a NULL dereference in igrab(). To fix this, use dget_parent() to safely grab a reference to the parent dentry, which pins the inode. This also eliminates the need to use d_find_any_alias() other than for the initial inode, as we no longer throw away the dentry at each step. This is an extremely hard race to hit, but it is possible. Adding a udelay() in between the reads of ->d_parent and its ->d_inode makes it reproducible on a no-journal filesystem using the following program: #include <fcntl.h> #include <unistd.h> int main() { if (fork()) { for (;;) { mkdir("dir1", 0700); int fd = open("dir1/file", O_RDWR|O_CREAT|O_SYNC); write(fd, "X", 1); close(fd); } } else { mkdir("dir2", 0700); for (;;) { rename("dir1/file", "dir2/file"); rmdir("dir1"); } } } Fixes: d59729f4 ("ext4: fix races in ext4_sync_parent()") Cc: stable@vger.kernel.org Signed-off-by:
Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20200506183140.541194-1-ebiggers@kernel.org Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Harshad Shirwadkar authored
stable inclusion from linux-4.19.129 commit acbec3dd4586d271a0248453d2810712439ded1b -------------------------------- commit c36a71b4 upstream. If eh->eh_max is 0, EXT_MAX_EXTENT/INDEX would evaluate to unsigned (-1) resulting in illegal memory accesses. Although there is no consistent repro, we see that generic/019 sometimes crashes because of this bug. Ran gce-xfstests smoke and verified that there were no regressions. Signed-off-by:
Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20200421023959.20879-2-harshadshirwadkar@gmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Pavel Tatashin authored
stable inclusion from linux-4.19.129 commit 88afa532c14135528b905015f1d9a5e740a95136 -------------------------------- commit 3d060856 upstream. Initializing struct pages is a long task and keeping interrupts disabled for the duration of this operation introduces a number of problems. 1. jiffies are not updated for long period of time, and thus incorrect time is reported. See proposed solution and discussion here: lkml/20200311123848.118638-1-shile.zhang@linux.alibaba.com 2. It prevents farther improving deferred page initialization by allowing intra-node multi-threading. We are keeping interrupts disabled to solve a rather theoretical problem that was never observed in real world (See 3a2d7fa8). Let's keep interrupts enabled. In case we ever encounter a scenario where an interrupt thread wants to allocate large amount of memory this early in boot we can deal with that by growing zone (see deferred_grow_zone()) by the needed amount before starting deferred_init_memmap() threads. Before: [ 1.232459] node 0 initialised, 12058412 pages in 1ms After: [ 1.632580] node 0 initialised, 12051227 pages in 436ms Fixes: 3a2d7fa8 ("mm: disable interrupts while initializing deferred pages") Reported-by:
Shile Zhang <shile.zhang@linux.alibaba.com> Signed-off-by:
Pavel Tatashin <pasha.tatashin@soleen.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Reviewed-by:
Daniel Jordan <daniel.m.jordan@oracle.com> Reviewed-by:
David Hildenbrand <david@redhat.com> Acked-by:
Michal Hocko <mhocko@suse.com> Acked-by:
Vlastimil Babka <vbabka@suse.cz> Cc: Dan Williams <dan.j.williams@intel.com> Cc: James Morris <jmorris@namei.org> Cc: Kirill Tkhai <ktkhai@virtuozzo.com> Cc: Sasha Levin <sashal@kernel.org> Cc: Yiqian Wei <yiwei@redhat.com> Cc: <stable@vger.kernel.org> [4.17+] Link: http://lkml.kernel.org/r/20200403140952.17177-3-pasha.tatashin@soleen.com Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Qiushi Wu authored
stable inclusion from linux-4.19.129 commit fad0431b7e61b750ef798c1a739382dfae85e231 -------------------------------- [ Upstream commit c343bf1b ] kobject_init_and_add() takes reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Previous commit "b8eb7183" fixed a similar problem. Signed-off-by:
Qiushi Wu <wu000273@umn.edu> [ rjw: Subject ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Serge Semin authored
stable inclusion from linux-4.19.129 commit 6d15fe48f50af2027c3292827c65277285acb9dc -------------------------------- [ Upstream commit f0410bbf ] DW APB SSI DMA-part of the driver may need to perform the requested SPI-transfer synchronously. In that case the dma_transfer() callback will return 0 as a marker of the SPI transfer being finished so the SPI core doesn't need to wait and may proceed with the SPI message trasnfers pumping procedure. This will be needed to fix the problem when DMA transactions are finished, but there is still data left in the SPI Tx/Rx FIFOs being sent/received. But for now make dma_transfer to return 1 as the normal dw_spi_transfer_one() method. Signed-off-by:
Serge Semin <Sergey.Semin@baikalelectronics.ru> Cc: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru> Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Feng Tang <feng.tang@intel.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: linux-mips@vger.kernel.org Cc: devicetree@vger.kernel.org Link: https://lore.kernel.org/r/20200529131205.31838-3-Sergey.Semin@baikalelectronics.ru Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Jiaxun Yang authored
stable inclusion from linux-4.19.129 commit 40a94a1ac783b878ec083b87242450949ae26eaf -------------------------------- [ Upstream commit b6caa1d8 ] Don't disable MEM/IO decoding when a device have both non_compliant_bars and mmio_always_on. That would allow us quirk devices with junk in BARs but can't disable their decoding. Signed-off-by:
Jiaxun Yang <jiaxun.yang@flygoat.com> Acked-by:
Bjorn Helgaas <helgaas@kernel.org> Signed-off-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Peter Zijlstra authored
stable inclusion from linux-4.19.129 commit 373491f1f41896241864b527b584856d8a510946 -------------------------------- [ Upstream commit bf2c59fc ] In the CPU-offline process, it calls mmdrop() after idle entry and the subsequent call to cpuhp_report_idle_dead(). Once execution passes the call to rcu_report_dead(), RCU is ignoring the CPU, which results in lockdep complaining when mmdrop() uses RCU from either memcg or debugobjects below. Fix it by cleaning up the active_mm state from BP instead. Every arch which has CONFIG_HOTPLUG_CPU should have already called idle_task_exit() from AP. The only exception is parisc because it switches them to &init_mm unconditionally (see smp_boot_one_cpu() and smp_cpu_init()), but the patch will still work there because it calls mmgrab(&init_mm) in smp_cpu_init() and then should call mmdrop(&init_mm) in finish_cpu(). WARNING: suspicious RCU usage ----------------------------- kernel/workqueue.c:710 RCU or wq_pool_mutex should be held! other info that might help us debug this: RCU used illegally from offline CPU! Call Trace: dump_stack+0xf4/0x164 (unreliable) lockdep_rcu_suspicious+0x140/0x164 get_work_pool+0x110/0x150 __queue_work+0x1bc/0xca0 queue_work_on+0x114/0x120 css_release+0x9c/0xc0 percpu_ref_put_many+0x204/0x230 free_pcp_prepare+0x264/0x570 free_unref_page+0x38/0xf0 __mmdrop+0x21c/0x2c0 idle_task_exit+0x170/0x1b0 pnv_smp_cpu_kill_self+0x38/0x2e0 cpu_die+0x48/0x64 arch_cpu_idle_dead+0x30/0x50 do_idle+0x2f4/0x470 cpu_startup_entry+0x38/0x40 start_secondary+0x7a8/0xa80 start_secondary_resume+0x10/0x14 Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
Qian Cai <cai@lca.pw> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Link: https://lkml.kernel.org/r/20200401214033.8448-1-cai@lca.pw Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Paul Moore authored
stable inclusion from linux-4.19.129 commit 4fe5dcafc74d9729e5f11f2d418c394eadbe0035 -------------------------------- [ Upstream commit 3054d067 ] If audit_list_rules_send() fails when trying to create a new thread to send the rules it also fails to cleanup properly, leaking a reference to a net structure. This patch fixes the error patch and renames audit_send_list() to audit_send_list_thread() to better match its cousin, audit_send_reply_thread(). Reported-by:
<teroincn@gmail.com> Reviewed-by:
Richard Guy Briggs <rgb@redhat.com> Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Paul Moore authored
stable inclusion from linux-4.19.129 commit 6d2f2b4218ad6af229ccefb517193094b88939ca -------------------------------- [ Upstream commit a48b284b ] If audit_send_reply() fails when trying to create a new thread to send the reply it also fails to cleanup properly, leaking a reference to a net structure. This patch fixes the error path and makes a handful of other cleanups that came up while fixing the code. Reported-by:
<teroincn@gmail.com> Reviewed-by:
Richard Guy Briggs <rgb@redhat.com> Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Serge Semin authored
stable inclusion from linux-4.19.129 commit 4d4d112dab0f7ba2b374264ec29c3d9405369fe5 -------------------------------- [ Upstream commit 46164fde ] Tx-only DMA transfers are working perfectly fine since in this case the code just ignores the Rx FIFO overflow interrupts. But it turns out the SPI Rx-only transfers are broken since nothing pushing any data to the shift registers, so the Rx FIFO is left empty and the SPI core subsystems just returns a timeout error. Since DW DMAC driver doesn't support something like cyclic write operations of a single byte to a device register, the only way to support the Rx-only SPI transfers is to fake it by using a dummy Tx-buffer. This is what we intend to fix in this commit by setting the SPI_CONTROLLER_MUST_TX flag for DMA-capable platform. Signed-off-by:
Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru> Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Feng Tang <feng.tang@intel.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: linux-mips@vger.kernel.org Cc: devicetree@vger.kernel.org Link: https://lore.kernel.org/r/20200529131205.31838-9-Sergey.Semin@baikalelectronics.ru Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Serge Semin authored
stable inclusion from linux-4.19.129 commit 655800d9203e59ae1fcd88882cb1887665d3f75f -------------------------------- [ Upstream commit 43dba9f3 ] It's pointless to track the Tx overrun interrupts if Rx-only SPI transfer is issued. Similarly there is no need in handling the Rx overrun/underrun interrupts if Tx-only SPI transfer is executed. So lets unmask the interrupts only if corresponding SPI transactions are implied. Co-developed-by:
Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru> Signed-off-by:
Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru> Signed-off-by:
Serge Semin <Sergey.Semin@baikalelectronics.ru> Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Paul Burton <paulburton@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: linux-mips@vger.kernel.org Cc: devicetree@vger.kernel.org Link: https://lore.kernel.org/r/20200522000806.7381-3-Sergey.Semin@baikalelectronics.ru Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Luke Nelson authored
stable inclusion from linux-4.19.129 commit 6d94929ed5df09303b2658b5a311db5e1a93316b -------------------------------- [ Upstream commit 579d1b3f ] This patch fixes two issues present in the current function for encoding arm64 logical immediates when using the 32-bit variants of instructions. First, the code does not correctly reject an all-ones 32-bit immediate, and returns an undefined instruction encoding. Second, the code incorrectly rejects some 32-bit immediates that are actually encodable as logical immediates. The root cause is that the code uses a default mask of 64-bit all-ones, even for 32-bit immediates. This causes an issue later on when the default mask is used to fill the top bits of the immediate with ones, shown here: /* * Pattern: 0..01..10..01..1 * * Fill the unused top bits with ones, and check if * the result is a valid immediate (all ones with a * contiguous ranges of zeroes). */ imm |= ~mask; if (!range_of_ones(~imm)) return AARCH64_BREAK_FAULT; To see the problem, consider an immediate of the form 0..01..10..01..1, where the upper 32 bits are zero, such as 0x80000001. The code checks if ~(imm | ~mask) contains a range of ones: the incorrect mask yields 1..10..01..10..0, which fails the check; the correct mask yields 0..01..10..0, which succeeds. The fix for both issues is to generate a correct mask based on the instruction immediate size, and use the mask to check for all-ones, all-zeroes, and values wider than the mask. Currently, arch/arm64/kvm/va_layout.c is the only user of this function, which uses 64-bit immediates and therefore won't trigger these bugs. We tested the new code against llvm-mc with all 1,302 encodable 32-bit logical immediates and all 5,334 encodable 64-bit logical immediates. Fixes: ef3935ee ("arm64: insn: Add encoder for bitwise operations using literals") Suggested-by:
Will Deacon <will@kernel.org> Co-developed-by:
Xi Wang <xi.wang@gmail.com> Signed-off-by:
Xi Wang <xi.wang@gmail.com> Signed-off-by:
Luke Nelson <luke.r.nels@gmail.com> Reviewed-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200508181547.24783-2-luke.r.nels@gmail.com Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Andy Shevchenko authored
stable inclusion from linux-4.19.129 commit f8f72a29018bad55b5e6f4da22e4275ba0bc461c -------------------------------- [ Upstream commit 3cb97e22 ] Some DMA controller drivers do not tolerate non-zero values in the DMA configuration structures. Zero them to avoid issues with such DMA controller drivers. Even despite above this is a good practice per se. Fixes: 7063c0d9 ("spi/dw_spi: add DMA support") Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Feng Tang <feng.tang@intel.com> Cc: Feng Tang <feng.tang@intel.com> Link: https://lore.kernel.org/r/20200506153025.21441-1-andriy.shevchenko@linux.intel.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Barret Rhoden authored
stable inclusion from linux-4.19.129 commit 28292eb6dda1ecfe1549a7e444f1c5d8c8489d92 -------------------------------- commit 2ed6edd3 upstream. Under rare circumstances, task_function_call() can repeatedly fail and cause a soft lockup. There is a slight race where the process is no longer running on the cpu we targeted by the time remote_function() runs. The code will simply try again. If we are very unlucky, this will continue to fail, until a watchdog fires. This can happen in a heavily loaded, multi-core virtual machine. Reported-by:
<syzbot+bb4935a5c09b5ff79940@syzkaller.appspotmail.com> Signed-off-by:
Barret Rhoden <brho@google.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20200414222920.121401-1-brho@google.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
王海 authored
stable inclusion from linux-4.19.129 commit 53bb2a6566fb84d2ce3d36ecd42af5cb9c34f14e -------------------------------- commit dde3c6b7 upstream. syzkaller reports for memory leak when kobject_init_and_add() returns an error in the function sysfs_slab_add() [1] When this happened, the function kobject_put() is not called for the corresponding kobject, which potentially leads to memory leak. This patch fixes the issue by calling kobject_put() even if kobject_init_and_add() fails. [1] BUG: memory leak unreferenced object 0xffff8880a6d4be88 (size 8): comm "syz-executor.3", pid 946, jiffies 4295772514 (age 18.396s) hex dump (first 8 bytes): 70 69 64 5f 33 00 ff ff pid_3... backtrace: kstrdup+0x35/0x70 mm/util.c:60 kstrdup_const+0x3d/0x50 mm/util.c:82 kvasprintf_const+0x112/0x170 lib/kasprintf.c:48 kobject_set_name_vargs+0x55/0x130 lib/kobject.c:289 kobject_add_varg lib/kobject.c:384 [inline] kobject_init_and_add+0xd8/0x170 lib/kobject.c:473 sysfs_slab_add+0x1d8/0x290 mm/slub.c:5811 __kmem_cache_create+0x50a/0x570 mm/slub.c:4384 create_cache+0x113/0x1e0 mm/slab_common.c:407 kmem_cache_create_usercopy+0x1a1/0x260 mm/slab_common.c:505 kmem_cache_create+0xd/0x10 mm/slab_common.c:564 create_pid_cachep kernel/pid_namespace.c:54 [inline] create_pid_namespace kernel/pid_namespace.c:96 [inline] copy_pid_ns+0x77c/0x8f0 kernel/pid_namespace.c:148 create_new_namespaces+0x26b/0xa30 kernel/nsproxy.c:95 unshare_nsproxy_namespaces+0xa7/0x1e0 kernel/nsproxy.c:229 ksys_unshare+0x3d2/0x770 kernel/fork.c:2969 __do_sys_unshare kernel/fork.c:3037 [inline] __se_sys_unshare kernel/fork.c:3035 [inline] __x64_sys_unshare+0x2d/0x40 kernel/fork.c:3035 do_syscall_64+0xa1/0x530 arch/x86/entry/common.c:295 Fixes: 80da026a ("mm/slub: fix slab double-free in case of duplicate sysfs filename") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wang Hai <wanghai38@huawei.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Cc: Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Link: http://lkml.kernel.org/r/20200602115033.1054-1-wanghai38@huawei.com Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Eric W. Biederman authored
stable inclusion from linux-4.19.129 commit de13aebcf5a812fc9bd70fac7dd7a47bbf9cc3ef -------------------------------- commit ef1548ad upstream. Recently syzbot reported that unmounting proc when there is an ongoing inotify watch on the root directory of proc could result in a use after free when the watch is removed after the unmount of proc when the watcher exits. Commit 69879c01 ("proc: Remove the now unnecessary internal mount of proc") made it easier to unmount proc and allowed syzbot to see the problem, but looking at the code it has been around for a long time. Looking at the code the fsnotify watch should have been removed by fsnotify_sb_delete in generic_shutdown_super. Unfortunately the inode was allocated with new_inode_pseudo instead of new_inode so the inode was not on the sb->s_inodes list. Which prevented fsnotify_unmount_inodes from finding the inode and removing the watch as well as made it so the "VFS: Busy inodes after unmount" warning could not find the inodes to warn about them. Make all of the inodes in proc visible to generic_shutdown_super, and fsnotify_sb_delete by using new_inode instead of new_inode_pseudo. The only functional difference is that new_inode places the inodes on the sb->s_inodes list. I wrote a small test program and I can verify that without changes it can trigger this issue, and by replacing new_inode_pseudo with new_inode the issues goes away. Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/000000000000d788c905a7dfa3f4@google.com Reported-by:
<syzbot+7d2debdcdb3cb93c1e5e@syzkaller.appspotmail.com> Fixes: 0097875b ("proc: Implement /proc/thread-self to point at the directory of the current thread") Fixes: 021ada7d ("procfs: switch /proc/self away from proc_dir_entry") Fixes: 51f0885e ("vfs,proc: guarantee unique inodes in /proc") Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Yuxuan Shui authored
stable inclusion from linux-4.19.129 commit cab0f4ae8b6f07eedda6f2ccaa8eec345f8040cc -------------------------------- commit 520da69d upstream. In ovl_copy_xattr, if all the xattrs to be copied are overlayfs private xattrs, the copy loop will terminate without assigning anything to the error variable, thus returning an uninitialized value. If ovl_copy_xattr is called from ovl_clear_empty, this uninitialized error value is put into a pointer by ERR_PTR(), causing potential invalid memory accesses down the line. This commit initialize error with 0. This is the correct value because when there's no xattr to copy, because all xattrs are private, ovl_copy_xattr should succeed. This bug is discovered with the help of INIT_STACK_ALL and clang. Signed-off-by:
Yuxuan Shui <yshuiv7@gmail.com> Link: https://bugs.chromium.org/p/chromium/issues/detail?id=1050405 Fixes: 0956254a ("ovl: don't copy up opaqueness") Cc: stable@vger.kernel.org # v4.8 Signed-off-by:
Alexander Potapenko <glider@google.com> Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Lukas Wunner authored
stable inclusion from linux-4.19.129 commit 675efd2778ce532d9492617d564426434c8be02c -------------------------------- [ Upstream commit 84855678 ] When an SPI controller unregisters, it unbinds all its slave devices. For this, their drivers may need to access the SPI bus, e.g. to quiesce interrupts. However since commit ffbbdd21 ("spi: create a message queueing infrastructure"), spi_destroy_queue() is executed before unbinding the slaves. It sets ctlr->running = false, thereby preventing SPI bus access and causing unbinding of slave devices to fail. Fix by unbinding slaves before calling spi_destroy_queue(). Fixes: ffbbdd21 ("spi: create a message queueing infrastructure") Signed-off-by:
Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org # v3.4+ Cc: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/8aaf9d44c153fe233b17bc2dec4eb679898d7e7b.1589557526.git.lukas@wunner.de Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Andy Shevchenko authored
stable inclusion from linux-4.19.129 commit 03a381292891560d7347a0a0ee4f6875bf8065a5 -------------------------------- [ Upstream commit ebc37af5 ] The device_for_each_child() doesn't require the returned value to be checked. Thus, drop the dummy variable completely and have no warning anymore: drivers/spi/spi.c: In function ‘spi_unregister_controller’: drivers/spi/spi.c:2480:6: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable] int dummy; ^~~~~ Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Lukas Wunner authored
stable inclusion from linux-4.19.129 commit 21d018ef732c7bf0c98941b1b0f67f3915b93afe -------------------------------- commit ca8b19d6 upstream. The Designware SPI driver uses devm_spi_register_controller() on bind. As a consequence, on unbind, __device_release_driver() first invokes dw_spi_remove_host() before unregistering the SPI controller via devres_release_all(). This order is incorrect: dw_spi_remove_host() shuts down the chip, rendering the SPI bus inaccessible even though the SPI controller is still registered. When the SPI controller is subsequently unregistered, it unbinds all its slave devices. Because their drivers cannot access the SPI bus, e.g. to quiesce interrupts, the slave devices may be left in an improper state. As a rule, devm_spi_register_controller() must not be used if the ->remove() hook performs teardown steps which shall be performed after unregistering the controller and specifically after unbinding of slaves. Fix by reverting to the non-devm variant of spi_register_controller(). An alternative approach would be to use device-managed functions for all steps in dw_spi_remove_host(), e.g. by calling devm_add_action_or_reset() on probe. However that approach would add more LoC to the driver and it wouldn't lend itself as well to backporting to stable. Fixes: 04f421e7 ("spi: dw: use managed resources") Signed-off-by:
Lukas Wunner <lukas@wunner.de> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: stable@vger.kernel.org # v3.14+ Cc: Baruch Siach <baruch@tkos.co.il> Link: https://lore.kernel.org/r/3fff8cb8ae44a9893840d0688be15bb88c090a14.1590408496.git.lukas@wunner.de Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Qiushi Wu authored
stable inclusion from linux-4.19.129 commit c1348a561d567bb1edcded41f720d6c8a178f96d -------------------------------- commit 4d8be4bc upstream. kobject_init_and_add() takes reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Previous commit "b8eb7183" fixed a similar problem. Fixes: 158c998e ("ACPI / CPPC: add sysfs support to compute delivered performance") Signed-off-by:
Qiushi Wu <wu000273@umn.edu> Cc: 4.10+ <stable@vger.kernel.org> # 4.10+ Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-
Qiushi Wu authored
stable inclusion from linux-4.19.129 commit efb4903f931a5955ee34fd1be89efa601b761961 -------------------------------- commit 6e6c2528 upstream. kobject_init_and_add() takes reference even when it fails. Thus, when kobject_init_and_add() returns an error, kobject_put() must be called to properly clean up the kobject. Fixes: 3f8055c3 ("ACPI / hotplug: Introduce user space interface for hotplug profiles") Signed-off-by:
Qiushi Wu <wu000273@umn.edu> Cc: 3.10+ <stable@vger.kernel.org> # 3.10+ Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
-