Wei Yongjun [Mon, 13 Jul 2020 15:59:50 +0000 (23:59 +0800)]
ip6_gre: fix null-ptr-deref in ip6gre_init_net()
[ Upstream commit
46ef5b89ec0ecf290d74c4aee844f063933c4da4 ]
KASAN report null-ptr-deref error when register_netdev() failed:
KASAN: null-ptr-deref in range [0x00000000000003c0-0x00000000000003c7]
CPU: 2 PID: 422 Comm: ip Not tainted 5.8.0-rc4+ #12
Call Trace:
ip6gre_init_net+0x4ab/0x580
? ip6gre_tunnel_uninit+0x3f0/0x3f0
ops_init+0xa8/0x3c0
setup_net+0x2de/0x7e0
? rcu_read_lock_bh_held+0xb0/0xb0
? ops_init+0x3c0/0x3c0
? kasan_unpoison_shadow+0x33/0x40
? __kasan_kmalloc.constprop.0+0xc2/0xd0
copy_net_ns+0x27d/0x530
create_new_namespaces+0x382/0xa30
unshare_nsproxy_namespaces+0xa1/0x1d0
ksys_unshare+0x39c/0x780
? walk_process_tree+0x2a0/0x2a0
? trace_hardirqs_on+0x4a/0x1b0
? _raw_spin_unlock_irq+0x1f/0x30
? syscall_trace_enter+0x1a7/0x330
? do_syscall_64+0x1c/0xa0
__x64_sys_unshare+0x2d/0x40
do_syscall_64+0x56/0xa0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
ip6gre_tunnel_uninit() has set 'ign->fb_tunnel_dev' to NULL, later
access to ign->fb_tunnel_dev cause null-ptr-deref. Fix it by saving
'ign->fb_tunnel_dev' to local variable ndev.
Fixes:
dafabb6590cb ("ip6_gre: fix use-after-free in ip6gre_tunnel_lookup()")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yuchung Cheng [Thu, 23 Jul 2020 19:00:06 +0000 (12:00 -0700)]
tcp: allow at most one TLP probe per flight
[ Upstream commit
76be93fc0702322179bb0ea87295d820ee46ad14 ]
Previously TLP may send multiple probes of new data in one
flight. This happens when the sender is cwnd limited. After the
initial TLP containing new data is sent, the sender receives another
ACK that acks partial inflight. It may re-arm another TLP timer
to send more, if no further ACK returns before the next TLP timeout
(PTO) expires. The sender may send in theory a large amount of TLP
until send queue is depleted. This only happens if the sender sees
such irregular uncommon ACK pattern. But it is generally undesirable
behavior during congestion especially.
The original TLP design restrict only one TLP probe per inflight as
published in "Reducing Web Latency: the Virtue of Gentle Aggression",
SIGCOMM 2013. This patch changes TLP to send at most one probe
per inflight.
Note that if the sender is app-limited, TLP retransmits old data
and did not have this issue.
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Thu, 23 Jul 2020 14:49:57 +0000 (17:49 +0300)]
AX.25: Prevent integer overflows in connect and sendmsg
[ Upstream commit
17ad73e941b71f3bec7523ea4e9cbc3752461c2d ]
We recently added some bounds checking in ax25_connect() and
ax25_sendmsg() and we so we removed the AX25_MAX_DIGIS checks because
they were no longer required.
Unfortunately, I believe they are required to prevent integer overflows
so I have added them back.
Fixes:
8885bb0621f0 ("AX.25: Prevent out-of-bounds read in ax25_sendmsg()")
Fixes:
2f2a7ffad5c6 ("AX.25: Fix out-of-bounds read in ax25_connect()")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Howells [Mon, 20 Jul 2020 11:41:46 +0000 (12:41 +0100)]
rxrpc: Fix sendmsg() returning EPIPE due to recvmsg() returning ENODATA
[ Upstream commit
639f181f0ee20d3249dbc55f740f0167267180f0 ]
rxrpc_sendmsg() returns EPIPE if there's an outstanding error, such as if
rxrpc_recvmsg() indicating ENODATA if there's nothing for it to read.
Change rxrpc_recvmsg() to return EAGAIN instead if there's nothing to read
as this particular error doesn't get stored in ->sk_err by the networking
core.
Also change rxrpc_sendmsg() so that it doesn't fail with delayed receive
errors (there's no way for it to report which call, if any, the error was
caused by).
Fixes:
17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both")
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Miaohe Lin [Tue, 21 Jul 2020 09:11:44 +0000 (17:11 +0800)]
net: udp: Fix wrong clean up for IS_UDPLITE macro
[ Upstream commit
b0a422772fec29811e293c7c0e6f991c0fd9241d ]
We can't use IS_UDPLITE to replace udp_sk->pcflag when UDPLITE_RECV_CC is
checked.
Fixes:
b2bf1e2659b1 ("[UDP]: Clean up for IS_UDPLITE macro")
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xiongfeng Wang [Tue, 21 Jul 2020 07:02:57 +0000 (15:02 +0800)]
net-sysfs: add a newline when printing 'tx_timeout' by sysfs
[ Upstream commit
9bb5fbea59f36a589ef886292549ca4052fe676c ]
When I cat 'tx_timeout' by sysfs, it displays as follows. It's better to
add a newline for easy reading.
root@syzkaller:~# cat /sys/devices/virtual/net/lo/queues/tx-0/tx_timeout
0root@syzkaller:~#
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subash Abhinov Kasiviswanathan [Thu, 23 Jul 2020 17:31:48 +0000 (11:31 -0600)]
dev: Defer free of skbs in flush_backlog
[ Upstream commit
7df5cb75cfb8acf96c7f2342530eb41e0c11f4c3 ]
IRQs are disabled when freeing skbs in input queue.
Use the IRQ safe variant to free skbs here.
Fixes:
145dd5f9c88f ("net: flush the softnet backlog in process context")
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peilin Ye [Wed, 22 Jul 2020 16:05:12 +0000 (12:05 -0400)]
AX.25: Prevent out-of-bounds read in ax25_sendmsg()
[ Upstream commit
8885bb0621f01a6c82be60a91e5fc0f6e2f71186 ]
Checks on `addr_len` and `usax->sax25_ndigis` are insufficient.
ax25_sendmsg() can go out of bounds when `usax->sax25_ndigis` equals to 7
or 8. Fix it.
It is safe to remove `usax->sax25_ndigis > AX25_MAX_DIGIS`, since
`addr_len` is guaranteed to be less than or equal to
`sizeof(struct full_sockaddr_ax25)`
Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peilin Ye [Wed, 22 Jul 2020 15:19:01 +0000 (11:19 -0400)]
AX.25: Fix out-of-bounds read in ax25_connect()
[ Upstream commit
2f2a7ffad5c6cbf3d438e813cfdc88230e185ba6 ]
Checks on `addr_len` and `fsa->fsa_ax25.sax25_ndigis` are insufficient.
ax25_connect() can go out of bounds when `fsa->fsa_ax25.sax25_ndigis`
equals to 7 or 8. Fix it.
This issue has been reported as a KMSAN uninit-value bug, because in such
a case, ax25_connect() reaches into the uninitialized portion of the
`struct sockaddr_storage` statically allocated in __sys_connect().
It is safe to remove `fsa->fsa_ax25.sax25_ndigis > AX25_MAX_DIGIS` because
`addr_len` is guaranteed to be less than or equal to
`sizeof(struct full_sockaddr_ax25)`.
Reported-by: syzbot+c82752228ed975b0a623@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=55ef9d629f3b3d7d70b69558015b63b48d01af66
Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark O'Donovan [Sat, 11 Jul 2020 04:33:24 +0000 (05:33 +0100)]
ath9k: Fix regression with Atheros 9271
commit
92f53e2fda8bb9a559ad61d57bfb397ce67ed0ab upstream.
This fix allows ath9k_htc modules to connect to WLAN once again.
Fixes:
2bbcaaee1fcb ("ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=208251
Signed-off-by: Mark O'Donovan <shiftee@posteo.net>
Reported-by: Roman Mamedov <rm@romanrm.net>
Tested-by: Viktor Jägersküpper <viktor_jaegerskuepper@freenet.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200711043324.8079-1-shiftee@posteo.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Qiujun Huang [Sat, 4 Apr 2020 04:18:38 +0000 (12:18 +0800)]
ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb
commit
2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05 upstream.
In ath9k_hif_usb_rx_cb interface number is assumed to be 0.
usb_ifnum_to_if(urb->dev, 0)
But it isn't always true.
The case reported by syzbot:
https://lore.kernel.org/linux-usb/
000000000000666c9c05a1c05d12@google.com
usb 2-1: new high-speed USB device number 2 using dummy_hcd
usb 2-1: config 1 has an invalid interface number: 2 but max is 0
usb 2-1: config 1 has no interface number 0
usb 2-1: New USB device found, idVendor=0cf3, idProduct=9271, bcdDevice=
1.08
usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
general protection fault, probably for non-canonical address
0xdffffc0000000015: 0000 [#1] SMP KASAN
KASAN: null-ptr-deref in range [0x00000000000000a8-0x00000000000000af]
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.0-rc5-syzkaller #0
Call Trace
__usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650
usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716
dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966
call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404
expire_timers kernel/time/timer.c:1449 [inline]
__run_timers kernel/time/timer.c:1773 [inline]
__run_timers kernel/time/timer.c:1740 [inline]
run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786
__do_softirq+0x21e/0x950 kernel/softirq.c:292
invoke_softirq kernel/softirq.c:373 [inline]
irq_exit+0x178/0x1a0 kernel/softirq.c:413
exiting_irq arch/x86/include/asm/apic.h:546 [inline]
smp_apic_timer_interrupt+0x141/0x540 arch/x86/kernel/apic/apic.c:1146
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
Reported-and-tested-by: syzbot+40d5d2e8a4680952f042@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang <hqjagain@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200404041838.10426-6-hqjagain@gmail.com
Cc: Viktor Jägersküpper <viktor_jaegerskuepper@freenet.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
John David Anglin [Tue, 21 Jul 2020 11:36:59 +0000 (07:36 -0400)]
parisc: Add atomic64_set_release() define to avoid CPU soft lockups
commit
be6577af0cef934ccb036445314072e8cb9217b9 upstream.
Stalls are quite frequent with recent kernels. I enabled
CONFIG_SOFTLOCKUP_DETECTOR and I caught the following stall:
watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [cc1:22803]
CPU: 0 PID: 22803 Comm: cc1 Not tainted 5.6.17+ #3
Hardware name: 9000/800/rp3440
IAOQ[0]: d_alloc_parallel+0x384/0x688
IAOQ[1]: d_alloc_parallel+0x388/0x688
RP(r2): d_alloc_parallel+0x134/0x688
Backtrace:
[<
000000004036974c>] __lookup_slow+0xa4/0x200
[<
0000000040369fc8>] walk_component+0x288/0x458
[<
000000004036a9a0>] path_lookupat+0x88/0x198
[<
000000004036e748>] filename_lookup+0xa0/0x168
[<
000000004036e95c>] user_path_at_empty+0x64/0x80
[<
000000004035d93c>] vfs_statx+0x104/0x158
[<
000000004035dfcc>] __do_sys_lstat64+0x44/0x80
[<
000000004035e5a0>] sys_lstat64+0x20/0x38
[<
0000000040180054>] syscall_exit+0x0/0x14
The code was stuck in this loop in d_alloc_parallel:
4037d414: 0e 00 10 dc ldd 0(r16),ret0
4037d418: c7 fc 5f ed bb,< ret0,1f,
4037d414 <d_alloc_parallel+0x384>
4037d41c: 08 00 02 40 nop
This is the inner loop of bit_spin_lock which is called by hlist_bl_unlock in
d_alloc_parallel:
static inline void bit_spin_lock(int bitnum, unsigned long *addr)
{
/*
* Assuming the lock is uncontended, this never enters
* the body of the outer loop. If it is contended, then
* within the inner loop a non-atomic test is used to
* busywait with less bus contention for a good time to
* attempt to acquire the lock bit.
*/
preempt_disable();
#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK)
while (unlikely(test_and_set_bit_lock(bitnum, addr))) {
preempt_enable();
do {
cpu_relax();
} while (test_bit(bitnum, addr));
preempt_disable();
}
#endif
__acquire(bitlock);
}
After consideration, I realized that we must be losing bit unlocks.
Then, I noticed that we missed defining atomic64_set_release().
Adding this define fixes the stalls in bit operations.
Signed-off-by: Dave Anglin <dave.anglin@bell.net>
Cc: stable@vger.kernel.org
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael J. Ruhl [Fri, 24 Jul 2020 04:15:46 +0000 (21:15 -0700)]
io-mapping: indicate mapping failure
commit
e0b3e0b1a04367fc15c07f44e78361545b55357c upstream.
The !ATOMIC_IOMAP version of io_maping_init_wc will always return
success, even when the ioremap fails.
Since the ATOMIC_IOMAP version returns NULL when the init fails, and
callers check for a NULL return on error this is unexpected.
During a device probe, where the ioremap failed, a crash can look like
this:
BUG: unable to handle page fault for address:
0000000000210000
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
Oops: 0002 [#1] PREEMPT SMP
CPU: 0 PID: 177 Comm:
RIP: 0010:fill_page_dma [i915]
gen8_ppgtt_create [i915]
i915_ppgtt_create [i915]
intel_gt_init [i915]
i915_gem_init [i915]
i915_driver_probe [i915]
pci_device_probe
really_probe
driver_probe_device
The remap failure occurred much earlier in the probe. If it had been
propagated, the driver would have exited with an error.
Return NULL on ioremap failure.
[akpm@linux-foundation.org: detect ioremap_wc() errors earlier]
Fixes:
cafaf14a5d8f ("io-mapping: Always create a struct to hold metadata about the io-mapping")
Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/20200721171936.81563-1-michael.j.ruhl@intel.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hugh Dickins [Fri, 24 Jul 2020 04:15:24 +0000 (21:15 -0700)]
mm/memcg: fix refcount error while moving and swapping
commit
8d22a9351035ef2ff12ef163a1091b8b8cf1e49c upstream.
It was hard to keep a test running, moving tasks between memcgs with
move_charge_at_immigrate, while swapping: mem_cgroup_id_get_many()'s
refcount is discovered to be 0 (supposedly impossible), so it is then
forced to REFCOUNT_SATURATED, and after thousands of warnings in quick
succession, the test is at last put out of misery by being OOM killed.
This is because of the way moved_swap accounting was saved up until the
task move gets completed in __mem_cgroup_clear_mc(), deferred from when
mem_cgroup_move_swap_account() actually exchanged old and new ids.
Concurrent activity can free up swap quicker than the task is scanned,
bringing id refcount down 0 (which should only be possible when
offlining).
Just skip that optimization: do that part of the accounting immediately.
Fixes:
615d66c37c75 ("mm: memcontrol: fix memcg id ref counter on swap charge move")
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Alex Shi <alex.shi@linux.alibaba.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Alex Shi <alex.shi@linux.alibaba.com>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/alpine.LSU.2.11.2007071431050.4726@eggly.anvils
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fangrui Song [Tue, 21 Jul 2020 17:31:23 +0000 (10:31 -0700)]
Makefile: Fix GCC_TOOLCHAIN_DIR prefix for Clang cross compilation
commit
ca9b31f6bb9c6aa9b4e5f0792f39a97bbffb8c51 upstream.
When CROSS_COMPILE is set (e.g. aarch64-linux-gnu-), if
$(CROSS_COMPILE)elfedit is found at /usr/bin/aarch64-linux-gnu-elfedit,
GCC_TOOLCHAIN_DIR will be set to /usr/bin/. --prefix= will be set to
/usr/bin/ and Clang as of 11 will search for both
$(prefix)aarch64-linux-gnu-$needle and $(prefix)$needle.
GCC searchs for $(prefix)aarch64-linux-gnu/$version/$needle,
$(prefix)aarch64-linux-gnu/$needle and $(prefix)$needle. In practice,
$(prefix)aarch64-linux-gnu/$needle rarely contains executables.
To better model how GCC's -B/--prefix takes in effect in practice, newer
Clang (since
https://github.com/llvm/llvm-project/commit/
3452a0d8c17f7166f479706b293caf6ac76ffd90)
only searches for $(prefix)$needle. Currently it will find /usr/bin/as
instead of /usr/bin/aarch64-linux-gnu-as.
Set --prefix= to $(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE))
(/usr/bin/aarch64-linux-gnu-) so that newer Clang can find the
appropriate cross compiling GNU as (when -no-integrated-as is in
effect).
Cc: stable@vger.kernel.org
Reported-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Fangrui Song <maskray@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Link: https://github.com/ClangBuiltLinux/linux/issues/1099
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tetsuo Handa [Sun, 12 Jul 2020 11:10:12 +0000 (20:10 +0900)]
vt: Reject zero-sized screen buffer size.
commit
ce684552a266cb1c7cc2f7e623f38567adec6653 upstream.
syzbot is reporting general protection fault in do_con_write() [1] caused
by vc->vc_screenbuf == ZERO_SIZE_PTR caused by vc->vc_screenbuf_size == 0
caused by vc->vc_cols == vc->vc_rows == vc->vc_size_row == 0 caused by
fb_set_var() from ioctl(FBIOPUT_VSCREENINFO) on /dev/fb0 , for
gotoxy(vc, 0, 0) from reset_terminal() from vc_init() from vc_allocate()
from con_install() from tty_init_dev() from tty_open() on such console
causes vc->vc_pos == 0x10000000e due to
((unsigned long) ZERO_SIZE_PTR) + -1U * 0 + (-1U << 1).
I don't think that a console with 0 column or 0 row makes sense. And it
seems that vc_do_resize() does not intend to allow resizing a console to
0 column or 0 row due to
new_cols = (cols ? cols : vc->vc_cols);
new_rows = (lines ? lines : vc->vc_rows);
exception.
Theoretically, cols and rows can be any range as long as
0 < cols * rows * 2 <= KMALLOC_MAX_SIZE is satisfied (e.g.
cols == 1048576 && rows == 2 is possible) because of
vc->vc_size_row = vc->vc_cols << 1;
vc->vc_screenbuf_size = vc->vc_rows * vc->vc_size_row;
in visual_init() and kzalloc(vc->vc_screenbuf_size) in vc_allocate().
Since we can detect cols == 0 or rows == 0 via screenbuf_size = 0 in
visual_init(), we can reject kzalloc(0). Then, vc_allocate() will return
an error, and con_write() will not be called on a console with 0 column
or 0 row.
We need to make sure that integer overflow in visual_init() won't happen.
Since vc_do_resize() restricts cols <= 32767 and rows <= 32767, applying
1 <= cols <= 32767 and 1 <= rows <= 32767 restrictions to vc_allocate()
will be practically fine.
This patch does not touch con_init(), for returning -EINVAL there
does not help when we are not returning -ENOMEM.
[1] https://syzkaller.appspot.com/bug?extid=
017265e8553724e514e8
Reported-and-tested-by: syzbot <syzbot+017265e8553724e514e8@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200712111013.11881-1-penguin-kernel@I-love.SAKURA.ne.jp
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Serge Semin [Tue, 14 Jul 2020 12:41:12 +0000 (15:41 +0300)]
serial: 8250_mtk: Fix high-speed baud rates clamping
commit
551e553f0d4ab623e2a6f424ab5834f9c7b5229c upstream.
Commit
7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250
port") fixed limits of a baud rate setting for a generic 8250 port.
In other words since that commit the baud rate has been permitted to be
within [uartclk / 16 / UART_DIV_MAX; uartclk / 16], which is absolutely
normal for a standard 8250 UART port. But there are custom 8250 ports,
which provide extended baud rate limits. In particular the Mediatek 8250
port can work with baud rates up to "uartclk" speed.
Normally that and any other peculiarity is supposed to be handled in a
custom set_termios() callback implemented in the vendor-specific
8250-port glue-driver. Currently that is how it's done for the most of
the vendor-specific 8250 ports, but for some reason for Mediatek a
solution has been spread out to both the glue-driver and to the generic
8250-port code. Due to that a bug has been introduced, which permitted the
extended baud rate limit for all even for standard 8250-ports. The bug
has been fixed by the commit
7b668c064ec3 ("serial: 8250: Fix max baud
limit in generic 8250 port") by narrowing the baud rates limit back down to
the normal bounds. Unfortunately by doing so we also broke the
Mediatek-specific extended bauds feature.
A fix of the problem described above is twofold. First since we can't get
back the extended baud rate limits feature to the generic set_termios()
function and that method supports only a standard baud rates range, the
requested baud rate must be locally stored before calling it and then
restored back to the new termios structure after the generic set_termios()
finished its magic business. By doing so we still use the
serial8250_do_set_termios() method to set the LCR/MCR/FCR/etc. registers,
while the extended baud rate setting procedure will be performed later in
the custom Mediatek-specific set_termios() callback. Second since a true
baud rate is now fully calculated in the custom set_termios() method we
need to locally update the port timeout by calling the
uart_update_timeout() function. After the fixes described above are
implemented in the 8250_mtk.c driver, the Mediatek 8250-port should
get back to normally working with extended baud rates.
Link: https://lore.kernel.org/linux-serial/20200701211337.3027448-1-danielwinkler@google.com
Fixes:
7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250 port")
Reported-by: Daniel Winkler <danielwinkler@google.com>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: stable <stable@vger.kernel.org>
Tested-by: Claire Chang <tientzu@chromium.org>
Link: https://lore.kernel.org/r/20200714124113.20918-1-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yang Yingliang [Tue, 21 Jul 2020 14:38:52 +0000 (14:38 +0000)]
serial: 8250: fix null-ptr-deref in serial8250_start_tx()
commit
f4c23a140d80ef5e6d3d1f8f57007649014b60fa upstream.
I got null-ptr-deref in serial8250_start_tx():
[ 78.114630] Unable to handle kernel NULL pointer dereference at virtual address
0000000000000000
[ 78.123778] Mem abort info:
[ 78.126560] ESR = 0x86000007
[ 78.129603] EC = 0x21: IABT (current EL), IL = 32 bits
[ 78.134891] SET = 0, FnV = 0
[ 78.137933] EA = 0, S1PTW = 0
[ 78.141064] user pgtable: 64k pages, 48-bit VAs, pgdp=
00000027d41a8600
[ 78.147562] [
0000000000000000] pgd=
00000027893f0003, p4d=
00000027893f0003, pud=
00000027893f0003, pmd=
00000027c9a20003, pte=
0000000000000000
[ 78.160029] Internal error: Oops:
86000007 [#1] SMP
[ 78.164886] Modules linked in: sunrpc vfat fat aes_ce_blk crypto_simd cryptd aes_ce_cipher crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce ses enclosure sg sbsa_gwdt ipmi_ssif spi_dw_mmio sch_fq_codel vhost_net tun vhost vhost_iotlb tap ip_tables ext4 mbcache jbd2 ahci hisi_sas_v3_hw libahci hisi_sas_main libsas hns3 scsi_transport_sas hclge libata megaraid_sas ipmi_si hnae3 ipmi_devintf ipmi_msghandler br_netfilter bridge stp llc nvme nvme_core xt_sctp sctp libcrc32c dm_mod nbd
[ 78.207383] CPU: 11 PID: 23258 Comm: null-ptr Not tainted 5.8.0-rc6+ #48
[ 78.214056] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B210.01 03/12/2020
[ 78.222888] pstate:
80400089 (Nzcv daIf +PAN -UAO BTYPE=--)
[ 78.228435] pc : 0x0
[ 78.230618] lr : serial8250_start_tx+0x160/0x260
[ 78.235215] sp :
ffff800062eefb80
[ 78.238517] x29:
ffff800062eefb80 x28:
0000000000000fff
[ 78.243807] x27:
ffff800062eefd80 x26:
ffff202fd83b3000
[ 78.249098] x25:
ffff800062eefd80 x24:
ffff202fd83b3000
[ 78.254388] x23:
ffff002fc5e50be8 x22:
0000000000000002
[ 78.259679] x21:
0000000000000001 x20:
0000000000000000
[ 78.264969] x19:
ffffa688827eecc8 x18:
0000000000000000
[ 78.270259] x17:
0000000000000000 x16:
0000000000000000
[ 78.275550] x15:
ffffa68881bc67a8 x14:
00000000000002e6
[ 78.280841] x13:
ffffa68881bc67a8 x12:
000000000000c539
[ 78.286131] x11:
d37a6f4de9bd37a7 x10:
ffffa68881cccff0
[ 78.291421] x9 :
ffffa68881bc6000 x8 :
ffffa688819daa88
[ 78.296711] x7 :
ffffa688822a0f20 x6 :
ffffa688819e0000
[ 78.302002] x5 :
ffff800062eef9d0 x4 :
ffffa68881e707a8
[ 78.307292] x3 :
0000000000000000 x2 :
0000000000000002
[ 78.312582] x1 :
0000000000000001 x0 :
ffffa688827eecc8
[ 78.317873] Call trace:
[ 78.320312] 0x0
[ 78.322147] __uart_start.isra.9+0x64/0x78
[ 78.326229] uart_start+0xb8/0x1c8
[ 78.329620] uart_flush_chars+0x24/0x30
[ 78.333442] n_tty_receive_buf_common+0x7b0/0xc30
[ 78.338128] n_tty_receive_buf+0x44/0x2c8
[ 78.342122] tty_ioctl+0x348/0x11f8
[ 78.345599] ksys_ioctl+0xd8/0xf8
[ 78.348903] __arm64_sys_ioctl+0x2c/0xc8
[ 78.352812] el0_svc_common.constprop.2+0x88/0x1b0
[ 78.357583] do_el0_svc+0x44/0xd0
[ 78.360887] el0_sync_handler+0x14c/0x1d0
[ 78.364880] el0_sync+0x140/0x180
[ 78.368185] Code: bad PC value
SERIAL_PORT_DFNS is not defined on each arch, if it's not defined,
serial8250_set_defaults() won't be called in serial8250_isa_init_ports(),
so the p->serial_in pointer won't be initialized, and it leads a null-ptr-deref.
Fix this problem by calling serial8250_set_defaults() after init uart port.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200721143852.4058352-1-yangyingliang@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Fri, 17 Jul 2020 14:52:56 +0000 (15:52 +0100)]
staging: comedi: addi_apci_1564: check INSN_CONFIG_DIGITAL_TRIG shift
commit
926234f1b8434c4409aa4c53637aa3362ca07cea upstream.
The `INSN_CONFIG` comedi instruction with sub-instruction code
`INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is
used as a right shift amount for other bitmask values without being
checked. Shift amounts greater than or equal to 32 will result in
undefined behavior. Add code to deal with this.
Fixes:
1e15687ea472 ("staging: comedi: addi_apci_1564: add Change-of-State interrupt subdevice and required functions")
Cc: <stable@vger.kernel.org> #3.17+
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://lore.kernel.org/r/20200717145257.112660-4-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Fri, 17 Jul 2020 14:52:57 +0000 (15:52 +0100)]
staging: comedi: addi_apci_1500: check INSN_CONFIG_DIGITAL_TRIG shift
commit
fc846e9db67c7e808d77bf9e2ef3d49e3820ce5d upstream.
The `INSN_CONFIG` comedi instruction with sub-instruction code
`INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is
used as a right shift amount for other bitmask values without being
checked. Shift amounts greater than or equal to 32 will result in
undefined behavior. Add code to deal with this, adjusting the checks
for invalid channels so that enabled channel bits that would have been
lost by shifting are also checked for validity. Only channels 0 to 15
are valid.
Fixes:
a8c66b684efaf ("staging: comedi: addi_apci_1500: rewrite the subdevice support functions")
Cc: <stable@vger.kernel.org> #4.0+: ef75e14a6c93: staging: comedi: verify array index is correct before using it
Cc: <stable@vger.kernel.org> #4.0+
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://lore.kernel.org/r/20200717145257.112660-5-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Fri, 17 Jul 2020 14:52:54 +0000 (15:52 +0100)]
staging: comedi: ni_6527: fix INSN_CONFIG_DIGITAL_TRIG support
commit
f07804ec77d77f8a9dcf570a24154e17747bc82f upstream.
`ni6527_intr_insn_config()` processes `INSN_CONFIG` comedi instructions
for the "interrupt" subdevice. When `data[0]` is
`INSN_CONFIG_DIGITAL_TRIG` it is configuring the digital trigger. When
`data[2]` is `COMEDI_DIGITAL_TRIG_ENABLE_EDGES` it is configuring rising
and falling edge detection for the digital trigger, using a base channel
number (or shift amount) in `data[3]`, a rising edge bitmask in
`data[4]` and falling edge bitmask in `data[5]`.
If the base channel number (shift amount) is greater than or equal to
the number of channels (24) of the digital input subdevice, there are no
changes to the rising and falling edges, so the mask of channels to be
changed can be set to 0, otherwise the mask of channels to be changed,
and the rising and falling edge bitmasks are shifted by the base channel
number before calling `ni6527_set_edge_detection()` to change the
appropriate registers. Unfortunately, the code is comparing the base
channel (shift amount) to the interrupt subdevice's number of channels
(1) instead of the digital input subdevice's number of channels (24).
Fix it by comparing to 32 because all shift amounts for an `unsigned
int` must be less than that and everything from bit 24 upwards is
ignored by `ni6527_set_edge_detection()` anyway.
Fixes:
110f9e687c1a8 ("staging: comedi: ni_6527: support INSN_CONFIG_DIGITAL_TRIG")
Cc: <stable@vger.kernel.org> # 3.17+
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://lore.kernel.org/r/20200717145257.112660-2-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Fri, 17 Jul 2020 14:52:55 +0000 (15:52 +0100)]
staging: comedi: addi_apci_1032: check INSN_CONFIG_DIGITAL_TRIG shift
commit
0bd0db42a030b75c20028c7ba6e327b9cb554116 upstream.
The `INSN_CONFIG` comedi instruction with sub-instruction code
`INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is
used as a right shift amount for other bitmask values without being
checked. Shift amounts greater than or equal to 32 will result in
undefined behavior. Add code to deal with this.
Fixes:
33cdce6293dcc ("staging: comedi: addi_apci_1032: conform to new INSN_CONFIG_DIGITAL_TRIG")
Cc: <stable@vger.kernel.org> #3.8+
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://lore.kernel.org/r/20200717145257.112660-3-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rustam Kovhaev [Wed, 22 Jul 2020 16:10:52 +0000 (09:10 -0700)]
staging: wlan-ng: properly check endpoint types
commit
faaff9765664009c1c7c65551d32e9ed3b1dda8f upstream.
As syzkaller detected, wlan-ng driver does not do sanity check of
endpoints in prism2sta_probe_usb(), add check for xfer direction and type
Reported-and-tested-by: syzbot+c2a1fa67c02faa0de723@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=c2a1fa67c02faa0de723
Signed-off-by: Rustam Kovhaev <rkovhaev@gmail.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200722161052.999754-1-rkovhaev@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steve French [Thu, 23 Jul 2020 19:41:29 +0000 (14:41 -0500)]
Revert "cifs: Fix the target file was deleted when rename failed."
commit
0e6705182d4e1b77248a93470d6d7b3013d59b30 upstream.
This reverts commit
9ffad9263b467efd8f8dc7ae1941a0a655a2bab2.
Upon additional testing with older servers, it was found that
the original commit introduced a regression when using the old SMB1
dialect and rsyncing over an existing file.
The patch will need to be respun to address this, likely including
a larger refactoring of the SMB1 and SMB3 rename code paths to make
it less confusing and also to address some additional rename error
cases that SMB3 may be able to workaround.
Signed-off-by: Steve French <stfrench@microsoft.com>
Reported-by: Patrick Fernie <patrick.fernie@gmail.com>
CC: Stable <stable@vger.kernel.org>
Acked-by: Ronnie Sahlberg <lsahlber@redhat.com>
Acked-by: Pavel Shilovsky <pshilov@microsoft.com>
Acked-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Forest Crossman [Fri, 17 Jul 2020 11:27:34 +0000 (06:27 -0500)]
usb: xhci: Fix ASM2142/ASM3142 DMA addressing
commit
dbb0897e805f2ab1b8bc358f6c3d878a376b8897 upstream.
The ASM2142/ASM3142 (same PCI IDs) does not support full 64-bit DMA
addresses, which can cause silent memory corruption or IOMMU errors on
platforms that use the upper bits. Add the XHCI_NO_64BIT_SUPPORT quirk
to fix this issue.
Signed-off-by: Forest Crossman <cyrozap@gmail.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200717112734.328432-1-cyrozap@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chunfeng Yun [Fri, 10 Jul 2020 05:57:52 +0000 (13:57 +0800)]
usb: xhci-mtk: fix the failure of bandwidth allocation
commit
5ce1a24dd98c00a57a8fa13660648abf7e08e3ef upstream.
The wMaxPacketSize field of endpoint descriptor may be zero
as default value in alternate interface, and they are not
actually selected when start stream, so skip them when try to
allocate bandwidth.
Cc: stable <stable@vger.kernel.org>
Fixes:
0cbd4b34cda9 ("xhci: mediatek: support MTK xHCI host controller")
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Link: https://lore.kernel.org/r/1594360672-2076-1-git-send-email-chunfeng.yun@mediatek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Wed, 27 May 2020 13:53:46 +0000 (15:53 +0200)]
x86: math-emu: Fix up 'cmp' insn for clang ias
[ Upstream commit
81e96851ea32deb2c921c870eecabf335f598aeb ]
The clang integrated assembler requires the 'cmp' instruction to
have a length prefix here:
arch/x86/math-emu/wm_sqrt.S:212:2: error: ambiguous instructions require an explicit suffix (could be 'cmpb', 'cmpw', or 'cmpl')
cmp $0xffffffff,-24(%ebp)
^
Make this a 32-bit comparison, which it was clearly meant to be.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Link: https://lkml.kernel.org/r/20200527135352.1198078-1-arnd@arndb.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
Will Deacon [Thu, 13 Feb 2020 12:12:26 +0000 (12:12 +0000)]
arm64: Use test_tsk_thread_flag() for checking TIF_SINGLESTEP
[ Upstream commit
5afc78551bf5d53279036e0bf63314e35631d79f ]
Rather than open-code test_tsk_thread_flag() at each callsite, simply
replace the couple of offenders with calls to test_tsk_thread_flag()
directly.
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Evgeny Novikov [Fri, 26 Jun 2020 13:17:47 +0000 (16:17 +0300)]
usb: gadget: udc: gr_udc: fix memleak on error handling path in gr_ep_init()
[ Upstream commit
c8f8529e2c4141afa2ebb487ad48e8a6ec3e8c99 ]
gr_ep_init() does not assign the allocated request anywhere if allocation
of memory for the buffer fails. This is a memory leak fixed by the given
patch.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Leonid Ravich [Wed, 1 Jul 2020 18:48:12 +0000 (21:48 +0300)]
dmaengine: ioat setting ioat timeout as module parameter
[ Upstream commit
87730ccbddcb48478b1b88e88b14e73424130764 ]
DMA transaction time to completion is a function of PCI bandwidth,
transaction size and a queue depth. So hard coded value for timeouts
might be wrong for some scenarios.
Signed-off-by: Leonid Ravich <Leonid.Ravich@emc.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/20200701184816.29138-1-leonid.ravich@dell.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marc Kleine-Budde [Fri, 3 Jul 2020 10:33:15 +0000 (12:33 +0200)]
regmap: dev_get_regmap_match(): fix string comparison
[ Upstream commit
e84861fec32dee8a2e62bbaa52cded6b05a2a456 ]
This function is used by dev_get_regmap() to retrieve a regmap for the
specified device. If the device has more than one regmap, the name parameter
can be used to specify one.
The code here uses a pointer comparison to check for equal strings. This
however will probably always fail, as the regmap->name is allocated via
kstrdup_const() from the regmap's config->name.
Fix this by using strcmp() instead.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Link: https://lore.kernel.org/r/20200703103315.267996-1-mkl@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dinghao Liu [Wed, 24 Jun 2020 06:46:26 +0000 (14:46 +0800)]
dmaengine: tegra210-adma: Fix runtime PM imbalance on error
[ Upstream commit
5b78fac4b1ba731cf4177fdbc1e3a4661521bcd0 ]
pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code. Thus a pairing decrement is needed on
the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://lore.kernel.org/r/20200624064626.19855-1-dinghao.liu@zju.edu.cn
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hans de Goede [Sat, 20 Jun 2020 12:32:29 +0000 (14:32 +0200)]
HID: apple: Disable Fn-key key-re-mapping on clone keyboards
[ Upstream commit
a5d81646fa294eed57786a9310b06ca48902adf8 ]
The Maxxter KB-BT-001 Bluetooth keyboard, which looks somewhat like the
Apple Wireless Keyboard, is using the vendor and product IDs (05AC:0239)
of the Apple Wireless Keyboard (2009 ANSI version) <sigh>.
But its F1 - F10 keys are marked as sending F1 - F10, not the special
functions hid-apple.c maps them too; and since its descriptors do not
contain the HID_UP_CUSTOM | 0x0003 usage apple-hid looks for for the
Fn-key, apple_setup_input() never gets called, so F1 - F6 are mapped
to key-codes which have not been set in the keybit array causing them
to not send any events at all.
The lack of a usage code matching the Fn key in the clone is actually
useful as this allows solving this problem in a generic way.
This commits adds a fn_found flag and it adds a input_configured
callback which checks if this flag is set once all usages have been
mapped. If it is not set, then assume this is a clone and clear the
quirks bitmap so that the hid-apple code does not add any special
handling to this keyboard.
This fixes F1 - F6 not sending anything at all and F7 - F12 sending
the wrong codes on the Maxxter KB-BT-001 Bluetooth keyboard and on
similar clones.
Cc: Joao Moreno <mail@joaomoreno.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Federico Ricchiuto [Mon, 15 Jun 2020 20:49:11 +0000 (22:49 +0200)]
HID: i2c-hid: add Mediacom FlexBook edge13 to descriptor override
[ Upstream commit
43e666acb79f3d355dd89bf20f4d25d3b15da13e ]
The Mediacom FlexBook edge13 uses the SIPODEV SP1064 touchpad, which does not
supply descriptors, so it has to be added to the override list.
Signed-off-by: Federico Ricchiuto <fed.ricchiuto@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pi-Hsun Shih [Fri, 24 Jul 2020 04:15:43 +0000 (21:15 -0700)]
scripts/decode_stacktrace: strip basepath from all paths
[ Upstream commit
d178770d8d21489abf5bafefcbb6d5243b482e9a ]
Currently the basepath is removed only from the beginning of the string.
When the symbol is inlined and there's multiple line outputs of
addr2line, only the first line would have basepath removed.
Change to remove the basepath prefix from all lines.
Fixes:
31013836a71e ("scripts/decode_stacktrace: match basepath using shell prefix operator, not regex")
Co-developed-by: Shik Chen <shik@chromium.org>
Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
Signed-off-by: Shik Chen <shik@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Cc: Sasha Levin <sashal@kernel.org>
Cc: Nicolas Boichat <drinkcat@chromium.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Link: http://lkml.kernel.org/r/20200720082709.252805-1-pihsun@chromium.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wang Hai [Thu, 16 Jul 2020 03:50:38 +0000 (11:50 +0800)]
net: smc91x: Fix possible memory leak in smc_drv_probe()
[ Upstream commit
bca9749b1aa23d964d3ab930938af66dbf887f15 ]
If try_toggle_control_gpio() failed in smc_drv_probe(), free_netdev(ndev)
should be called to free the ndev created earlier. Otherwise, a memleak
will occur.
Fixes:
7d2911c43815 ("net: smc91x: Fix gpios for device tree based booting")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sergey Organov [Wed, 15 Jul 2020 16:10:00 +0000 (19:10 +0300)]
net: dp83640: fix SIOCSHWTSTAMP to update the struct with actual configuration
[ Upstream commit
473309fb8372365ad211f425bca760af800e10a7 ]
From Documentation/networking/timestamping.txt:
A driver which supports hardware time stamping shall update the
struct with the actual, possibly more permissive configuration.
Do update the struct passed when we upscale the requested time
stamping mode.
Fixes:
cb646e2b02b2 ("ptp: Added a clock driver for the National Semiconductor PHYTER.")
Signed-off-by: Sergey Organov <sorganov@gmail.com>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
George Kennedy [Wed, 15 Jul 2020 13:59:31 +0000 (09:59 -0400)]
ax88172a: fix ax88172a_unbind() failures
[ Upstream commit
c28d9a285668c799eeae2f7f93e929a6028a4d6d ]
If ax88172a_unbind() fails, make sure that the return code is
less than zero so that cleanup is done properly and avoid UAF.
Fixes:
a9a51bd727d1 ("ax88172a: fix information leak on short answers")
Signed-off-by: George Kennedy <george.kennedy@oracle.com>
Reported-by: syzbot+4cd84f527bf4a10fc9c1@syzkaller.appspotmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe JAILLET [Tue, 14 Jul 2020 11:00:27 +0000 (13:00 +0200)]
hippi: Fix a size used in a 'pci_free_consistent()' in an error handling path
[ Upstream commit
3195c4706b00106aa82c73acd28340fa8fc2bfc1 ]
The size used when calling 'pci_alloc_consistent()' and
'pci_free_consistent()' should match.
Fix it and have it consistent with the corresponding call in 'rr_close()'.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vasundhara Volam [Sun, 12 Jul 2020 00:48:23 +0000 (20:48 -0400)]
bnxt_en: Fix race when modifying pause settings.
[ Upstream commit
163e9ef63641a02de4c95cd921577265c52e1ce2 ]
The driver was modified to not rely on rtnl lock to protect link
settings about 2 years ago. The pause setting was missed when
making that change. Fix it by acquiring link_lock mutex before
calling bnxt_hwrm_set_pause().
Fixes:
e2dc9b6e38fa ("bnxt_en: Don't use rtnl lock to protect link change logic in workqueue.")
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Reviewed-by: Edwin Peer <edwin.peer@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Boris Burkov [Thu, 16 Jul 2020 20:29:46 +0000 (13:29 -0700)]
btrfs: fix mount failure caused by race with umount
[ Upstream commit
48cfa61b58a1fee0bc49eef04f8ccf31493b7cdd ]
It is possible to cause a btrfs mount to fail by racing it with a slow
umount. The crux of the sequence is generic_shutdown_super not yet
calling sop->put_super before btrfs_mount_root calls btrfs_open_devices.
If that occurs, btrfs_open_devices will decide the opened counter is
non-zero, increment it, and skip resetting fs_devices->total_rw_bytes to
0. From here, mount will call sget which will result in grab_super
trying to take the super block umount semaphore. That semaphore will be
held by the slow umount, so mount will block. Before up-ing the
semaphore, umount will delete the super block, resulting in mount's sget
reliably allocating a new one, which causes the mount path to dutifully
fill it out, and increment total_rw_bytes a second time, which causes
the mount to fail, as we see double the expected bytes.
Here is the sequence laid out in greater detail:
CPU0 CPU1
down_write sb->s_umount
btrfs_kill_super
kill_anon_super(sb)
generic_shutdown_super(sb);
shrink_dcache_for_umount(sb);
sync_filesystem(sb);
evict_inodes(sb); // SLOW
btrfs_mount_root
btrfs_scan_one_device
fs_devices = device->fs_devices
fs_info->fs_devices = fs_devices
// fs_devices-opened makes this a no-op
btrfs_open_devices(fs_devices, mode, fs_type)
s = sget(fs_type, test, set, flags, fs_info);
find sb in s_instances
grab_super(sb);
down_write(&s->s_umount); // blocks
sop->put_super(sb)
// sb->fs_devices->opened == 2; no-op
spin_lock(&sb_lock);
hlist_del_init(&sb->s_instances);
spin_unlock(&sb_lock);
up_write(&sb->s_umount);
return 0;
retry lookup
don't find sb in s_instances (deleted by CPU0)
s = alloc_super
return s;
btrfs_fill_super(s, fs_devices, data)
open_ctree // fs_devices total_rw_bytes improperly set!
btrfs_read_chunk_tree
read_one_dev // increment total_rw_bytes again!!
super_total_bytes < fs_devices->total_rw_bytes // ERROR!!!
To fix this, we clear total_rw_bytes from within btrfs_read_chunk_tree
before the calls to read_one_dev, while holding the sb umount semaphore
and the uuid mutex.
To reproduce, it is sufficient to dirty a decent number of inodes, then
quickly umount and mount.
for i in $(seq 0 500)
do
dd if=/dev/zero of="/mnt/foo/$i" bs=1M count=1
done
umount /mnt/foo&
mount /mnt/foo
does the trick for me.
CC: stable@vger.kernel.org # 4.4+
Signed-off-by: Boris Burkov <boris@bur.io>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Filipe Manana [Mon, 13 Jul 2020 14:11:56 +0000 (15:11 +0100)]
btrfs: fix double free on ulist after backref resolution failure
commit
580c079b5766ac706f56eec5c79aee4bf929fef6 upstream.
At btrfs_find_all_roots_safe() we allocate a ulist and set the **roots
argument to point to it. However if later we fail due to an error returned
by find_parent_nodes(), we free that ulist but leave a dangling pointer in
the **roots argument. Upon receiving the error, a caller of this function
can attempt to free the same ulist again, resulting in an invalid memory
access.
One such scenario is during qgroup accounting:
btrfs_qgroup_account_extents()
--> calls btrfs_find_all_roots() passes &new_roots (a stack allocated
pointer) to btrfs_find_all_roots()
--> btrfs_find_all_roots() just calls btrfs_find_all_roots_safe()
passing &new_roots to it
--> allocates ulist and assigns its address to **roots (which
points to new_roots from btrfs_qgroup_account_extents())
--> find_parent_nodes() returns an error, so we free the ulist
and leave **roots pointing to it after returning
--> btrfs_qgroup_account_extents() sees btrfs_find_all_roots() returned
an error and jumps to the label 'cleanup', which just tries to
free again the same ulist
Stack trace example:
------------[ cut here ]------------
BTRFS: tree first key check failed
WARNING: CPU: 1 PID: 1763215 at fs/btrfs/disk-io.c:422 btrfs_verify_level_key+0xe0/0x180 [btrfs]
Modules linked in: dm_snapshot dm_thin_pool (...)
CPU: 1 PID: 1763215 Comm: fsstress Tainted: G W 5.8.0-rc3-btrfs-next-64 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:btrfs_verify_level_key+0xe0/0x180 [btrfs]
Code: 28 5b 5d (...)
RSP: 0018:
ffffb89b473779a0 EFLAGS:
00010286
RAX:
0000000000000000 RBX:
ffff90397759bf08 RCX:
0000000000000000
RDX:
0000000000000001 RSI:
0000000000000027 RDI:
00000000ffffffff
RBP:
ffff9039a419c000 R08:
0000000000000000 R09:
0000000000000000
R10:
0000000000000000 R11:
ffffb89b43301000 R12:
000000000000005e
R13:
ffffb89b47377a2e R14:
ffffb89b473779af R15:
0000000000000000
FS:
00007fc47e1e1000(0000) GS:
ffff9039ac200000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
00007fc47e1df000 CR3:
00000003d9e4e001 CR4:
00000000003606e0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
Call Trace:
read_block_for_search+0xf6/0x350 [btrfs]
btrfs_next_old_leaf+0x242/0x650 [btrfs]
resolve_indirect_refs+0x7cf/0x9e0 [btrfs]
find_parent_nodes+0x4ea/0x12c0 [btrfs]
btrfs_find_all_roots_safe+0xbf/0x130 [btrfs]
btrfs_qgroup_account_extents+0x9d/0x390 [btrfs]
btrfs_commit_transaction+0x4f7/0xb20 [btrfs]
btrfs_sync_file+0x3d4/0x4d0 [btrfs]
do_fsync+0x38/0x70
__x64_sys_fdatasync+0x13/0x20
do_syscall_64+0x5c/0xe0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7fc47e2d72e3
Code: Bad RIP value.
RSP: 002b:
00007fffa32098c8 EFLAGS:
00000246 ORIG_RAX:
000000000000004b
RAX:
ffffffffffffffda RBX:
0000000000000003 RCX:
00007fc47e2d72e3
RDX:
00007fffa3209830 RSI:
00007fffa3209830 RDI:
0000000000000003
RBP:
000000000000072e R08:
0000000000000001 R09:
0000000000000003
R10:
0000000000000000 R11:
0000000000000246 R12:
00000000000003e8
R13:
0000000051eb851f R14:
00007fffa3209970 R15:
00005607c4ac8b50
irq event stamp: 0
hardirqs last enabled at (0): [<
0000000000000000>] 0x0
hardirqs last disabled at (0): [<
ffffffffb8eb5e85>] copy_process+0x755/0x1eb0
softirqs last enabled at (0): [<
ffffffffb8eb5e85>] copy_process+0x755/0x1eb0
softirqs last disabled at (0): [<
0000000000000000>] 0x0
---[ end trace
8639237550317b48 ]---
BTRFS error (device sdc): tree first key mismatch detected, bytenr=
62324736 parent_transid=94 key expected=(262,108,1351680) has=(259,108,1921024)
general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI
CPU: 2 PID: 1763215 Comm: fsstress Tainted: G W 5.8.0-rc3-btrfs-next-64 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:ulist_release+0x14/0x60 [btrfs]
Code: c7 07 00 (...)
RSP: 0018:
ffffb89b47377d60 EFLAGS:
00010282
RAX:
6b6b6b6b6b6b6b6b RBX:
ffff903959b56b90 RCX:
0000000000000000
RDX:
0000000000000001 RSI:
0000000000270024 RDI:
ffff9036e2adc840
RBP:
ffff9036e2adc848 R08:
0000000000000000 R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000000 R12:
ffff9036e2adc840
R13:
0000000000000015 R14:
ffff9039a419ccf8 R15:
ffff90395d605840
FS:
00007fc47e1e1000(0000) GS:
ffff9039ac600000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
00007f8c1c0a51c8 CR3:
00000003d9e4e004 CR4:
00000000003606e0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
Call Trace:
ulist_free+0x13/0x20 [btrfs]
btrfs_qgroup_account_extents+0xf3/0x390 [btrfs]
btrfs_commit_transaction+0x4f7/0xb20 [btrfs]
btrfs_sync_file+0x3d4/0x4d0 [btrfs]
do_fsync+0x38/0x70
__x64_sys_fdatasync+0x13/0x20
do_syscall_64+0x5c/0xe0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7fc47e2d72e3
Code: Bad RIP value.
RSP: 002b:
00007fffa32098c8 EFLAGS:
00000246 ORIG_RAX:
000000000000004b
RAX:
ffffffffffffffda RBX:
0000000000000003 RCX:
00007fc47e2d72e3
RDX:
00007fffa3209830 RSI:
00007fffa3209830 RDI:
0000000000000003
RBP:
000000000000072e R08:
0000000000000001 R09:
0000000000000003
R10:
0000000000000000 R11:
0000000000000246 R12:
00000000000003e8
R13:
0000000051eb851f R14:
00007fffa3209970 R15:
00005607c4ac8b50
Modules linked in: dm_snapshot dm_thin_pool (...)
---[ end trace
8639237550317b49 ]---
RIP: 0010:ulist_release+0x14/0x60 [btrfs]
Code: c7 07 00 (...)
RSP: 0018:
ffffb89b47377d60 EFLAGS:
00010282
RAX:
6b6b6b6b6b6b6b6b RBX:
ffff903959b56b90 RCX:
0000000000000000
RDX:
0000000000000001 RSI:
0000000000270024 RDI:
ffff9036e2adc840
RBP:
ffff9036e2adc848 R08:
0000000000000000 R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000000 R12:
ffff9036e2adc840
R13:
0000000000000015 R14:
ffff9039a419ccf8 R15:
ffff90395d605840
FS:
00007fc47e1e1000(0000) GS:
ffff9039ad200000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
00007f6a776f7d40 CR3:
00000003d9e4e002 CR4:
00000000003606e0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
Fix this by making btrfs_find_all_roots_safe() set *roots to NULL after
it frees the ulist.
Fixes:
8da6d5815c592b ("Btrfs: added btrfs_find_all_roots()")
CC: stable@vger.kernel.org # 4.4+
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Sun, 28 Jun 2020 15:52:27 +0000 (17:52 +0200)]
ASoC: rt5670: Correct RT5670_LDO_SEL_MASK
commit
5cacc6f5764e94fa753b2c1f5f7f1f3f74286e82 upstream.
The RT5670_PWR_ANLG1 register has 3 bits to select the LDO voltage,
so the correct mask is 0x7 not 0x3.
Because of this wrong mask we were programming the ldo bits
to a setting of binary 001 (0x05 & 0x03) instead of binary 101
when moving to SND_SOC_BIAS_PREPARE.
According to the datasheet 001 is a reserved value, so no idea
what it did, since the driver was working fine before I guess we
got lucky and it does something which is ok.
Fixes:
5e8351de740d ("ASoC: add RT5670 CODEC driver")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200628155231.71089-3-hdegoede@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Fri, 17 Jul 2020 08:40:23 +0000 (10:40 +0200)]
ALSA: info: Drop WARN_ON() from buffer NULL sanity check
commit
60379ba08532eca861e933b389526a4dc89e0c42 upstream.
snd_info_get_line() has a sanity check of NULL buffer -- both buffer
itself being NULL and buffer->buffer being NULL. Basically both
checks are valid and necessary, but the problem is that it's with
snd_BUG_ON() macro that triggers WARN_ON(). The latter condition
(NULL buffer->buffer) can be met arbitrarily by user since the buffer
is allocated at the first write, so it means that user can trigger
WARN_ON() at will.
This patch addresses it by simply moving buffer->buffer NULL check out
of snd_BUG_ON() so that spurious WARNING is no longer triggered.
Reported-by: syzbot+e42d0746c3c3699b6061@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200717084023.5928-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oleg Nesterov [Thu, 23 Jul 2020 15:44:20 +0000 (17:44 +0200)]
uprobes: Change handle_swbp() to send SIGTRAP with si_code=SI_KERNEL, to fix GDB regression
commit
fe5ed7ab99c656bd2f5b79b49df0e9ebf2cead8a upstream.
If a tracee is uprobed and it hits int3 inserted by debugger, handle_swbp()
does send_sig(SIGTRAP, current, 0) which means si_code == SI_USER. This used
to work when this code was written, but then GDB started to validate si_code
and now it simply can't use breakpoints if the tracee has an active uprobe:
# cat test.c
void unused_func(void)
{
}
int main(void)
{
return 0;
}
# gcc -g test.c -o test
# perf probe -x ./test -a unused_func
# perf record -e probe_test:unused_func gdb ./test -ex run
GNU gdb (GDB) 10.0.50.
20200714-git
...
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff7ddf909 in dl_main () from /lib64/ld-linux-x86-64.so.2
(gdb)
The tracee hits the internal breakpoint inserted by GDB to monitor shared
library events but GDB misinterprets this SIGTRAP and reports a signal.
Change handle_swbp() to use force_sig(SIGTRAP), this matches do_int3_user()
and fixes the problem.
This is the minimal fix for -stable, arch/x86/kernel/uprobes.c is equally
wrong; it should use send_sigtrap(TRAP_TRACE) instead of send_sig(SIGTRAP),
but this doesn't confuse GDB and needs another x86-specific patch.
Reported-by: Aaron Merey <amerey@redhat.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200723154420.GA32043@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Olga Kornievskaia [Wed, 15 Jul 2020 17:04:15 +0000 (13:04 -0400)]
SUNRPC reverting
d03727b248d0 ("NFSv4 fix CLOSE not waiting for direct IO compeletion")
commit
65caafd0d2145d1dd02072c4ced540624daeab40 upstream.
Reverting commit
d03727b248d0 "NFSv4 fix CLOSE not waiting for
direct IO compeletion". This patch made it so that fput() by calling
inode_dio_done() in nfs_file_release() would wait uninterruptably
for any outstanding directIO to the file (but that wait on IO should
be killable).
The problem the patch was also trying to address was REMOVE returning
ERR_ACCESS because the file is still opened, is supposed to be resolved
by server returning ERR_FILE_OPEN and not ERR_ACCESS.
Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Skeggs [Tue, 23 Jun 2020 06:39:13 +0000 (16:39 +1000)]
drm/nouveau/i2c/g94-: increase NV_PMGR_DP_AUXCTL_TRANSACTREQ timeout
[ Upstream commit
0156e76d388310a490aeb0f2fbb5b284ded3aecc ]
Tegra TRM says worst-case reply time is 1216us, and this should fix some
spurious timeouts that have been popping up.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tom Rix [Fri, 3 Jul 2020 13:33:59 +0000 (06:33 -0700)]
net: sky2: initialize return of gm_phy_read
[ Upstream commit
28b18e4eb515af7c6661c3995c6e3c34412c2874 ]
clang static analysis flags this garbage return
drivers/net/ethernet/marvell/sky2.c:208:2: warning: Undefined or garbage value returned to caller [core.uninitialized.UndefReturn]
return v;
^~~~~~~~
static inline u16 gm_phy_read( ...
{
u16 v;
__gm_phy_read(hw, port, reg, &v);
return v;
}
__gm_phy_read can return without setting v.
So handle similar to skge.c's gm_phy_read, initialize v.
Signed-off-by: Tom Rix <trix@redhat.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xie He [Mon, 6 Jul 2020 00:45:21 +0000 (17:45 -0700)]
drivers/net/wan/lapbether: Fixed the value of hard_header_len
[ Upstream commit
9dc829a135fb5927f1519de11286e2bbb79f5b66 ]
When this driver transmits data,
first this driver will remove a pseudo header of 1 byte,
then the lapb module will prepend the LAPB header of 2 or 3 bytes,
then this driver will prepend a length field of 2 bytes,
then the underlying Ethernet device will prepend its own header.
So, the header length required should be:
-1 + 3 + 2 + "the header length needed by the underlying device".
This patch fixes kernel panic when this driver is used with AF_PACKET
SOCK_DGRAM sockets.
Signed-off-by: Xie He <xie.he.0141@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Max Filippov [Thu, 2 Jul 2020 15:32:25 +0000 (08:32 -0700)]
xtensa: update *pos in cpuinfo_op.next
[ Upstream commit
0d5ab144429e8bd80889b856a44d56ab4a5cd59b ]
Increment *pos in the cpuinfo_op.next to fix the following warning
triggered by cat /proc/cpuinfo:
seq_file: buggy .next function c_next did not update position index
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Max Filippov [Thu, 4 Jun 2020 20:37:10 +0000 (13:37 -0700)]
xtensa: fix __sync_fetch_and_{and,or}_4 declarations
[ Upstream commit
73f9941306d5ce030f3ffc7db425c7b2a798cf8e ]
Building xtensa kernel with gcc-10 produces the following warnings:
arch/xtensa/kernel/xtensa_ksyms.c:90:15: warning: conflicting types
for built-in function ‘__sync_fetch_and_and_4’;
expected ‘unsigned int(volatile void *, unsigned int)’
[-Wbuiltin-declaration-mismatch]
arch/xtensa/kernel/xtensa_ksyms.c:96:15: warning: conflicting types
for built-in function ‘__sync_fetch_and_or_4’;
expected ‘unsigned int(volatile void *, unsigned int)’
[-Wbuiltin-declaration-mismatch]
Fix declarations of these functions to avoid the warning.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tom Rix [Sat, 27 Jun 2020 13:32:42 +0000 (06:32 -0700)]
scsi: scsi_transport_spi: Fix function pointer check
[ Upstream commit
5aee52c44d9170591df65fafa1cd408acc1225ce ]
clang static analysis flags several null function pointer problems.
drivers/scsi/scsi_transport_spi.c:374:1: warning: Called function pointer is null (null dereference) [core.CallAndMessage]
spi_transport_max_attr(offset, "%d\n");
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Reviewing the store_spi_store_max macro
if (i->f->set_##field)
return -EINVAL;
should be
if (!i->f->set_##field)
return -EINVAL;
Link: https://lore.kernel.org/r/20200627133242.21618-1-trix@redhat.com
Reviewed-by: James Bottomley <jejb@linux.ibm.com>
Signed-off-by: Tom Rix <trix@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Markus Theil [Thu, 25 Jun 2020 10:42:14 +0000 (12:42 +0200)]
mac80211: allow rx of mesh eapol frames with default rx key
[ Upstream commit
0b467b63870d9c05c81456aa9bfee894ab2db3b6 ]
Without this patch, eapol frames cannot be received in mesh
mode, when 802.1X should be used. Initially only a MGTK is
defined, which is found and set as rx->key, when there are
no other keys set. ieee80211_drop_unencrypted would then
drop these eapol frames, as they are data frames without
encryption and there exists some rx->key.
Fix this by differentiating between mesh eapol frames and
other data frames with existing rx->key. Allow mesh mesh
eapol frames only if they are for our vif address.
With this patch in-place, ieee80211_rx_h_mesh_fwding continues
after the ieee80211_drop_unencrypted check and notices, that
these eapol frames have to be delivered locally, as they should.
Signed-off-by: Markus Theil <markus.theil@tu-ilmenau.de>
Link: https://lore.kernel.org/r/20200625104214.50319-1-markus.theil@tu-ilmenau.de
[small code cleanups]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jacky Hu [Tue, 16 Jun 2020 01:50:24 +0000 (09:50 +0800)]
pinctrl: amd: fix npins for uart0 in kerncz_groups
[ Upstream commit
69339d083dfb7786b0e0b3fc19eaddcf11fabdfb ]
uart0_pins is defined as:
static const unsigned uart0_pins[] = {135, 136, 137, 138, 139};
which npins is wronly specified as 9 later
{
.name = "uart0",
.pins = uart0_pins,
.npins = 9,
},
npins should be 5 instead of 9 according to the definition.
Signed-off-by: Jacky Hu <hengqing.hu@gmail.com>
Link: https://lore.kernel.org/r/20200616015024.287683-1-hengqing.hu@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Greg Kroah-Hartman [Wed, 22 Jul 2020 07:10:54 +0000 (09:10 +0200)]
Linux 4.9.231
Suraj Jitindar Singh [Tue, 14 Jul 2020 22:05:28 +0000 (22:05 +0000)]
x86/cpu: Move x86_cache_bits settings
This patch is to fix the backport of the upstream patch:
cc51e5428ea5 x86/speculation/l1tf: Increase l1tf memory limit for Nehalem+
When this was backported to the 4.9 and 4.14 stable branches the line
+ c->x86_cache_bits = c->x86_phys_bits;
was applied in the wrong place, being added to the
identify_cpu_without_cpuid() function instead of the get_cpu_cap()
function which it was correctly applied to in the 4.4 backport.
This means that x86_cache_bits is not set correctly resulting in the
following warning due to the cache bits being left uninitalised (zero).
WARNING: CPU: 0 PID: 7566 at arch/x86/kvm/mmu.c:284 kvm_mmu_set_mmio_spte_mask+0x4e/0x60 [kvm
Modules linked in: kvm_intel(+) kvm irqbypass ipv6 crc_ccitt binfmt_misc evdev lpc_ich mfd_core ioatdma pcc_cpufreq dca ena acpi_power_meter hwmon acpi_pad button ext4 crc16 mbcache jbd2 fscrypto nvme nvme_core dm_mirror dm_region_hash dm_log dm_mod dax
Hardware name: Amazon EC2 i3.metal/Not Specified, BIOS 1.0 10/16/2017
task:
ffff88ff77704c00 task.stack:
ffffc9000edac000
RIP: 0010:kvm_mmu_set_mmio_spte_mask+0x4e/0x60 [kvm
RSP: 0018:
ffffc9000edafc60 EFLAGS:
00010206
RAX:
0000000000000000 RBX:
0000000000000000 RCX:
00000000ffffff45
RDX:
000000000000002e RSI:
0008000000000001 RDI:
0008000000000001
RBP:
ffffffffa036f000 R08:
ffffffffffffff80 R09:
ffffe8ffffccb3c0
R10:
0000000000000038 R11:
0000000000000000 R12:
0000000000005b80
R13:
ffffffffa0370e40 R14:
0000000000000001 R15:
ffff88bf7c0927e0
FS:
00007fa316f24740(0000) GS:
ffff88bf7f600000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
00007fa316ea0000 CR3:
0000003f7e986004 CR4:
00000000003606f0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
Call Trace:
kvm_mmu_module_init+0x166/0x230 [kvm
kvm_arch_init+0x5d/0x150 [kvm
kvm_init+0x1c/0x2d0 [kvm
? hardware_setup+0x4a6/0x4a6 [kvm_intel
vmx_init+0x23/0x6aa [kvm_intel
? hardware_setup+0x4a6/0x4a6 [kvm_intel
do_one_initcall+0x3e/0x15d
do_init_module+0x5b/0x1e5
load_module+0x19e6/0x1dc0
? SYSC_init_module+0x13b/0x170
SYSC_init_module+0x13b/0x170
do_syscall_64+0x67/0x110
entry_SYSCALL_64_after_hwframe+0x41/0xa6
RIP: 0033:0x7fa316828f3a
RSP: 002b:
00007ffc9d65c1f8 EFLAGS:
00000246 ORIG_RAX:
00000000000000af
RAX:
ffffffffffffffda RBX:
00007fa316b08849 RCX:
00007fa316828f3a
RDX:
00007fa316b08849 RSI:
0000000000071328 RDI:
00007fa316e37000
RBP:
0000000000b47e80 R08:
0000000000000003 R09:
0000000000000000
R10:
00007fa316822dba R11:
0000000000000246 R12:
0000000000b46340
R13:
0000000000b464c0 R14:
0000000000000000 R15:
0000000000040000
Code: e9 65 06 00 75 25 48 b8 00 00 00 00 00 00 00 40 48 09 c6 48 09 c7 48 89 35 f8 65 06 00 48 89 3d f9 65 06 00 c3 0f 0b 0f 0b eb d2 <0f> 0b eb d7 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44
Fixes: 4.9.x
ef3d45c95764 x86/speculation/l1tf: Increase l1tf memory limit for Nehalem+
Fixes: 4.14.x
ec4034835eaf x86/speculation/l1tf: Increase l1tf memory limit for Nehalem+
Cc: stable@vger.kernel.org # 4.9.x-4.14.x
Signed-off-by: Suraj Jitindar Singh <surajjs@amazon.com>
Reviewed-by: Samuel Mendoza-Jonas <samjonas@amazon.com>
Reviewed-by: Frank van der Linden <fllinden@amazon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marc Zyngier [Sun, 21 Jun 2020 13:43:15 +0000 (14:43 +0100)]
irqchip/gic: Atomically update affinity
commit
005c34ae4b44f085120d7f371121ec7ded677761 upstream.
The GIC driver uses a RMW sequence to update the affinity, and
relies on the gic_lock_irqsave/gic_unlock_irqrestore sequences
to update it atomically.
But these sequences only expand into anything meaningful if
the BL_SWITCHER option is selected, which almost never happens.
It also turns out that using a RMW and locks is just as silly,
as the GIC distributor supports byte accesses for the GICD_TARGETRn
registers, which when used make the update atomic by definition.
Drop the terminally broken code and replace it by a byte write.
Fixes:
04c8b0f82c7d ("irqchip/gic: Make locking a BL_SWITCHER only feature")
Cc: stable@vger.kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vincent Guittot [Fri, 10 Jul 2020 15:24:26 +0000 (17:24 +0200)]
sched/fair: handle case of task_h_load() returning 0
commit
01cfcde9c26d8555f0e6e9aea9d6049f87683998 upstream.
task_h_load() can return 0 in some situations like running stress-ng
mmapfork, which forks thousands of threads, in a sched group on a 224 cores
system. The load balance doesn't handle this correctly because
env->imbalance never decreases and it will stop pulling tasks only after
reaching loop_max, which can be equal to the number of running tasks of
the cfs. Make sure that imbalance will be decreased by at least 1.
misfit task is the other feature that doesn't handle correctly such
situation although it's probably more difficult to face the problem
because of the smaller number of CPUs and running tasks on heterogenous
system.
We can't simply ensure that task_h_load() returns at least one because it
would imply to handle underflow in other places.
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: <stable@vger.kernel.org> # v4.4+
Link: https://lkml.kernel.org/r/20200710152426.16981-1-vincent.guittot@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Will Deacon [Thu, 13 Feb 2020 12:06:26 +0000 (12:06 +0000)]
arm64: ptrace: Override SPSR.SS when single-stepping is enabled
commit
3a5a4366cecc25daa300b9a9174f7fdd352b9068 upstream.
Luis reports that, when reverse debugging with GDB, single-step does not
function as expected on arm64:
| I've noticed, under very specific conditions, that a PTRACE_SINGLESTEP
| request by GDB won't execute the underlying instruction. As a consequence,
| the PC doesn't move, but we return a SIGTRAP just like we would for a
| regular successful PTRACE_SINGLESTEP request.
The underlying problem is that when the CPU register state is restored
as part of a reverse step, the SPSR.SS bit is cleared and so the hardware
single-step state can transition to the "active-pending" state, causing
an unexpected step exception to be taken immediately if a step operation
is attempted.
In hindsight, we probably shouldn't have exposed SPSR.SS in the pstate
accessible by the GPR regset, but it's a bit late for that now. Instead,
simply prevent userspace from configuring the bit to a value which is
inconsistent with the TIF_SINGLESTEP state for the task being traced.
Cc: <stable@vger.kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Keno Fischer <keno@juliacomputing.com>
Link: https://lore.kernel.org/r/1eed6d69-d53d-9657-1fc9-c089be07f98c@linaro.org
Reported-by: Luis Machado <luis.machado@linaro.org>
Tested-by: Luis Machado <luis.machado@linaro.org>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michał Mirosław [Wed, 24 Jun 2020 11:35:41 +0000 (13:35 +0200)]
misc: atmel-ssc: lock with mutex instead of spinlock
commit
b037d60a3b1d1227609fd858fa34321f41829911 upstream.
Uninterruptible context is not needed in the driver and causes lockdep
warning because of mutex taken in of_alias_get_id(). Convert the lock to
mutex to avoid the issue.
Cc: stable@vger.kernel.org
Fixes:
099343c64e16 ("ARM: at91: atmel-ssc: add device tree support")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/50f0d7fa107f318296afb49477c3571e4d6978c5.1592998403.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Krzysztof Kozlowski [Thu, 11 Jun 2020 12:17:41 +0000 (14:17 +0200)]
dmaengine: fsl-edma: Fix NULL pointer exception in fsl_edma_tx_handler
commit
f5e5677c420346b4e9788051c2e4d750996c428c upstream.
NULL pointer exception happens occasionally on serial output initiated
by login timeout. This was reproduced only if kernel was built with
significant debugging options and EDMA driver is used with serial
console.
col-vf50 login: root
Password:
Login timed out after 60 seconds.
Unable to handle kernel NULL pointer dereference at virtual address
00000044
Internal error: Oops: 5 [#1] ARM
CPU: 0 PID: 157 Comm: login Not tainted 5.7.0-next-
20200610-dirty #4
Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
(fsl_edma_tx_handler) from [<
8016eb10>] (__handle_irq_event_percpu+0x64/0x304)
(__handle_irq_event_percpu) from [<
8016eddc>] (handle_irq_event_percpu+0x2c/0x7c)
(handle_irq_event_percpu) from [<
8016ee64>] (handle_irq_event+0x38/0x5c)
(handle_irq_event) from [<
801729e4>] (handle_fasteoi_irq+0xa4/0x160)
(handle_fasteoi_irq) from [<
8016ddcc>] (generic_handle_irq+0x34/0x44)
(generic_handle_irq) from [<
8016e40c>] (__handle_domain_irq+0x54/0xa8)
(__handle_domain_irq) from [<
80508bc8>] (gic_handle_irq+0x4c/0x80)
(gic_handle_irq) from [<
80100af0>] (__irq_svc+0x70/0x98)
Exception stack(0x8459fe80 to 0x8459fec8)
fe80:
72286b00 e3359f64 00000001 0000412d a0070013 85c98840 85c98840 a0070013
fea0:
8054e0d4 00000000 00000002 00000000 00000002 8459fed0 8081fbe8 8081fbec
fec0:
60070013 ffffffff
(__irq_svc) from [<
8081fbec>] (_raw_spin_unlock_irqrestore+0x30/0x58)
(_raw_spin_unlock_irqrestore) from [<
8056cb48>] (uart_flush_buffer+0x88/0xf8)
(uart_flush_buffer) from [<
80554e60>] (tty_ldisc_hangup+0x38/0x1ac)
(tty_ldisc_hangup) from [<
8054c7f4>] (__tty_hangup+0x158/0x2bc)
(__tty_hangup) from [<
80557b90>] (disassociate_ctty.part.1+0x30/0x23c)
(disassociate_ctty.part.1) from [<
8011fc18>] (do_exit+0x580/0xba0)
(do_exit) from [<
801214f8>] (do_group_exit+0x3c/0xb4)
(do_group_exit) from [<
80121580>] (__wake_up_parent+0x0/0x14)
Issue looks like race condition between interrupt handler fsl_edma_tx_handler()
(called as result of fsl_edma_xfer_desc()) and terminating the transfer with
fsl_edma_terminate_all().
The fsl_edma_tx_handler() handles interrupt for a transfer with already freed
edesc and idle==true.
Fixes:
d6be34fbd39b ("dma: Add Freescale eDMA engine driver support")
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Robin Gong <yibin.gong@nxp.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1591877861-28156-2-git-send-email-krzk@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vishwas M [Tue, 7 Jul 2020 14:27:47 +0000 (19:57 +0530)]
hwmon: (emc2103) fix unable to change fan pwm1_enable attribute
commit
14b0e83dc4f1e52b94acaeb85a18fd7fdd46d2dc upstream.
This patch fixes a bug which does not let FAN mode to be changed from
sysfs(pwm1_enable). i.e pwm1_enable can not be set to 3, it will always
remain at 0.
This is caused because the device driver handles the result of
"read_u8_from_i2c(client, REG_FAN_CONF1, &conf_reg)" incorrectly. The
driver thinks an error has occurred if the (result != 0). This has been
fixed by changing the condition to (result < 0).
Signed-off-by: Vishwas M <vishwas.reddy.vr@gmail.com>
Link: https://lore.kernel.org/r/20200707142747.118414-1-vishwas.reddy.vr@gmail.com
Fixes:
9df7305b5a86 ("hwmon: Add driver for SMSC EMC2103 temperature monitor and fan controller")
Cc: stable@vger.kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Huacai Chen [Thu, 16 Jul 2020 09:39:29 +0000 (17:39 +0800)]
MIPS: Fix build for LTS kernel caused by backporting lpj adjustment
Commit
ed26aacfb5f71eecb20a ("mips: Add udelay lpj numbers adjustment")
has backported to 4.4~5.4, but the "struct cpufreq_freqs" (and also the
cpufreq notifier machanism) of 4.4~4.19 are different from the upstream
kernel. These differences cause build errors, and this patch can fix the
build.
Cc: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Stable <stable@vger.kernel.org> # 4.4/4.9/4.14/4.19
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Frederic Weisbecker [Fri, 17 Jul 2020 14:05:40 +0000 (16:05 +0200)]
timer: Fix wheel index calculation on last level
commit
e2a71bdea81690b6ef11f4368261ec6f5b6891aa upstream.
When an expiration delta falls into the last level of the wheel, that delta
has be compared against the maximum possible delay and reduced to fit in if
necessary.
However instead of comparing the delta against the maximum, the code
compares the actual expiry against the maximum. Then instead of fixing the
delta to fit in, it sets the maximum delta as the expiry value.
This can result in various undesired outcomes, the worst possible one
being a timer expiring 15 days ahead to fire immediately.
Fixes:
500462a9de65 ("timers: Switch to a non-cascading wheel")
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20200717140551.29076-2-frederic@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Esben Haabendal [Wed, 1 Jul 2020 14:56:58 +0000 (16:56 +0200)]
uio_pdrv_genirq: fix use without device tree and no interrupt
commit
bf12fdf0ab728ca8e5933aac46dd972c0dd0421e upstream.
While
e3a3c3a20555 ("UIO: fix uio_pdrv_genirq with device tree but no
interrupt") added support for using uio_pdrv_genirq for devices without
interrupt for device tree platforms, the removal of uio_pdrv in
26dac3c49d56 ("uio: Remove uio_pdrv and use uio_pdrv_genirq instead")
broke the support for non device tree platforms.
This change fixes this, so that uio_pdrv_genirq can be used without
interrupt on all platforms.
This still leaves the support that uio_pdrv had for custom interrupt
handler lacking, as uio_pdrv_genirq does not handle it (yet).
Fixes:
26dac3c49d56 ("uio: Remove uio_pdrv and use uio_pdrv_genirq instead")
Signed-off-by: Esben Haabendal <esben@geanix.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200701145659.3978-3-esben@geanix.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Pedersen [Tue, 7 Jul 2020 01:48:51 +0000 (18:48 -0700)]
Input: i8042 - add Lenovo XiaoXin Air 12 to i8042 nomux list
commit
17d51429da722cd8fc77a365a112f008abf4f8b3 upstream.
This fixes two finger trackpad scroll on the Lenovo XiaoXin Air 12.
Without nomux, the trackpad behaves as if only one finger is present and
moves the cursor when trying to scroll.
Signed-off-by: David Pedersen <limero1337@gmail.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200625133754.291325-1-limero1337@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Usyskin [Sun, 28 Jun 2020 22:53:59 +0000 (01:53 +0300)]
mei: bus: don't clean driver pointer
commit
e852c2c251ed9c23ae6e3efebc5ec49adb504207 upstream.
It's not needed to set driver to NULL in mei_cl_device_remove()
which is bus_type remove() handler as this is done anyway
in __device_release_driver().
Actually this is causing an endless loop in driver_detach()
on ubuntu patched kernel, while removing (rmmod) the mei_hdcp module.
The reason list_empty(&drv->p->klist_devices.k_list) is always not-empty.
as the check is always true in __device_release_driver()
if (dev->driver != drv)
return;
The non upstream patch is causing this behavior, titled:
'vfio -- release device lock before userspace requests'
Nevertheless the fix is correct also for the upstream.
Link: https://patchwork.ozlabs.org/project/ubuntu-kernel/patch/20180912085046.3401-2-apw@canonical.com/
Cc: <stable@vger.kernel.org>
Cc: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Link: https://lore.kernel.org/r/20200628225359.2185929-1-tomas.winkler@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chirantan Ekbote [Tue, 14 Jul 2020 10:26:39 +0000 (19:26 +0900)]
fuse: Fix parameter for FS_IOC_{GET,SET}FLAGS
commit
31070f6ccec09f3bd4f1e28cd1e592fa4f3ba0b6 upstream.
The ioctl encoding for this parameter is a long but the documentation says
it should be an int and the kernel drivers expect it to be an int. If the
fuse driver treats this as a long it might end up scribbling over the stack
of a userspace process that only allocated enough space for an int.
This was previously discussed in [1] and a patch for fuse was proposed in
[2]. From what I can tell the patch in [2] was nacked in favor of adding
new, "fixed" ioctls and using those from userspace. However there is still
no "fixed" version of these ioctls and the fact is that it's sometimes
infeasible to change all userspace to use the new one.
Handling the ioctls specially in the fuse driver seems like the most
pragmatic way for fuse servers to support them without causing crashes in
userspace applications that call them.
[1]: https://lore.kernel.org/linux-fsdevel/
20131126200559.GH20559@hall.aurel32.net/T/
[2]: https://sourceforge.net/p/fuse/mailman/message/
31771759/
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Fixes:
59efec7b9039 ("fuse: implement ioctl support")
Cc: <stable@vger.kernel.org>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Lobakin [Tue, 23 Jun 2020 11:09:33 +0000 (11:09 +0000)]
virtio: virtio_console: add missing MODULE_DEVICE_TABLE() for rproc serial
commit
897c44f0bae574c5fb318c759b060bebf9dd6013 upstream.
rproc_serial_id_table lacks an exposure to module devicetable, so
when remoteproc firmware requests VIRTIO_ID_RPROC_SERIAL, no uevent
is generated and no module autoloading occurs.
Add missing MODULE_DEVICE_TABLE() annotation and move the existing
one for VIRTIO_ID_CONSOLE right to the table itself.
Fixes:
1b6370463e88 ("virtio_console: Add support for remoteproc serial")
Cc: <stable@vger.kernel.org> # v3.8+
Signed-off-by: Alexander Lobakin <alobakin@pm.me>
Reviewed-by: Amit Shah <amit@kernel.org>
Link: https://lore.kernel.org/r/x7C_CbeJtoGMy258nwAXASYz3xgFMFpyzmUvOyZzRnQrgWCREBjaqBOpAUS7ol4NnZYvSVwmTsCG0Ohyfvta-ygw6HMHcoeKK0C3QFiAO_Q=@pm.me
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
AceLan Kao [Tue, 7 Jul 2020 08:15:53 +0000 (16:15 +0800)]
USB: serial: option: add Quectel EG95 LTE modem
commit
da6902e5b6dbca9081e3d377f9802d4fd0c5ea59 upstream.
Add support for Quectel Wireless Solutions Co., Ltd. EG95 LTE modem
T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=2c7c ProdID=0195 Rev=03.18
S: Manufacturer=Android
S: Product=Android
C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jörgen Storvist [Mon, 22 Jun 2020 22:13:59 +0000 (00:13 +0200)]
USB: serial: option: add GosunCn GM500 series
commit
08d4ef5cc9203a113702f24725f6cf4db476c958 upstream.
Add USB IDs for GosunCn GM500 series cellular modules.
RNDIS config:
usb-devices
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 12 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=305a ProdID=1404 Rev=03.18
S: Manufacturer=Android
S: Product=Android
S: SerialNumber=
C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
I: If#=0x0 Alt= 0 #EPs= 1 Cls=e0(wlcon) Sub=01 Prot=03 Driver=rndis_host
I: If#=0x1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
I: If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
MBIM config:
usb-devices
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 11 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=305a ProdID=1405 Rev=03.18
S: Manufacturer=Android
S: Product=Android
S: SerialNumber=
C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#=0x3 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
I: If#=0x4 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
ECM config:
usb-devices
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 13 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=305a ProdID=1406 Rev=03.18
S: Manufacturer=Android
S: Product=Android
S: SerialNumber=
C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#=0x3 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether
I: If#=0x4 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
Signed-off-by: Jörgen Storvist <jorgen.storvist@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Igor Moura [Tue, 23 Jun 2020 08:11:11 +0000 (05:11 -0300)]
USB: serial: ch341: add new Product ID for CH340
commit
5d0136f8e79f8287e6a36780601f0ce797cf11c2 upstream.
Add PID for CH340 that's found on some ESP8266 dev boards made by
LilyGO. The specific device that contains such serial converter can be
seen here: https://github.com/LilyGO/LILYGO-T-OI.
Apparently, it's a regular CH340, but I've confirmed with others that
also bought this board that the PID found on this device (0x7522)
differs from other devices with the "same" converter (0x7523).
Simply adding its PID to the driver and rebuilding it made it work
as expected.
Signed-off-by: Igor Moura <imphilippini@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Hilliard [Tue, 16 Jun 2020 22:04:03 +0000 (16:04 -0600)]
USB: serial: cypress_m8: enable Simply Automated UPB PIM
commit
5c45d04c5081c1830d674f4d22d4400ea2083afe upstream.
This is a UPB (Universal Powerline Bus) PIM (Powerline Interface Module)
which allows for controlling multiple UPB compatible devices from Linux
using the standard serial interface.
Based on vendor application source code there are two different models
of USB based PIM devices in addition to a number of RS232 based PIM's.
The vendor UPB application source contains the following USB ID's:
#define USB_PCS_VENDOR_ID 0x04b4
#define USB_PCS_PIM_PRODUCT_ID 0x5500
#define USB_SAI_VENDOR_ID 0x17dd
#define USB_SAI_PIM_PRODUCT_ID 0x5500
The first set of ID's correspond to the PIM variant sold by Powerline
Control Systems while the second corresponds to the Simply Automated
Incorporated PIM. As the product ID for both of these match the default
cypress HID->COM RS232 product ID it assumed that they both use an
internal variant of this HID->COM RS232 converter hardware. However
as the vendor ID for the Simply Automated variant is different we need
to also add it to the cypress_M8 driver so that it is properly
detected.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Link: https://lore.kernel.org/r/20200616220403.1807003-1-james.hilliard1@gmail.com
Cc: stable@vger.kernel.org
[ johan: amend VID define entry ]
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 15 Jul 2020 09:02:45 +0000 (11:02 +0200)]
USB: serial: iuu_phoenix: fix memory corruption
commit
e7b931bee739e8a77ae216e613d3b99342b6dec0 upstream.
The driver would happily overwrite its write buffer with user data in
256 byte increments due to a removed buffer-space sanity check.
Fixes:
5fcf62b0f1f2 ("tty: iuu_phoenix: fix locking.")
Cc: stable <stable@vger.kernel.org> # 2.6.31
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Zhang Qiang [Mon, 6 Jul 2020 05:14:55 +0000 (13:14 +0800)]
usb: gadget: function: fix missing spinlock in f_uac1_legacy
commit
8778eb0927ddcd3f431805c37b78fa56481aeed9 upstream.
Add a missing spinlock protection for play_queue, because
the play_queue may be destroyed when the "playback_work"
work func and "f_audio_out_ep_complete" callback func
operate this paly_queue at the same time.
Fixes:
c6994e6f067cf ("USB: gadget: add USB Audio Gadget driver")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Zhang Qiang <qiang.zhang@windriver.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Chen [Tue, 7 Jul 2020 06:06:01 +0000 (14:06 +0800)]
usb: chipidea: core: add wakeup support for extcon
commit
876d4e1e8298ad1f94d9e9392fc90486755437b4 upstream.
If wakeup event occurred by extcon event, it needs to call
ci_irq again since the first ci_irq calling at extcon notifier
only wakes up controller, but do noop for event handling,
it causes the extcon use case can't work well from low power mode.
Cc: <stable@vger.kernel.org>
Fixes:
3ecb3e09b042 ("usb: chipidea: Use extcon framework for VBUS and ID detect")
Reported-by: Philippe Schenker <philippe.schenker@toradex.com>
Tested-by: Philippe Schenker <philippe.schenker@toradex.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Link: https://lore.kernel.org/r/20200707060601.31907-2-peter.chen@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Minas Harutyunyan [Sat, 30 May 2020 07:41:50 +0000 (11:41 +0400)]
usb: dwc2: Fix shutdown callback in platform
commit
4fdf228cdf6925af45a2066d403821e0977bfddb upstream.
To avoid lot of interrupts from dwc2 core, which can be asserted in
specific conditions need to disable interrupts on HW level instead of
disable IRQs on Kernel level, because of IRQ can be shared between
drivers.
Cc: stable@vger.kernel.org
Fixes:
a40a00318c7fc ("usb: dwc2: add shutdown callback to platform variant")
Tested-by: Frank Mori Hess <fmh6jj@gmail.com>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Frank Mori Hess <fmh6jj@gmail.com>
Signed-off-by: Minas Harutyunyan <hminas@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tom Rix [Wed, 8 Jul 2020 13:12:43 +0000 (06:12 -0700)]
USB: c67x00: fix use after free in c67x00_giveback_urb
commit
211f08347355cba1f769bbf3355816a12b3ddd55 upstream.
clang static analysis flags this error
c67x00-sched.c:489:55: warning: Use of memory after it is freed [unix.Malloc]
usb_hcd_giveback_urb(c67x00_hcd_to_hcd(c67x00), urb, urbp->status);
^~~~~~~~~~~~
Problem happens in this block of code
c67x00_release_urb(c67x00, urb);
usb_hcd_unlink_urb_from_ep(c67x00_hcd_to_hcd(c67x00), urb);
spin_unlock(&c67x00->lock);
usb_hcd_giveback_urb(c67x00_hcd_to_hcd(c67x00), urb, urbp->status);
In the call to c67x00_release_urb has this freeing of urbp
urbp = urb->hcpriv;
urb->hcpriv = NULL;
list_del(&urbp->hep_node);
kfree(urbp);
And so urbp is freed before usb_hcd_giveback_urb uses it as its 3rd
parameter.
Since all is required is the status, pass the status directly as is
done in c64x00_urb_dequeue
Fixes:
e9b29ffc519b ("USB: add Cypress c67x00 OTG controller HCD driver")
Signed-off-by: Tom Rix <trix@redhat.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200708131243.24336-1-trix@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Fri, 10 Jul 2020 16:06:56 +0000 (18:06 +0200)]
ALSA: usb-audio: Fix race against the error recovery URB submission
commit
9b7e5208a941e2e491a83eb5fa83d889e888fa2f upstream.
USB MIDI driver has an error recovery mechanism to resubmit the URB in
the delayed timer handler, and this may race with the standard start /
stop operations. Although both start and stop operations themselves
don't race with each other due to the umidi->mutex protection, but
this isn't applied to the timer handler.
For fixing this potential race, the following changes are applied:
- Since the timer handler can't use the mutex, we apply the
umidi->disc_lock protection at each input stream URB submission;
this also needs to change the GFP flag to GFP_ATOMIC
- Add a check of the URB refcount and skip if already submitted
- Move the timer cancel call at disconnection to the beginning of the
procedure; this assures the in-flight timer handler is gone properly
before killing all pending URBs
Reported-by: syzbot+0f4ecfe6a2c322c81728@syzkaller.appspotmail.com
Reported-by: syzbot+5f1d24c49c1d2c427497@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200710160656.16819-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Fri, 10 Jul 2020 13:33:51 +0000 (15:33 +0200)]
ALSA: line6: Perform sanity check for each URB creation
commit
6e8a914ad619042c5f25a4feb663357c4170fd8d upstream.
LINE6 drivers create stream URBs with a fixed pipe without checking
its validity, and this may lead to a kernel WARNING at the submission
when a malformed USB descriptor is passed.
For avoiding the kernel warning, perform the similar sanity checks for
each pipe type at creating a URB.
Reported-by: syzbot+c190f6858a04ea7fbc52@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/s5hv9iv4hq8.wl-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Wed, 4 Oct 2017 14:15:59 +0000 (16:15 +0200)]
usb: core: Add a helper function to check the validity of EP type in URB
commit
e901b9873876ca30a09253731bd3a6b00c44b5b0 upstream.
This patch adds a new helper function to perform a sanity check of the
given URB to see whether it contains a valid endpoint. It's a light-
weight version of what usb_submit_urb() does, but without the kernel
warning followed by the stack trace, just returns an error code.
Especially for a driver that doesn't parse the descriptor but fills
the URB with the fixed endpoint (e.g. some quirks for non-compliant
devices), this kind of check is preferable at the probe phase before
actually submitting the urb.
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Torokhov [Sun, 24 May 2020 23:51:34 +0000 (16:51 -0700)]
HID: magicmouse: do not set up autorepeat
commit
6363d2065cd399cf9d6dc9d08c437f8658831100 upstream.
Neither the trackpad, nor the mouse want input core to generate autorepeat
events for their buttons, so let's reset the bit (as hid-input sets it for
these devices based on the usage vendor code).
Cc: stable@vger.kernel.org
Reported-by: Yariv <oigevald+kernel@gmail.com>
Tested-by: Yariv <oigevald+kernel@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Álvaro Fernández Rojas [Fri, 22 May 2020 12:15:21 +0000 (14:15 +0200)]
mtd: rawnand: brcmnand: fix CS0 layout
commit
3d3fb3c5be9ce07fa85d8f67fb3922e4613b955b upstream.
Only v3.3-v5.0 have a different CS0 layout.
Controllers before v3.3 use the same layout for every CS.
Fixes:
27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller")
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200522121524.4161539-3-noltari@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jin Yao [Thu, 9 Apr 2020 07:07:55 +0000 (15:07 +0800)]
perf stat: Zero all the 'ena' and 'run' array slot stats for interval mode
commit
0e0bf1ea1147fcf74eab19c2d3c853cc3740a72f upstream.
As the code comments in perf_stat_process_counter() say, we calculate
counter's data every interval, and the display code shows ps->res_stats
avg value. We need to zero the stats for interval mode.
But the current code only zeros the res_stats[0], it doesn't zero the
res_stats[1] and res_stats[2], which are for ena and run of counter.
This patch zeros the whole res_stats[] for interval mode.
Fixes:
51fd2df1e882 ("perf stat: Fix interval output values")
Signed-off-by: Jin Yao <yao.jin@linux.intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Jin Yao <yao.jin@intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lore.kernel.org/lkml/20200409070755.17261-1-yao.jin@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Krzysztof Kozlowski [Fri, 26 Jun 2020 08:06:02 +0000 (10:06 +0200)]
ARM: dts: socfpga: Align L2 cache-controller nodename with dtschema
[ Upstream commit
d7adfe5ffed9faa05f8926223086b101e14f700d ]
Fix dtschema validator warnings like:
l2-cache@
fffff000: $nodename:0:
'l2-cache@
fffff000' does not match '^(cache-controller|cpu)(@[0-9a-f,]+)*$'
Fixes:
475dc86d08de ("arm: dts: socfpga: Add a base DTSI for Altera's Arria10 SOC")
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Enric Balletbo i Serra [Tue, 7 Jul 2020 10:34:12 +0000 (12:34 +0200)]
Revert "thermal: mediatek: fix register index error"
[ Upstream commit
a8f62f183021be389561570ab5f8c701a5e70298 ]
This reverts commit
eb9aecd90d1a39601e91cd08b90d5fee51d321a6
The above patch is supposed to fix a register index error on mt2701. It
is not clear if the problem solved is a hang or just an invalid value
returned, my guess is the second. The patch introduces, though, a new
hang on MT8173 device making them unusable. So, seems reasonable, revert
the patch because introduces a worst issue.
The reason I send a revert instead of trying to fix the issue for MT8173
is because the information needed to fix the issue is in the datasheet
and is not public. So I am not really able to fix it.
Fixes the following bug when CONFIG_MTK_THERMAL is set on MT8173
devices.
[ 2.222488] Unable to handle kernel paging request at virtual address
ffff8000125f5001
[ 2.230421] Mem abort info:
[ 2.233207] ESR = 0x96000021
[ 2.236261] EC = 0x25: DABT (current EL), IL = 32 bits
[ 2.241571] SET = 0, FnV = 0
[ 2.244623] EA = 0, S1PTW = 0
[ 2.247762] Data abort info:
[ 2.250640] ISV = 0, ISS = 0x00000021
[ 2.254473] CM = 0, WnR = 0
[ 2.257544] swapper pgtable: 4k pages, 48-bit VAs, pgdp=
0000000041850000
[ 2.264251] [
ffff8000125f5001] pgd=
000000013ffff003, pud=
000000013fffe003, pmd=
000000013fff9003, pte=
006800001100b707
[ 2.274867] Internal error: Oops:
96000021 [#1] PREEMPT SMP
[ 2.280432] Modules linked in:
[ 2.283483] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc6+ #162
[ 2.289914] Hardware name: Google Elm (DT)
[ 2.294003] pstate:
20000005 (nzCv daif -PAN -UAO)
[ 2.298792] pc : mtk_read_temp+0xb8/0x1c8
[ 2.302793] lr : mtk_read_temp+0x7c/0x1c8
[ 2.306794] sp :
ffff80001003b930
[ 2.310100] x29:
ffff80001003b930 x28:
0000000000000000
[ 2.315404] x27:
0000000000000002 x26:
ffff0000f9550b10
[ 2.320709] x25:
ffff0000f9550a80 x24:
0000000000000090
[ 2.326014] x23:
ffff80001003ba24 x22:
00000000610344c0
[ 2.331318] x21:
0000000000002710 x20:
00000000000001f4
[ 2.336622] x19:
0000000000030d40 x18:
ffff800011742ec0
[ 2.341926] x17:
0000000000000001 x16:
0000000000000001
[ 2.347230] x15:
ffffffffffffffff x14:
ffffff0000000000
[ 2.352535] x13:
ffffffffffffffff x12:
0000000000000028
[ 2.357839] x11:
0000000000000003 x10:
ffff800011295ec8
[ 2.363143] x9 :
000000000000291b x8 :
0000000000000002
[ 2.368447] x7 :
00000000000000a8 x6 :
0000000000000004
[ 2.373751] x5 :
0000000000000000 x4 :
ffff800011295cb0
[ 2.379055] x3 :
0000000000000002 x2 :
ffff8000125f5001
[ 2.384359] x1 :
0000000000000001 x0 :
ffff0000f9550a80
[ 2.389665] Call trace:
[ 2.392105] mtk_read_temp+0xb8/0x1c8
[ 2.395760] of_thermal_get_temp+0x2c/0x40
[ 2.399849] thermal_zone_get_temp+0x78/0x160
[ 2.404198] thermal_zone_device_update.part.0+0x3c/0x1f8
[ 2.409589] thermal_zone_device_update+0x34/0x48
[ 2.414286] of_thermal_set_mode+0x58/0x88
[ 2.418375] thermal_zone_of_sensor_register+0x1a8/0x1d8
[ 2.423679] devm_thermal_zone_of_sensor_register+0x64/0xb0
[ 2.429242] mtk_thermal_probe+0x690/0x7d0
[ 2.433333] platform_drv_probe+0x5c/0xb0
[ 2.437335] really_probe+0xe4/0x448
[ 2.440901] driver_probe_device+0xe8/0x140
[ 2.445077] device_driver_attach+0x7c/0x88
[ 2.449252] __driver_attach+0xac/0x178
[ 2.453082] bus_for_each_dev+0x78/0xc8
[ 2.456909] driver_attach+0x2c/0x38
[ 2.460476] bus_add_driver+0x14c/0x230
[ 2.464304] driver_register+0x6c/0x128
[ 2.468131] __platform_driver_register+0x50/0x60
[ 2.472831] mtk_thermal_driver_init+0x24/0x30
[ 2.477268] do_one_initcall+0x50/0x298
[ 2.481098] kernel_init_freeable+0x1ec/0x264
[ 2.485450] kernel_init+0x1c/0x110
[ 2.488931] ret_from_fork+0x10/0x1c
[ 2.492502] Code:
f9401081 f9400402 b8a67821 8b010042 (
b9400042)
[ 2.498599] ---[ end trace
e43e3105ed27dc99 ]---
[ 2.503367] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 2.511020] SMP: stopping secondary CPUs
[ 2.514941] Kernel Offset: disabled
[ 2.518421] CPU features: 0x090002,
25006005
[ 2.522595] Memory Limit: none
[ 2.525644] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--
Cc: Michael Kao <michael.kao@mediatek.com>
Fixes:
eb9aecd90d1a ("thermal: mediatek: fix register index error")
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200707103412.1010823-1-enric.balletbo@collabora.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Thu, 9 Jul 2020 10:29:36 +0000 (13:29 +0300)]
staging: comedi: verify array index is correct before using it
[ Upstream commit
ef75e14a6c935eec82abac07ab68e388514e39bc ]
This code reads from the array before verifying that "trig" is a valid
index. If the index is wildly out of bounds then reading from an
invalid address could lead to an Oops.
Fixes:
a8c66b684efa ("staging: comedi: addi_apci_1500: rewrite the subdevice support functions")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://lore.kernel.org/r/20200709102936.GA20875@mwanda
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michał Mirosław [Thu, 28 May 2020 18:35:54 +0000 (20:35 +0200)]
usb: gadget: udc: atmel: fix uninitialized read in debug printk
[ Upstream commit
30517ffeb3bff842e1355cbc32f1959d9dbb5414 ]
Fixed commit moved the assignment of 'req', but did not update a
reference in the DBG() call. Use the argument as it was renamed.
Fixes:
5fb694f96e7c ("usb: gadget: udc: atmel: fix possible oops when unloading module")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marc Kleine-Budde [Mon, 6 Jul 2020 14:34:34 +0000 (16:34 +0200)]
spi: spi-sun6i: sun6i_spi_transfer_one(): fix setting of clock rate
[ Upstream commit
ed7815db70d17b1741883f2da8e1d80bc2efe517 ]
A SPI transfer defines the _maximum_ speed of the SPI transfer. However the
driver doesn't take into account that the clock divider is always rounded down
(due to integer arithmetics). This results in a too high clock rate for the SPI
transfer.
E.g.: with a mclk_rate of 24 MHz and a SPI transfer speed of 10 MHz, the
original code calculates a reg of "0", which results in a effective divider of
"2" and a 12 MHz clock for the SPI transfer.
This patch fixes the issue by using DIV_ROUND_UP() instead of a plain
integer division.
While there simplify the divider calculation for the CDR1 case, use
order_base_2() instead of two ilog2() calculations.
Fixes:
3558fe900e8a ("spi: sunxi: Add Allwinner A31 SPI controller driver")
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/r/20200706143443.9855-2-mkl@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jonathan Cameron [Sun, 17 May 2020 17:29:57 +0000 (18:29 +0100)]
iio:health:afe4404 Fix timestamp alignment and prevent data leak.
[ Upstream commit
f88ecccac4be348bbcc6d056bdbc622a8955c04d ]
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses a 40 byte array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv() data with alignment
explicitly requested. This data is allocated with kzalloc so no
data can leak appart from previous readings.
Fixes:
87aec56e27ef ("iio: health: Add driver for the TI AFE4404 heart monitor")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sasha Levin [Fri, 17 Jul 2020 16:39:13 +0000 (12:39 -0400)]
Revert "usb/ohci-platform: Fix a warning when hibernating"
This reverts commit
104592a5233d77322c3e527e3925dc7c5a30a6af.
Eugeniu Rosca writes:
On Thu, Jul 09, 2020 at 09:00:23AM +0200, Eugeniu Rosca wrote:
>After integrating v4.14.186 commit
5410d158ca2a50 ("usb/ehci-platform:
>Set PM runtime as active on resume") into downstream v4.14.x, we started
>to consistently experience below panic [1] on every second s2ram of
>R-Car H3 Salvator-X Renesas reference board.
>
>After some investigations, we concluded the following:
> - the issue does not exist in vanilla v5.8-rc4+
> - [bisecting shows that] the panic on v4.14.186 is caused by the lack
> of v5.6-rc1 commit
987351e1ea7772 ("phy: core: Add consumer device
> link support"). Getting evidence for that is easy. Reverting
>
987351e1ea7772 in vanilla leads to a similar backtrace [2].
>
>Questions:
> - Backporting
987351e1ea7772 ("phy: core: Add consumer device
> link support") to v4.14.187 looks challenging enough, so probably not
> worth it. Anybody to contradict this?
> - Assuming no plans to backport the missing mainline commit to v4.14.x,
> should the following three v4.14.186 commits be reverted on v4.14.x?
> *
baef809ea497a4 ("usb/ohci-platform: Fix a warning when hibernating")
> *
9f33eff4958885 ("usb/xhci-plat: Set PM runtime as active on resume")
> *
5410d158ca2a50 ("usb/ehci-platform: Set PM runtime as active on resume")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sasha Levin [Fri, 17 Jul 2020 16:38:19 +0000 (12:38 -0400)]
Revert "usb/xhci-plat: Set PM runtime as active on resume"
This reverts commit
9e148a5e5e0929a4cb3000de9c843a07508ce575.
Eugeniu Rosca writes:
On Thu, Jul 09, 2020 at 09:00:23AM +0200, Eugeniu Rosca wrote:
>After integrating v4.14.186 commit
5410d158ca2a50 ("usb/ehci-platform:
>Set PM runtime as active on resume") into downstream v4.14.x, we started
>to consistently experience below panic [1] on every second s2ram of
>R-Car H3 Salvator-X Renesas reference board.
>
>After some investigations, we concluded the following:
> - the issue does not exist in vanilla v5.8-rc4+
> - [bisecting shows that] the panic on v4.14.186 is caused by the lack
> of v5.6-rc1 commit
987351e1ea7772 ("phy: core: Add consumer device
> link support"). Getting evidence for that is easy. Reverting
>
987351e1ea7772 in vanilla leads to a similar backtrace [2].
>
>Questions:
> - Backporting
987351e1ea7772 ("phy: core: Add consumer device
> link support") to v4.14.187 looks challenging enough, so probably not
> worth it. Anybody to contradict this?
> - Assuming no plans to backport the missing mainline commit to v4.14.x,
> should the following three v4.14.186 commits be reverted on v4.14.x?
> *
baef809ea497a4 ("usb/ohci-platform: Fix a warning when hibernating")
> *
9f33eff4958885 ("usb/xhci-plat: Set PM runtime as active on resume")
> *
5410d158ca2a50 ("usb/ehci-platform: Set PM runtime as active on resume")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sasha Levin [Fri, 17 Jul 2020 16:36:52 +0000 (12:36 -0400)]
Revert "usb/ehci-platform: Set PM runtime as active on resume"
This reverts commit
5365fc3132a36a027fd7c2bb461e651b37f1e4d1.
Eugeniu Rosca writes:
On Thu, Jul 09, 2020 at 09:00:23AM +0200, Eugeniu Rosca wrote:
>After integrating v4.14.186 commit
5410d158ca2a50 ("usb/ehci-platform:
>Set PM runtime as active on resume") into downstream v4.14.x, we started
>to consistently experience below panic [1] on every second s2ram of
>R-Car H3 Salvator-X Renesas reference board.
>
>After some investigations, we concluded the following:
> - the issue does not exist in vanilla v5.8-rc4+
> - [bisecting shows that] the panic on v4.14.186 is caused by the lack
> of v5.6-rc1 commit
987351e1ea7772 ("phy: core: Add consumer device
> link support"). Getting evidence for that is easy. Reverting
>
987351e1ea7772 in vanilla leads to a similar backtrace [2].
>
>Questions:
> - Backporting
987351e1ea7772 ("phy: core: Add consumer device
> link support") to v4.14.187 looks challenging enough, so probably not
> worth it. Anybody to contradict this?
> - Assuming no plans to backport the missing mainline commit to v4.14.x,
> should the following three v4.14.186 commits be reverted on v4.14.x?
> *
baef809ea497a4 ("usb/ohci-platform: Fix a warning when hibernating")
> *
9f33eff4958885 ("usb/xhci-plat: Set PM runtime as active on resume")
> *
5410d158ca2a50 ("usb/ehci-platform: Set PM runtime as active on resume")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Florian Fainelli [Thu, 18 Jun 2020 03:42:44 +0000 (20:42 -0700)]
net: dsa: bcm_sf2: Fix node reference count
[ Upstream commit
8dbe4c5d5e40fe140221024f7b16bec9f310bf70 ]
of_find_node_by_name() will do an of_node_put() on the "from" argument.
With CONFIG_OF_DYNAMIC enabled which checks for device_node reference
counts, we would be getting a warning like this:
[ 6.347230] refcount_t: increment on 0; use-after-free.
[ 6.352498] WARNING: CPU: 3 PID: 77 at lib/refcount.c:156
refcount_inc_checked+0x38/0x44
[ 6.360601] Modules linked in:
[ 6.363661] CPU: 3 PID: 77 Comm: kworker/3:1 Tainted: G W
5.4.46-gb78b3e9956e6 #13
[ 6.372546] Hardware name: BCM97278SV (DT)
[ 6.376649] Workqueue: events deferred_probe_work_func
[ 6.381796] pstate:
60000005 (nZCv daif -PAN -UAO)
[ 6.386595] pc : refcount_inc_checked+0x38/0x44
[ 6.391133] lr : refcount_inc_checked+0x38/0x44
...
[ 6.478791] Call trace:
[ 6.481243] refcount_inc_checked+0x38/0x44
[ 6.485433] kobject_get+0x3c/0x4c
[ 6.488840] of_node_get+0x24/0x34
[ 6.492247] of_irq_find_parent+0x3c/0xe0
[ 6.496263] of_irq_parse_one+0xe4/0x1d0
[ 6.500191] irq_of_parse_and_map+0x44/0x84
[ 6.504381] bcm_sf2_sw_probe+0x22c/0x844
[ 6.508397] platform_drv_probe+0x58/0xa8
[ 6.512413] really_probe+0x238/0x3fc
[ 6.516081] driver_probe_device+0x11c/0x12c
[ 6.520358] __device_attach_driver+0xa8/0x100
[ 6.524808] bus_for_each_drv+0xb4/0xd0
[ 6.528650] __device_attach+0xd0/0x164
[ 6.532493] device_initial_probe+0x24/0x30
[ 6.536682] bus_probe_device+0x38/0x98
[ 6.540524] deferred_probe_work_func+0xa8/0xd4
[ 6.545061] process_one_work+0x178/0x288
[ 6.549078] process_scheduled_works+0x44/0x48
[ 6.553529] worker_thread+0x218/0x270
[ 6.557285] kthread+0xdc/0xe4
[ 6.560344] ret_from_fork+0x10/0x18
[ 6.563925] ---[ end trace
68f65caf69bb152a ]---
Fix this by adding a of_node_get() to increment the reference count
prior to the call.
Fixes:
afa3b592953b ("net: dsa: bcm_sf2: Ensure correct sub-node is parsed")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Angelo Dureghello [Wed, 26 Dec 2018 21:45:06 +0000 (22:45 +0100)]
spi: fix initial SPI_SR value in spi-fsl-dspi
[ Upstream commit
aa54c1c9d90e6db75190813907190fadcce1bf45 ]
On ColdFire mcf54418, using DSPI_DMA_MODE mode, spi transfers
at first boot stage are not succeding:
m25p80 spi0.1: unrecognized JEDEC id bytes: 00, 00, 00
The reason is the SPI_SR initial value set by the driver, that
is not clearing (not setting to 1) the RF_DF flag. After a tour
on the dspi hw modules that use this driver(Vybrid, ColdFire and
ls1021a) a better init value for SR register has been set.
Signed-off-by: Angelo Dureghello <angelo@sysam.it>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jonathan Cameron [Sun, 17 May 2020 17:29:56 +0000 (18:29 +0100)]
iio:health:afe4403 Fix timestamp alignment and prevent data leak.
commit
3f9c6d38797e9903937b007a341dad0c251765d6 upstream.
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses a 32 byte array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv() data with alignment
explicitly requested. This data is allocated with kzalloc so no
data can leak appart from previous readings.
Fixes:
eec96d1e2d31 ("iio: health: Add driver for the TI AFE4403 heart monitor")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Andrew F. Davis <afd@ti.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan Cameron [Sun, 7 Jun 2020 15:53:57 +0000 (16:53 +0100)]
iio:pressure:ms5611 Fix buffer element alignment
commit
8db4afe163bbdd93dca6fcefbb831ef12ecc6b4d upstream.
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
Here there is no data leak possibility so use an explicit structure
on the stack to ensure alignment and nice readable fashion.
The forced alignment of ts isn't strictly necessary in this driver
as the padding will be correct anyway (there isn't any). However
it is probably less fragile to have it there and it acts as
documentation of the requirement.
Fixes:
713bbb4efb9dc ("iio: pressure: ms5611: Add triggered buffer support")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Tomasz Duszynski <tomasz.duszynski@octakon.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Navid Emamdoost [Fri, 5 Jun 2020 02:44:44 +0000 (21:44 -0500)]
iio: pressure: zpa2326: handle pm_runtime_get_sync failure
commit
d88de040e1df38414fc1e4380be9d0e997ab4d58 upstream.
Calling pm_runtime_get_sync increments the counter even in case of
failure, causing incorrect ref count. Call pm_runtime_put if
pm_runtime_get_sync fails.
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Fixes:
03b262f2bbf4 ("iio:pressure: initial zpa2326 barometer support")
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chuhong Yuan [Thu, 28 May 2020 06:41:21 +0000 (14:41 +0800)]
iio: mma8452: Add missed iio_device_unregister() call in mma8452_probe()
commit
d7369ae1f4d7cffa7574d15e1f787dcca184c49d upstream.
The function iio_device_register() was called in mma8452_probe().
But the function iio_device_unregister() was not called after
a call of the function mma8452_set_freefall_mode() failed.
Thus add the missed function call for one error case.
Fixes:
1a965d405fc6 ("drivers:iio:accel:mma8452: added cleanup provision in case of failure.")
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dinghao Liu [Tue, 26 May 2020 10:47:17 +0000 (18:47 +0800)]
iio: magnetometer: ak8974: Fix runtime PM imbalance on error
commit
0187294d227dfc42889e1da8f8ce1e44fc25f147 upstream.
When devm_regmap_init_i2c() returns an error code, a pairing
runtime PM usage counter decrement is needed to keep the
counter balanced. For error paths after ak8974_set_power(),
ak8974_detect() and ak8974_reset(), things are the same.
However, When iio_triggered_buffer_setup() returns an error
code, there will be two PM usgae counter decrements.
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Fixes:
7c94a8b2ee8c ("iio: magn: add a driver for AK8974")
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>