commit 0e446529d34888ac57fe059ec32e9114a381c800 Author: Greg Kroah-Hartman Date: Tue Aug 11 15:35:42 2020 +0200 Linux 5.7.15 Tested-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman commit ab5dd525532ea1246395c88337b9451224874a60 Author: Guenter Roeck Date: Fri Aug 7 07:45:21 2020 -0700 arm64: kaslr: Use standard early random function commit 9bceb80b3cc483e6763c39a4928402fa82815d3e upstream. Commit 585524081ecd ("random: random.h should include archrandom.h, not the other way around") tries to fix a problem with recursive inclusion of linux/random.h and arch/archrandom.h for arm64. Unfortunately, this results in the following compile error if ARCH_RANDOM is disabled. arch/arm64/kernel/kaslr.c: In function 'kaslr_early_init': arch/arm64/kernel/kaslr.c:128:6: error: implicit declaration of function '__early_cpu_has_rndr'; did you mean '__early_pfn_to_nid'? [-Werror=implicit-function-declaration] if (__early_cpu_has_rndr()) { ^~~~~~~~~~~~~~~~~~~~ __early_pfn_to_nid arch/arm64/kernel/kaslr.c:131:7: error: implicit declaration of function '__arm64_rndr' [-Werror=implicit-function-declaration] if (__arm64_rndr(&raw)) ^~~~~~~~~~~~ The problem is that arch/archrandom.h is only included from linux/random.h if ARCH_RANDOM is enabled. If not, __arm64_rndr() and __early_cpu_has_rndr() are undeclared, causing the problem. Use arch_get_random_seed_long_early() instead of arm64 specific functions to solve the problem. Reported-by: Qian Cai Fixes: 585524081ecd ("random: random.h should include archrandom.h, not the other way around") Cc: Qian Cai Cc: Mark Brown Reviewed-by: Mark Rutland Reviewed-by: Mark Brown Tested-by: Mark Brown Signed-off-by: Guenter Roeck Signed-off-by: Linus Torvalds Cc: Sedat Dilek Signed-off-by: Greg Kroah-Hartman commit 4efe0ff1c84660710d45e00a52d07a1d9fde0de7 Author: Bruno Meneguele Date: Mon Jul 13 13:48:30 2020 -0300 ima: move APPRAISE_BOOTPARAM dependency on ARCH_POLICY to runtime commit 311aa6aafea446c2f954cc19d66425bfed8c4b0b upstream. The IMA_APPRAISE_BOOTPARAM config allows enabling different "ima_appraise=" modes - log, fix, enforce - at run time, but not when IMA architecture specific policies are enabled.  This prevents properly labeling the filesystem on systems where secure boot is supported, but not enabled on the platform.  Only when secure boot is actually enabled should these IMA appraise modes be disabled. This patch removes the compile time dependency and makes it a runtime decision, based on the secure boot state of that platform. Test results as follows: -> x86-64 with secure boot enabled [ 0.015637] Kernel command line: <...> ima_policy=appraise_tcb ima_appraise=fix [ 0.015668] ima: Secure boot enabled: ignoring ima_appraise=fix boot parameter option -> powerpc with secure boot disabled [ 0.000000] Kernel command line: <...> ima_policy=appraise_tcb ima_appraise=fix [ 0.000000] Secure boot mode disabled -> Running the system without secure boot and with both options set: CONFIG_IMA_APPRAISE_BOOTPARAM=y CONFIG_IMA_ARCH_POLICY=y Audit prompts "missing-hash" but still allow execution and, consequently, filesystem labeling: type=INTEGRITY_DATA msg=audit(07/09/2020 12:30:27.778:1691) : pid=4976 uid=root auid=root ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op=appraise_data cause=missing-hash comm=bash name=/usr/bin/evmctl dev="dm-0" ino=493150 res=no Cc: stable@vger.kernel.org Fixes: d958083a8f64 ("x86/ima: define arch_get_ima_policy() for x86") Signed-off-by: Bruno Meneguele Cc: stable@vger.kernel.org # 5.0 Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit db74b6228662288b15b3e1a05ab650385beb060d Author: Paolo Abeni Date: Mon Aug 3 18:40:39 2020 +0200 mptcp: fix bogus sendmsg() return code under pressure [ Upstream commit 8555c6bfd5fddb1cf363d3cd157d70a1bb27f718 ] In case of memory pressure, mptcp_sendmsg() may call sk_stream_wait_memory() after succesfully xmitting some bytes. If the latter fails we currently return to the user-space the error code, ignoring the succeful xmit. Address the issue always checking for the xmitted bytes before mptcp_sendmsg() completes. Fixes: f296234c98a8 ("mptcp: Add handling of incoming MP_JOIN requests") Reviewed-by: Matthieu Baerts Signed-off-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 81ffffd52fb24439946c9949ec6a71bedc6b9bcb Author: Paolo Abeni Date: Tue Aug 4 18:31:06 2020 +0200 mptcp: be careful on subflow creation [ Upstream commit adf7341064982de923a1f8a11bcdec48be6b3004 ] Nicolas reported the following oops: [ 1521.392541] BUG: kernel NULL pointer dereference, address: 00000000000000c0 [ 1521.394189] #PF: supervisor read access in kernel mode [ 1521.395376] #PF: error_code(0x0000) - not-present page [ 1521.396607] PGD 0 P4D 0 [ 1521.397156] Oops: 0000 [#1] SMP PTI [ 1521.398020] CPU: 0 PID: 22986 Comm: kworker/0:2 Not tainted 5.8.0-rc4+ #109 [ 1521.399618] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 [ 1521.401728] Workqueue: events mptcp_worker [ 1521.402651] RIP: 0010:mptcp_subflow_create_socket+0xf1/0x1c0 [ 1521.403954] Code: 24 08 89 44 24 04 48 8b 7a 18 e8 2a 48 d4 ff 8b 44 24 04 85 c0 75 7a 48 8b 8b 78 02 00 00 48 8b 54 24 08 48 8d bb 80 00 00 00 <48> 8b 89 c0 00 00 00 48 89 8a c0 00 00 00 48 8b 8b 78 02 00 00 8b [ 1521.408201] RSP: 0000:ffffabc4002d3c60 EFLAGS: 00010246 [ 1521.409433] RAX: 0000000000000000 RBX: ffffa0b9ad8c9a00 RCX: 0000000000000000 [ 1521.411096] RDX: ffffa0b9ae78a300 RSI: 00000000fffffe01 RDI: ffffa0b9ad8c9a80 [ 1521.412734] RBP: ffffa0b9adff2e80 R08: ffffa0b9af02d640 R09: ffffa0b9ad923a00 [ 1521.414333] R10: ffffabc4007139f8 R11: fefefefefefefeff R12: ffffabc4002d3cb0 [ 1521.415918] R13: ffffa0b9ad91fa58 R14: ffffa0b9ad8c9f9c R15: 0000000000000000 [ 1521.417592] FS: 0000000000000000(0000) GS:ffffa0b9af000000(0000) knlGS:0000000000000000 [ 1521.419490] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1521.420839] CR2: 00000000000000c0 CR3: 000000002951e006 CR4: 0000000000160ef0 [ 1521.422511] Call Trace: [ 1521.423103] __mptcp_subflow_connect+0x94/0x1f0 [ 1521.425376] mptcp_pm_create_subflow_or_signal_addr+0x200/0x2a0 [ 1521.426736] mptcp_worker+0x31b/0x390 [ 1521.431324] process_one_work+0x1fc/0x3f0 [ 1521.432268] worker_thread+0x2d/0x3b0 [ 1521.434197] kthread+0x117/0x130 [ 1521.435783] ret_from_fork+0x22/0x30 on some unconventional configuration. The MPTCP protocol is trying to create a subflow for an unaccepted server socket. That is allowed by the RFC, even if subflow creation will likely fail. Unaccepted sockets have still a NULL sk_socket field, avoid the issue by failing earlier. Reported-and-tested-by: Nicolas Rybowski Fixes: 7d14b0d2b9b3 ("mptcp: set correct vfs info for subflows") Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4880b3091b49ee7c3799ec0dde5f61f6f90ccda6 Author: Jianfeng Wang Date: Thu Jul 30 23:49:16 2020 +0000 tcp: apply a floor of 1 for RTT samples from TCP timestamps [ Upstream commit 730e700e2c19d87e578ff0e7d8cb1d4a02b036d2 ] For retransmitted packets, TCP needs to resort to using TCP timestamps for computing RTT samples. In the common case where the data and ACK fall in the same 1-millisecond interval, TCP senders with millisecond- granularity TCP timestamps compute a ca_rtt_us of 0. This ca_rtt_us of 0 propagates to rs->rtt_us. This value of 0 can cause performance problems for congestion control modules. For example, in BBR, the zero min_rtt sample can bring the min_rtt and BDP estimate down to 0, reduce snd_cwnd and result in a low throughput. It would be hard to mitigate this with filtering in the congestion control module, because the proper floor to apply would depend on the method of RTT sampling (using timestamp options or internally-saved transmission timestamps). This fix applies a floor of 1 for the RTT sample delta from TCP timestamps, so that seq_rtt_us, ca_rtt_us, and rs->rtt_us will be at least 1 * (USEC_PER_SEC / TCP_TS_HZ). Note that the receiver RTT computation in tcp_rcv_rtt_measure() and min_rtt computation in tcp_update_rtt_min() both already apply a floor of 1 timestamp tick, so this commit makes the code more consistent in avoiding this edge case of a value of 0. Signed-off-by: Jianfeng Wang Signed-off-by: Neal Cardwell Signed-off-by: Eric Dumazet Acked-by: Kevin Yang Acked-by: Yuchung Cheng Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d5d9d2a5c2e448bb97392a001d18c9c70523df7c Author: Willem de Bruijn Date: Wed Aug 5 04:40:45 2020 -0400 selftests/net: relax cpu affinity requirement in msg_zerocopy test [ Upstream commit 16f6458f2478b55e2b628797bc81a4455045c74e ] The msg_zerocopy test pins the sender and receiver threads to separate cores to reduce variance between runs. But it hardcodes the cores and skips core 0, so it fails on machines with the selected cores offline, or simply fewer cores. The test mainly gives code coverage in automated runs. The throughput of zerocopy ('-z') and non-zerocopy runs is logged for manual inspection. Continue even when sched_setaffinity fails. Just log to warn anyone interpreting the data. Fixes: 07b65c5b31ce ("test: add msg_zerocopy test") Reported-by: Colin Ian King Signed-off-by: Willem de Bruijn Acked-by: Colin Ian King Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 81b1d29ea366722f4c928656c4fbd78f2fd55d3e Author: Hangbin Liu Date: Wed Aug 5 10:41:31 2020 +0800 Revert "vxlan: fix tos value before xmit" [ Upstream commit a0dced17ad9dc08b1b25e0065b54c97a318e6e8b ] This reverts commit 71130f29979c7c7956b040673e6b9d5643003176. In commit 71130f29979c ("vxlan: fix tos value before xmit") we want to make sure the tos value are filtered by RT_TOS() based on RFC1349. 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | PRECEDENCE | TOS | MBZ | +-----+-----+-----+-----+-----+-----+-----+-----+ But RFC1349 has been obsoleted by RFC2474. The new DSCP field defined like 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | DS FIELD, DSCP | ECN FIELD | +-----+-----+-----+-----+-----+-----+-----+-----+ So with IPTOS_TOS_MASK 0x1E RT_TOS(tos) ((tos)&IPTOS_TOS_MASK) the first 3 bits DSCP info will get lost. To take all the DSCP info in xmit, we should revert the patch and just push all tos bits to ip_tunnel_ecn_encap(), which will handling ECN field later. Fixes: 71130f29979c ("vxlan: fix tos value before xmit") Signed-off-by: Hangbin Liu Acked-by: Guillaume Nault Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0599307728f96b722464d0e35489916ba06acac1 Author: Peilin Ye Date: Fri Jul 31 00:48:38 2020 -0400 openvswitch: Prevent kernel-infoleak in ovs_ct_put_key() [ Upstream commit 9aba6c5b49254d5bee927d81593ed4429e91d4ae ] ovs_ct_put_key() is potentially copying uninitialized kernel stack memory into socket buffers, since the compiler may leave a 3-byte hole at the end of `struct ovs_key_ct_tuple_ipv4` and `struct ovs_key_ct_tuple_ipv6`. Fix it by initializing `orig` with memset(). Fixes: 9dd7f8907c37 ("openvswitch: Add original direction conntrack tuple to sw_flow_key.") Suggested-by: Dan Carpenter Signed-off-by: Peilin Ye Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 45e69b071f00d7e7c0bb29c7cda5d091beb99691 Author: Xin Long Date: Tue Aug 4 15:02:30 2020 +0800 net: thunderx: use spin_lock_bh in nicvf_set_rx_mode_task() [ Upstream commit bab9693a9a8c6dd19f670408ec1e78e12a320682 ] A dead lock was triggered on thunderx driver: CPU0 CPU1 ---- ---- [01] lock(&(&nic->rx_mode_wq_lock)->rlock); [11] lock(&(&mc->mca_lock)->rlock); [12] lock(&(&nic->rx_mode_wq_lock)->rlock); [02] lock(&(&mc->mca_lock)->rlock); The path for each is: [01] worker_thread() -> process_one_work() -> nicvf_set_rx_mode_task() [02] mld_ifc_timer_expire() [11] ipv6_add_dev() -> ipv6_dev_mc_inc() -> igmp6_group_added() -> [12] dev_mc_add() -> __dev_set_rx_mode() -> nicvf_set_rx_mode() To fix it, it needs to disable bh on [1], so that the timer on [2] wouldn't be triggered until rx_mode_wq_lock is released. So change to use spin_lock_bh() instead of spin_lock(). Thanks to Paolo for helping with this. v1->v2: - post to netdev. Reported-by: Rafael P. Tested-by: Dean Nelson Fixes: 469998c861fa ("net: thunderx: prevent concurrent data re-writing by nicvf_set_rx_mode") Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7154bda4cfc1f41b339121475d2b0234141f3492 Author: wenxu Date: Fri Jul 31 10:45:01 2020 +0800 net/sched: act_ct: fix miss set mru for ovs after defrag in act_ct [ Upstream commit 038ebb1a713d114d54dbf14868a73181c0c92758 ] When openvswitch conntrack offload with act_ct action. Fragment packets defrag in the ingress tc act_ct action and miss the next chain. Then the packet pass to the openvswitch datapath without the mru. The over mtu packet will be dropped in output action in openvswitch for over mtu. "kernel: net2: dropped over-mtu packet: 1528 > 1500" This patch add mru in the tc_skb_ext for adefrag and miss next chain situation. And also add mru in the qdisc_skb_cb. The act_ct set the mru to the qdisc_skb_cb when the packet defrag. And When the chain miss, The mru is set to tc_skb_ext which can be got by ovs datapath. Fixes: b57dc7c13ea9 ("net/sched: Introduce action ct") Signed-off-by: wenxu Reviewed-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 95a936364f2685e9e040c6b179b553604d96de22 Author: Lorenzo Bianconi Date: Fri Jul 31 10:38:32 2020 +0200 net: mvpp2: fix memory leak in mvpp2_rx [ Upstream commit d6526926de7397a97308780911565e31a6b67b59 ] Release skb memory in mvpp2_rx() if mvpp2_rx_refill routine fails Fixes: b5015854674b ("net: mvpp2: fix refilling BM pools in RX path") Signed-off-by: Lorenzo Bianconi Acked-by: Matteo Croce Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 25820a4435aaa87d98941e038112463e72eff06b Author: Stefan Roese Date: Tue Aug 4 14:17:16 2020 +0200 net: macb: Properly handle phylink on at91sam9x [ Upstream commit f7ba7dbf4f7af67b5936ff1cbd40a3254b409ebf ] I just recently noticed that ethernet does not work anymore since v5.5 on the GARDENA smart Gateway, which is based on the AT91SAM9G25. Debugging showed that the "GEM bits" in the NCFGR register are now unconditionally accessed, which is incorrect for the !macb_is_gem() case. This patch adds the macb_is_gem() checks back to the code (in macb_mac_config() & macb_mac_link_up()), so that the GEM register bits are not accessed in this case any more. Fixes: 7897b071ac3b ("net: macb: convert to phylink") Signed-off-by: Stefan Roese Cc: Reto Schneider Cc: Alexandre Belloni Cc: Nicolas Ferre Cc: David S. Miller Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a95ef2ddfdb091e136e997c7d8f6812803a8eef8 Author: Lorenzo Bianconi Date: Fri Jul 31 20:12:05 2020 +0200 net: gre: recompute gre csum for sctp over gre tunnels [ Upstream commit 622e32b7d4a6492cf5c1f759ef833f817418f7b3 ] The GRE tunnel can be used to transport traffic that does not rely on a Internet checksum (e.g. SCTP). The issue can be triggered creating a GRE or GRETAP tunnel and transmitting SCTP traffic ontop of it where CRC offload has been disabled. In order to fix the issue we need to recompute the GRE csum in gre_gso_segment() not relying on the inner checksum. The issue is still present when we have the CRC offload enabled. In this case we need to disable the CRC offload if we require GRE checksum since otherwise skb_checksum() will report a wrong value. Fixes: 90017accff61 ("sctp: Add GSO support") Signed-off-by: Lorenzo Bianconi Reviewed-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a8997ea05a35b9925ac48f9d2eaeb7d5aad93f71 Author: Nikolay Aleksandrov Date: Fri Jul 31 19:26:16 2020 +0300 net: bridge: clear bridge's private skb space on xmit [ Upstream commit fd65e5a95d08389444e8591a20538b3edece0e15 ] We need to clear all of the bridge private skb variables as they can be stale due to the packet being recirculated through the stack and then transmitted through the bridge device. Similar memset is already done on bridge's input. We've seen cases where proxyarp_replied was 1 on routed multicast packets transmitted through the bridge to ports with neigh suppress which were getting dropped. Same thing can in theory happen with the port isolation bit as well. Fixes: 821f1b21cabb ("bridge: add new BR_NEIGH_SUPPRESS port flag to suppress arp and nd flood") Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b9ce61f71ecb7070f8063d90856bc4be2aefaab6 Author: Stephen Hemminger Date: Tue Aug 4 09:54:15 2020 -0700 hv_netvsc: do not use VF device if link is down [ Upstream commit 7c9864bbccc23e1812ac82966555d68c13ea4006 ] If the accelerated networking SRIOV VF device has lost carrier use the synthetic network device which is available as backup path. This is a rare case since if VF link goes down, normally the VMBus device will also loose external connectivity as well. But if the communication is between two VM's on the same host the VMBus device will still work. Reported-by: "Shah, Ashish N" Fixes: 0c195567a8f6 ("netvsc: transparent VF management") Signed-off-by: Stephen Hemminger Reviewed-by: Haiyang Zhang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bbf027c851b37b59791396d908c578dba89d3c45 Author: YueHaibing Date: Tue Aug 4 21:26:43 2020 +0800 dpaa2-eth: Fix passing zero to 'PTR_ERR' warning [ Upstream commit 02afa9c66bb954c6959877c70d9e128dcf0adce7 ] Fix smatch warning: drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c:2419 alloc_channel() warn: passing zero to 'ERR_PTR' setup_dpcon() should return ERR_PTR(err) instead of zero in error handling case. Fixes: d7f5a9d89a55 ("dpaa2-eth: defer probe on object allocate") Signed-off-by: YueHaibing Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0dcff59f4582ce9e0bc60729bd97ffec711b7704 Author: Vincent Duvert Date: Sun Aug 2 07:06:51 2020 +0200 appletalk: Fix atalk_proc_init() return path [ Upstream commit d0f6ba2ef2c1c95069509e71402e7d6d43452512 ] Add a missing return statement to atalk_proc_init so it doesn't return -ENOMEM when successful. This allows the appletalk module to load properly. Fixes: e2bcd8b0ce6e ("appletalk: use remove_proc_subtree to simplify procfs code") Link: https://www.downtowndougbrown.com/2020/08/hacking-up-a-fix-for-the-broken-appletalk-kernel-module-in-linux-5-1-and-newer/ Reported-by: Christopher KOBAYASHI Reported-by: Doug Brown Signed-off-by: Vincent Duvert [lukas: add missing tags] Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v5.1+ Cc: Yue Haibing Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f7747668cc5197f89de5dea42652c6010643acd1 Author: Jakub Kicinski Date: Tue Jul 28 16:15:07 2020 -0700 devlink: ignore -EOPNOTSUPP errors on dumpit [ Upstream commit 82274d075536322368ce710b211c41c37c4740b9 ] Number of .dumpit functions try to ignore -EOPNOTSUPP errors. Recent change missed that, and started reporting all errors but -EMSGSIZE back from dumps. This leads to situation like this: $ devlink dev info devlink answers: Operation not supported Dump should not report an error just because the last device to be queried could not provide an answer. To fix this and avoid similar confusion make sure we clear err properly, and not leave it set to an error if we don't terminate the iteration. Fixes: c62c2cfb801b ("net: devlink: don't ignore errors during dumpit") Signed-off-by: Jakub Kicinski Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ebd4edd83d43a70e5102f5f498d484f9806ac50c Author: Herbert Xu Date: Fri Jul 24 20:14:34 2020 +1000 rhashtable: Restore RCU marking on rhash_lock_head [ Upstream commit ce9b362bf6db51a083c4221ef0f93c16cfb1facf ] This patch restores the RCU marking on bucket_table->buckets as it really does need RCU protection. Its removal had led to a fatal bug. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 01f5ed845906f03b5c096f4451f9c90f8153c691 Author: Johan Hovold Date: Tue Jul 28 14:10:31 2020 +0200 net: lan78xx: replace bogus endpoint lookup [ Upstream commit ea060b352654a8de1e070140d25fe1b7e4d50310 ] Drop the bogus endpoint-lookup helper which could end up accepting interfaces based on endpoints belonging to unrelated altsettings. Note that the returned bulk pipes and interrupt endpoint descriptor were never actually used. Instead the bulk-endpoint numbers are hardcoded to 1 and 2 (matching the specification), while the interrupt- endpoint descriptor was assumed to be the third descriptor created by USB core. Try to bring some order to this by dropping the bogus lookup helper and adding the missing endpoint sanity checks while keeping the interrupt- descriptor assumption for now. Signed-off-by: Johan Hovold Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bb6ee7d1502470ca0665cc0d23961b233f5ac3fe Author: Ido Schimmel Date: Wed Jul 29 11:34:36 2020 +0300 vxlan: Ensure FDB dump is performed under RCU [ Upstream commit b5141915b5aec3b29a63db869229e3741ebce258 ] The commit cited below removed the RCU read-side critical section from rtnl_fdb_dump() which means that the ndo_fdb_dump() callback is invoked without RCU protection. This results in the following warning [1] in the VXLAN driver, which relied on the callback being invoked from an RCU read-side critical section. Fix this by calling rcu_read_lock() in the VXLAN driver, as already done in the bridge driver. [1] WARNING: suspicious RCU usage 5.8.0-rc4-custom-01521-g481007553ce6 #29 Not tainted ----------------------------- drivers/net/vxlan.c:1379 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by bridge/166: #0: ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0xea/0x1090 stack backtrace: CPU: 1 PID: 166 Comm: bridge Not tainted 5.8.0-rc4-custom-01521-g481007553ce6 #29 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014 Call Trace: dump_stack+0x100/0x184 lockdep_rcu_suspicious+0x153/0x15d vxlan_fdb_dump+0x51e/0x6d0 rtnl_fdb_dump+0x4dc/0xad0 netlink_dump+0x540/0x1090 __netlink_dump_start+0x695/0x950 rtnetlink_rcv_msg+0x802/0xbd0 netlink_rcv_skb+0x17a/0x480 rtnetlink_rcv+0x22/0x30 netlink_unicast+0x5ae/0x890 netlink_sendmsg+0x98a/0xf40 __sys_sendto+0x279/0x3b0 __x64_sys_sendto+0xe6/0x1a0 do_syscall_64+0x54/0xa0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fe14fa2ade0 Code: Bad RIP value. RSP: 002b:00007fff75bb5b88 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00005614b1ba0020 RCX: 00007fe14fa2ade0 RDX: 000000000000011c RSI: 00007fff75bb5b90 RDI: 0000000000000003 RBP: 00007fff75bb5b90 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00005614b1b89160 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Fixes: 5e6d24358799 ("bridge: netlink dump interface at par with brctl") Signed-off-by: Ido Schimmel Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1308ddf505aefcfebb7dd1f99ee74ed0ef94d4ad Author: David Howells Date: Wed Jul 29 00:03:56 2020 +0100 rxrpc: Fix race between recvmsg and sendmsg on immediate call failure [ Upstream commit 65550098c1c4db528400c73acf3e46bfa78d9264 ] There's a race between rxrpc_sendmsg setting up a call, but then failing to send anything on it due to an error, and recvmsg() seeing the call completion occur and trying to return the state to the user. An assertion fails in rxrpc_recvmsg() because the call has already been released from the socket and is about to be released again as recvmsg deals with it. (The recvmsg_q queue on the socket holds a ref, so there's no problem with use-after-free.) We also have to be careful not to end up reporting an error twice, in such a way that both returns indicate to userspace that the user ID supplied with the call is no longer in use - which could cause the client to malfunction if it recycles the user ID fast enough. Fix this by the following means: (1) When sendmsg() creates a call after the point that the call has been successfully added to the socket, don't return any errors through sendmsg(), but rather complete the call and let recvmsg() retrieve them. Make sendmsg() return 0 at this point. Further calls to sendmsg() for that call will fail with ESHUTDOWN. Note that at this point, we haven't send any packets yet, so the server doesn't yet know about the call. (2) If sendmsg() returns an error when it was expected to create a new call, it means that the user ID wasn't used. (3) Mark the call disconnected before marking it completed to prevent an oops in rxrpc_release_call(). (4) recvmsg() will then retrieve the error and set MSG_EOR to indicate that the user ID is no longer known by the kernel. An oops like the following is produced: kernel BUG at net/rxrpc/recvmsg.c:605! ... RIP: 0010:rxrpc_recvmsg+0x256/0x5ae ... Call Trace: ? __init_waitqueue_head+0x2f/0x2f ____sys_recvmsg+0x8a/0x148 ? import_iovec+0x69/0x9c ? copy_msghdr_from_user+0x5c/0x86 ___sys_recvmsg+0x72/0xaa ? __fget_files+0x22/0x57 ? __fget_light+0x46/0x51 ? fdget+0x9/0x1b do_recvmmsg+0x15e/0x232 ? _raw_spin_unlock+0xa/0xb ? vtime_delta+0xf/0x25 __x64_sys_recvmmsg+0x2c/0x2f do_syscall_64+0x4c/0x78 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 357f5ef64628 ("rxrpc: Call rxrpc_release_call() on error in rxrpc_new_client_call()") Reported-by: syzbot+b54969381df354936d96@syzkaller.appspotmail.com Signed-off-by: David Howells Reviewed-by: Marc Dionne Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3ea587758c21619582e1b566b3d7eca51522f585 Author: Xiyu Yang Date: Sat Jul 25 16:02:18 2020 +0800 ipv6: Fix nexthop refcnt leak when creating ipv6 route info [ Upstream commit 706ec919164622ff5ce822065472d0f30a9e9dd2 ] ip6_route_info_create() invokes nexthop_get(), which increases the refcount of the "nh". When ip6_route_info_create() returns, local variable "nh" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one exception handling path of ip6_route_info_create(). When nexthops can not be used with source routing, the function forgets to decrease the refcnt increased by nexthop_get(), causing a refcnt leak. Fix this issue by pulling up the error source routing handling when nexthops can not be used with source routing. Fixes: f88d8ea67fbd ("ipv6: Plumb support for nexthop object in a fib6_info") Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b3af432ff3e4dd6f4649e9f57db0ad7da4dd4fd5 Author: Cong Wang Date: Sat Jul 25 15:40:53 2020 -0700 ipv6: fix memory leaks on IPV6_ADDRFORM path [ Upstream commit 8c0de6e96c9794cb523a516c465991a70245da1c ] IPV6_ADDRFORM causes resource leaks when converting an IPv6 socket to IPv4, particularly struct ipv6_ac_socklist. Similar to struct ipv6_mc_socklist, we should just close it on this path. This bug can be easily reproduced with the following C program: #include #include #include #include #include int main() { int s, value; struct sockaddr_in6 addr; struct ipv6_mreq m6; s = socket(AF_INET6, SOCK_DGRAM, 0); addr.sin6_family = AF_INET6; addr.sin6_port = htons(5000); inet_pton(AF_INET6, "::ffff:192.168.122.194", &addr.sin6_addr); connect(s, (struct sockaddr *)&addr, sizeof(addr)); inet_pton(AF_INET6, "fe80::AAAA", &m6.ipv6mr_multiaddr); m6.ipv6mr_interface = 5; setsockopt(s, SOL_IPV6, IPV6_JOIN_ANYCAST, &m6, sizeof(m6)); value = AF_INET; setsockopt(s, SOL_IPV6, IPV6_ADDRFORM, &value, sizeof(value)); close(s); return 0; } Reported-by: ch3332xr@gmail.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3e44aaa77deb8bf2e4b519f87c05202857479895 Author: Ido Schimmel Date: Wed Jul 29 11:37:13 2020 +0300 ipv4: Silence suspicious RCU usage warning [ Upstream commit 83f3522860f702748143e022f1a546547314c715 ] fib_trie_unmerge() is called with RTNL held, but not from an RCU read-side critical section. This leads to the following warning [1] when the FIB alias list in a leaf is traversed with hlist_for_each_entry_rcu(). Since the function is always called with RTNL held and since modification of the list is protected by RTNL, simply use hlist_for_each_entry() and silence the warning. [1] WARNING: suspicious RCU usage 5.8.0-rc4-custom-01520-gc1f937f3f83b #30 Not tainted ----------------------------- net/ipv4/fib_trie.c:1867 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/164: #0: ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x49a/0xbd0 stack backtrace: CPU: 0 PID: 164 Comm: ip Not tainted 5.8.0-rc4-custom-01520-gc1f937f3f83b #30 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014 Call Trace: dump_stack+0x100/0x184 lockdep_rcu_suspicious+0x153/0x15d fib_trie_unmerge+0x608/0xdb0 fib_unmerge+0x44/0x360 fib4_rule_configure+0xc8/0xad0 fib_nl_newrule+0x37a/0x1dd0 rtnetlink_rcv_msg+0x4f7/0xbd0 netlink_rcv_skb+0x17a/0x480 rtnetlink_rcv+0x22/0x30 netlink_unicast+0x5ae/0x890 netlink_sendmsg+0x98a/0xf40 ____sys_sendmsg+0x879/0xa00 ___sys_sendmsg+0x122/0x190 __sys_sendmsg+0x103/0x1d0 __x64_sys_sendmsg+0x7d/0xb0 do_syscall_64+0x54/0xa0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fc80a234e97 Code: Bad RIP value. RSP: 002b:00007ffef8b66798 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc80a234e97 RDX: 0000000000000000 RSI: 00007ffef8b66800 RDI: 0000000000000003 RBP: 000000005f141b1c R08: 0000000000000001 R09: 0000000000000000 R10: 00007fc80a2a8ac0 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000000 R14: 00007ffef8b67008 R15: 0000556fccb10020 Fixes: 0ddcf43d5d4a ("ipv4: FIB Local/MAIN table collapse") Signed-off-by: Ido Schimmel Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fcaef8db7c1a5114676fc2561db51013fb342f52 Author: Nicolas Chauvet Date: Sat Jul 18 12:07:10 2020 +0200 PCI: tegra: Revert tegra124 raw_violation_fixup commit e7b856dfcec6d3bf028adee8c65342d7035914a1 upstream. As reported in https://bugzilla.kernel.org/206217 , raw_violation_fixup is causing more harm than good in some common use-cases. This patch is a partial revert of commit: 191cd6fb5d2c ("PCI: tegra: Add SW fixup for RAW violations") and fixes the following regression since then. * Description: When both the NIC and MMC are used one can see the following message: NETDEV WATCHDOG: enp1s0 (r8169): transmit queue 0 timed out and pcieport 0000:00:02.0: AER: Uncorrected (Non-Fatal) error received: 0000:01:00.0 r8169 0000:01:00.0: AER: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) r8169 0000:01:00.0: AER: device [10ec:8168] error status/mask=00004000/00400000 r8169 0000:01:00.0: AER: [14] CmpltTO (First) r8169 0000:01:00.0: AER: can't recover (no error_detected callback) pcieport 0000:00:02.0: AER: device recovery failed After that, the ethernet NIC is not functional anymore even after reloading the r8169 module. After a reboot, this is reproducible by copying a large file over the NIC to the MMC. For some reason this is not reproducible when files are copied to a tmpfs. * Little background on the fixup, by Manikanta Maddireddy: "In the internal testing with dGPU on Tegra124, CmplTO is reported by dGPU. This happened because FIFO queue in AFI(AXI to PCIe) module get full by upstream posted writes. Back to back upstream writes interleaved with infrequent reads, triggers RAW violation and CmpltTO. This is fixed by reducing the posted write credits and by changing updateFC timer frequency. These settings are fixed after stress test. In the current case, RTL NIC is also reporting CmplTO. These settings seems to be aggravating the issue instead of fixing it." Link: https://lore.kernel.org/r/20200718100710.15398-1-kwizart@gmail.com Fixes: 191cd6fb5d2c ("PCI: tegra: Add SW fixup for RAW violations") Signed-off-by: Nicolas Chauvet Signed-off-by: Lorenzo Pieralisi Reviewed-by: Manikanta Maddireddy Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit d4622ea48841a79d0f09164f8153bc947dff7d04 Author: Christophe Leroy Date: Thu Jul 2 11:52:02 2020 +0000 Revert "powerpc/kasan: Fix shadow pages allocation failure" commit b506923ee44ae87fc9f4de16b53feb313623e146 upstream. This reverts commit d2a91cef9bbdeb87b7449fdab1a6be6000930210. This commit moved too much work in kasan_init(). The allocation of shadow pages has to be moved for the reason explained in that patch, but the allocation of page tables still need to be done before switching to the final hash table. First revert the incorrect commit, following patch redoes it properly. Fixes: d2a91cef9bbd ("powerpc/kasan: Fix shadow pages allocation failure") Cc: stable@vger.kernel.org Reported-by: Erhard F. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://bugzilla.kernel.org/show_bug.cgi?id=208181 Link: https://lore.kernel.org/r/3667deb0911affbf999b99f87c31c77d5e870cd2.1593690707.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman commit 1511086bb905cdebc77a79c60d0bc94d1d5f50d1 Author: Frank van der Linden Date: Tue Jun 23 22:39:18 2020 +0000 xattr: break delegations in {set,remove}xattr commit 08b5d5014a27e717826999ad20e394a8811aae92 upstream. set/removexattr on an exported filesystem should break NFS delegations. This is true in general, but also for the upcoming support for RFC 8726 (NFSv4 extended attribute support). Make sure that they do. Additionally, they need to grow a _locked variant, since callers might call this with i_rwsem held (like the NFS server code). Cc: stable@vger.kernel.org # v4.9+ Cc: linux-fsdevel@vger.kernel.org Cc: Al Viro Signed-off-by: Frank van der Linden Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit dba57fe0885cbef9a6ec75a1b0ff5914e832887d Author: Philippe Duplessis-Guindon Date: Thu Jul 30 11:02:36 2020 -0400 tools lib traceevent: Fix memory leak in process_dynamic_array_len [ Upstream commit e24c6447ccb7b1a01f9bf0aec94939e6450c0b4d ] I compiled with AddressSanitizer and I had these memory leaks while I was using the tep_parse_format function: Direct leak of 28 byte(s) in 4 object(s) allocated from: #0 0x7fb07db49ffe in __interceptor_realloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dffe) #1 0x7fb07a724228 in extend_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:985 #2 0x7fb07a724c21 in __read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1140 #3 0x7fb07a724f78 in read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1206 #4 0x7fb07a725191 in __read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1291 #5 0x7fb07a7251df in read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1299 #6 0x7fb07a72e6c8 in process_dynamic_array_len /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:2849 #7 0x7fb07a7304b8 in process_function /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3161 #8 0x7fb07a730900 in process_arg_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3207 #9 0x7fb07a727c0b in process_arg /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1786 #10 0x7fb07a731080 in event_read_print_args /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3285 #11 0x7fb07a731722 in event_read_print /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3369 #12 0x7fb07a740054 in __tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6335 #13 0x7fb07a74047a in __parse_event /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6389 #14 0x7fb07a740536 in tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6431 #15 0x7fb07a785acf in parse_event ../../../src/fs-src/fs.c:251 #16 0x7fb07a785ccd in parse_systems ../../../src/fs-src/fs.c:284 #17 0x7fb07a786fb3 in read_metadata ../../../src/fs-src/fs.c:593 #18 0x7fb07a78760e in ftrace_fs_source_init ../../../src/fs-src/fs.c:727 #19 0x7fb07d90c19c in add_component_with_init_method_data ../../../../src/lib/graph/graph.c:1048 #20 0x7fb07d90c87b in add_source_component_with_initialize_method_data ../../../../src/lib/graph/graph.c:1127 #21 0x7fb07d90c92a in bt_graph_add_source_component ../../../../src/lib/graph/graph.c:1152 #22 0x55db11aa632e in cmd_run_ctx_create_components_from_config_components ../../../src/cli/babeltrace2.c:2252 #23 0x55db11aa6fda in cmd_run_ctx_create_components ../../../src/cli/babeltrace2.c:2347 #24 0x55db11aa780c in cmd_run ../../../src/cli/babeltrace2.c:2461 #25 0x55db11aa8a7d in main ../../../src/cli/babeltrace2.c:2673 #26 0x7fb07d5460b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) The token variable in the process_dynamic_array_len function is allocated in the read_expect_type function, but is not freed before calling the read_token function. Free the token variable before calling read_token in order to plug the leak. Signed-off-by: Philippe Duplessis-Guindon Reviewed-by: Steven Rostedt (VMware) Link: https://lore.kernel.org/linux-trace-devel/20200730150236.5392-1-pduplessis@efficios.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 377bee428cbe3827fa1bb407cc6d7584b9742930 Author: Xin Xiong Date: Wed Jul 29 21:06:59 2020 +0800 atm: fix atm_dev refcnt leaks in atmtcp_remove_persistent [ Upstream commit 51875dad43b44241b46a569493f1e4bfa0386d86 ] atmtcp_remove_persistent() invokes atm_dev_lookup(), which returns a reference of atm_dev with increased refcount or NULL if fails. The refcount leaks issues occur in two error handling paths. If dev_data->persist is zero or PRIV(dev)->vcc isn't NULL, the function returns 0 without decreasing the refcount kept by a local variable, resulting in refcount leaks. Fix the issue by adding atm_dev_put() before returning 0 both when dev_data->persist is zero or PRIV(dev)->vcc isn't NULL. Signed-off-by: Xin Xiong Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b16c5401f262fb67db132360783874d9bf56842f Author: Francesco Ruggeri Date: Thu Jul 2 15:39:06 2020 -0700 igb: reinit_locked() should be called with rtnl_lock [ Upstream commit 024a8168b749db7a4aa40a5fbdfa04bf7e77c1c0 ] We observed two panics involving races with igb_reset_task. The first panic is caused by this race condition: kworker reboot -f igb_reset_task igb_reinit_locked igb_down napi_synchronize __igb_shutdown igb_clear_interrupt_scheme igb_free_q_vectors igb_free_q_vector adapter->q_vector[v_idx] = NULL; napi_disable Panics trying to access adapter->q_vector[v_idx].napi_state The second panic (a divide error) is caused by this race: kworker reboot -f tx packet igb_reset_task __igb_shutdown rtnl_lock() ... igb_clear_interrupt_scheme igb_free_q_vectors adapter->num_tx_queues = 0 ... rtnl_unlock() rtnl_lock() igb_reinit_locked igb_down igb_up netif_tx_start_all_queues dev_hard_start_xmit igb_xmit_frame igb_tx_queue_mapping Panics on r_idx % adapter->num_tx_queues This commit applies to igb_reset_task the same changes that were applied to ixgbe in commit 2f90b8657ec9 ("ixgbe: this patch adds support for DCB to the kernel and ixgbe driver"), commit 8f4c5c9fb87a ("ixgbe: reinit_locked() should be called with rtnl_lock") and commit 88adce4ea8f9 ("ixgbe: fix possible race in reset subtask"). Signed-off-by: Francesco Ruggeri Tested-by: Aaron Brown Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit aa354f905a8921e7c98aee1e740d6a11935ae946 Author: Julian Squires Date: Mon Jul 6 17:13:53 2020 -0400 cfg80211: check vendor command doit pointer before use [ Upstream commit 4052d3d2e8f47a15053320bbcbe365d15610437d ] In the case where a vendor command does not implement doit, and has no flags set, doit would not be validated and a NULL pointer dereference would occur, for example when invoking the vendor command via iw. I encountered this while developing new vendor commands. Perhaps in practice it is advisable to always implement doit along with dumpit, but it seems reasonable to me to always check doit anyway, not just when NEED_WDEV. Signed-off-by: Julian Squires Link: https://lore.kernel.org/r/20200706211353.2366470-1-julian@cipht.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 44c8b477fe201c8923ea146d2a4c1d64a8c17d9c Author: Qiushi Wu Date: Sat Jun 13 14:05:33 2020 -0500 firmware: Fix a reference count leak. [ Upstream commit fe3c60684377d5ad9b0569b87ed3e26e12c8173b ] kobject_init_and_add() takes reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Callback function fw_cfg_sysfs_release_entry() in kobject_put() can handle the pointer "entry" properly. Signed-off-by: Qiushi Wu Link: https://lore.kernel.org/r/20200613190533.15712-1-wu000273@umn.edu Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 7d415ec14c613f038ab4974886ebb503b1e54ff1 Author: Ranjani Sridharan Date: Tue Jul 28 16:10:11 2020 -0700 ALSA: hda: fix NULL pointer dereference during suspend [ Upstream commit 7fcd9bb5acd01250bcae1ecc0cb8b8d4bb5b7e63 ] When the ASoC card registration fails and the codec component driver never probes, the codec device is not initialized and therefore memory for codec->wcaps is not allocated. This results in a NULL pointer dereference when the codec driver suspend callback is invoked during system suspend. Fix this by returning without performing any actions during codec suspend/resume if the card was not registered successfully. Reviewed-by: Pierre-Louis Bossart Signed-off-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20200728231011.1454066-1-ranjani.sridharan@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 6afddfff61f0e5d6b5d5ca1ba89278f293ced36a Author: René van Dorst Date: Thu Jul 23 20:07:10 2020 +0100 net: ethernet: mtk_eth_soc: Always call mtk_gmac0_rgmii_adjust() for mt7623 [ Upstream commit 19016d93bfc335f0c158c0d9e3b9d06c4dd53d39 ] Modify mtk_gmac0_rgmii_adjust() so it can always be called. mtk_gmac0_rgmii_adjust() sets-up the TRGMII clocks. Signed-off-by: René van Dorst Signed-off-By: David Woodhouse Tested-by: Frank Wunderlich Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 735635c92ecb598217d89d804cfdd4656a0208a8 Author: Rustam Kovhaev Date: Mon Jul 27 23:42:17 2020 -0700 usb: hso: check for return value in hso_serial_common_create() [ Upstream commit e911e99a0770f760377c263bc7bac1b1593c6147 ] in case of an error tty_register_device_attr() returns ERR_PTR(), add IS_ERR() check Reported-and-tested-by: syzbot+67b2bd0e34f952d0321e@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=67b2bd0e34f952d0321e Signed-off-by: Rustam Kovhaev Reviewed-by: Greg Kroah-Hartman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4f62dd6c132eb1362a1f911d6511415221162a51 Author: Wolfram Sang Date: Sat Jul 25 21:50:53 2020 +0200 i2c: slave: add sanity check when unregistering [ Upstream commit 8808981baf96e1b3dea1f08461e4d958aa0dbde1 ] Signed-off-by: Wolfram Sang Reviewed-by: Alain Volmat Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 5abd689c477b0f61ddd3112716399bbe947694c3 Author: Wolfram Sang Date: Sat Jul 25 21:50:52 2020 +0200 i2c: slave: improve sanity check when registering [ Upstream commit 1b1be3bf27b62f5abcf85c6f3214bdb9c7526685 ] Add check for ERR_PTR and simplify code while here. Signed-off-by: Wolfram Sang Reviewed-by: Alain Volmat Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 06dd122843cd4cf8956b7200159bff316b830bdf Author: laurent brando Date: Mon Jul 27 18:26:14 2020 +0800 net: mscc: ocelot: fix hardware timestamp dequeue logic [ Upstream commit 5fd82200d870a5dd3e509c98ef2041f580b2c0e1 ] The next hw timestamp should be snapshoot to the read registers only once the current timestamp has been read. If none of the pending skbs matches the current HW timestamp just gracefully flush the available timestamp by reading it. Signed-off-by: laurent brando Signed-off-by: Vladimir Oltean Signed-off-by: Yangbo Lu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit cea0a7943a30a6d0320c8558a844dd27e8f0aa8b Author: Sam Ravnborg Date: Thu Jul 9 21:30:16 2020 +0200 drm/drm_fb_helper: fix fbdev with sparc64 [ Upstream commit 2a1658bf922ffd9b7907e270a7d9cdc9643fc45d ] Recent kernels have been reported to panic using the bochs_drm framebuffer under qemu-system-sparc64 which was bisected to commit 7a0483ac4ffc ("drm/bochs: switch to generic drm fbdev emulation"). The backtrace indicates that the shadow framebuffer copy in drm_fb_helper_dirty_blit_real() is trying to access the real framebuffer using a virtual address rather than use an IO access typically implemented using a physical (ASI_PHYS) access on SPARC. The fix is to replace the memcpy with memcpy_toio() from io.h. memcpy_toio() uses writeb() where the original fbdev code used sbus_memcpy_toio(). The latter uses sbus_writeb(). The difference between writeb() and sbus_memcpy_toio() is that writeb() writes bytes in little-endian, where sbus_writeb() writes bytes in big-endian. As endian does not matter for byte writes they are the same. So we can safely use memcpy_toio() here. Note that this only fixes bochs, in general fbdev helpers still have issues with mixing up system memory and __iomem space. Fixing that will require a lot more work. v3: - Improved changelog (Daniel) - Added FIXME to fbdev_use_iomem (Daniel) v2: - Added missing __iomem cast (kernel test robot) - Made changelog readable and fix typos (Mark) - Add flag to select iomem - and set it in the bochs driver Signed-off-by: Sam Ravnborg Reported-by: Mark Cave-Ayland Reported-by: kernel test robot Tested-by: Mark Cave-Ayland Reviewed-by: Daniel Vetter Cc: Mark Cave-Ayland Cc: Thomas Zimmermann Cc: Gerd Hoffmann Cc: "David S. Miller" Cc: sparclinux@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200709193016.291267-1-sam@ravnborg.org Link: https://patchwork.freedesktop.org/patch/msgid/20200725191012.GA434957@ravnborg.org Signed-off-by: Sasha Levin commit b0bb39a3aeb76f00afc52f69eb2cf180d073fe6b Author: Jitao Shi Date: Tue Jul 14 20:33:32 2020 +0800 drm/panel: Fix auo, kd101n80-45na horizontal noise on edges of panel [ Upstream commit d76acc9fcddeda53b985b029c890976a87fcc3fc ] Fine tune the HBP and HFP to avoid the dot noise on the left and right edges. Signed-off-by: Jitao Shi Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20200714123332.37609-1-jitao.shi@mediatek.com Signed-off-by: Sasha Levin commit 1e1f8e41a922514d5a6b4dad2f288dd4a2a29c92 Author: Laurentiu Palcu Date: Mon Jul 20 15:42:27 2020 +0300 drm/bridge/adv7511: set the bridge type properly [ Upstream commit f10761c9df96a882438faa09dcd25261281d69ca ] After the drm_bridge_connector_init() helper function has been added, the ADV driver has been changed accordingly. However, the 'type' field of the bridge structure was left unset, which makes the helper function always return -EINVAL. Signed-off-by: Laurentiu Palcu Reviewed-by: Laurent Pinchart Reviewed-by: Vinod Koul Tested-by: Vinod Koul # tested on DragonBoard 410c Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20200720124228.12552-1-laurentiu.palcu@oss.nxp.com Signed-off-by: Sasha Levin commit 4e72313d19b55a68e264c2d6acfd09649998d619 Author: Kai-Heng Feng Date: Fri Jul 24 01:29:10 2020 +0800 nvme-pci: prevent SK hynix PC400 from using Write Zeroes command [ Upstream commit 5611ec2b9814bc91f7b0a8d804c1fc152e2025d9 ] After commit 6e02318eaea5 ("nvme: add support for the Write Zeroes command"), SK hynix PC400 becomes very slow with the following error message: [ 224.567695] blk_update_request: operation not supported error, dev nvme1n1, sector 499384320 op 0x9:(WRITE_ZEROES) flags 0x1000000 phys_seg 0 prio class 0] SK Hynix PC400 has a buggy firmware that treats NLB as max value instead of a range, so the NLB passed isn't a valid value to the firmware. According to SK hynix there are three commands are affected: - Write Zeroes - Compare - Write Uncorrectable Right now only Write Zeroes is implemented, so disable it completely on SK hynix PC400. BugLink: https://bugs.launchpad.net/bugs/1872383 Cc: kyounghwan sohn Signed-off-by: Kai-Heng Feng Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit a75f18e854b55a385174b4778f1980bfcd01718d Author: Pavel Begunkov Date: Fri Jul 24 20:07:21 2020 +0300 io_uring: fix lockup in io_fail_links() [ Upstream commit 4ae6dbd683860b9edc254ea8acf5e04b5ae242e5 ] io_fail_links() doesn't consider REQ_F_COMP_LOCKED leading to nested spin_lock(completion_lock) and lockup. [ 197.680409] rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 6-... } 18239 jiffies s: 1421 root: 0x40/. [ 197.680411] rcu: blocking rcu_node structures: [ 197.680412] Task dump for CPU 6: [ 197.680413] link-timeout R running task 0 1669 1 0x8000008a [ 197.680414] Call Trace: [ 197.680420] ? io_req_find_next+0xa0/0x200 [ 197.680422] ? io_put_req_find_next+0x2a/0x50 [ 197.680423] ? io_poll_task_func+0xcf/0x140 [ 197.680425] ? task_work_run+0x67/0xa0 [ 197.680426] ? do_exit+0x35d/0xb70 [ 197.680429] ? syscall_trace_enter+0x187/0x2c0 [ 197.680430] ? do_group_exit+0x43/0xa0 [ 197.680448] ? __x64_sys_exit_group+0x18/0x20 [ 197.680450] ? do_syscall_64+0x52/0xa0 [ 197.680452] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 80e614d2fba1d728a931651c011c4a06495966dd Author: Ben Skeggs Date: Fri Jul 24 17:02:48 2020 +1000 drm/nouveau/fbcon: zero-initialise the mode_cmd2 structure [ Upstream commit 15fbc3b938534cc8eaac584a7b0c1183fc968b86 ] This is tripping up the format modifier patches. Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit c9109bcf4bac173c39ac6b54cb82107fdea0302e Author: Ben Skeggs Date: Fri Jul 24 17:01:39 2020 +1000 drm/nouveau/fbcon: fix module unload when fbcon init has failed for some reason [ Upstream commit 498595abf5bd51f0ae074cec565d888778ea558f ] Stale pointer was tripping up the unload path. Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit 9198b9e6c0c70d58632d7c55953bd12c29641d07 Author: Ben Skeggs Date: Thu Jul 23 20:10:42 2020 +1000 drm/nouveau/kms/tu102: wait for core update to complete when assigning windows [ Upstream commit 705d9d022949e3cdae82d89db6a8fc773eb23dad ] Fixes a race on Turing between the core cross-channel error checks and the following window update. Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit 4f708f41344d8b4ec64e2ff55d04feeb8d198683 Author: Christoph Hellwig Date: Fri Jul 10 10:57:22 2020 +0200 net/9p: validate fds in p9_fd_open [ Upstream commit a39c46067c845a8a2d7144836e9468b7f072343e ] p9_fd_open just fgets file descriptors passed in from userspace, but doesn't verify that they are valid for read or writing. This gets cought down in the VFS when actually attempting a read or write, but a new warning added in linux-next upsets syzcaller. Fix this by just verifying the fds early on. Link: http://lkml.kernel.org/r/20200710085722.435850-1-hch@lst.de Reported-by: syzbot+e6f77e16ff68b2434a2c@syzkaller.appspotmail.com Signed-off-by: Christoph Hellwig [Dominique: amend goto as per Doug Nazar's review] Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit 06b46481d51fac58bb776067478ceeb460339a57 Author: Peilin Ye Date: Tue Jul 14 14:09:04 2020 -0400 bpf: Fix NULL pointer dereference in __btf_resolve_helper_id() [ Upstream commit 5b801dfb7feb2738975d80223efc2fc193e55573 ] Prevent __btf_resolve_helper_id() from dereferencing `btf_vmlinux` as NULL. This patch fixes the following syzbot bug: https://syzkaller.appspot.com/bug?id=f823224ada908fa5c207902a5a62065e53ca0fcc Reported-by: syzbot+ee09bda7017345f1fbe6@syzkaller.appspotmail.com Signed-off-by: Peilin Ye Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200714180904.277512-1-yepeilin.cs@gmail.com Signed-off-by: Sasha Levin commit 5cca11ebb504fe17de1a111b07317789fdab5da7 Author: Dmitry Osipenko Date: Thu Jul 9 20:11:59 2020 +0300 gpio: max77620: Fix missing release of interrupt commit 2a5e6f7eede8cd1c4bac0b8ec6491cec4e75c99a upstream. The requested interrupt is never released by the driver. Fix this by using the resource-managed variant of request_threaded_irq(). Fixes: ab3dd9cc24d4 ("gpio: max77620: Fix interrupt handling") Signed-off-by: Dmitry Osipenko Reviewed-by: Andy Shevchenko Acked-by: Laxman Dewangan Cc: # 5.5+ Link: https://lore.kernel.org/r/20200709171203.12950-3-digetx@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 02c1ba9a22a177f05e6939ffe3aaba52a1cbb736 Author: Johan Hovold Date: Mon Jun 1 15:39:45 2020 +0200 leds: 88pm860x: fix use-after-free on unbind commit eca21c2d8655387823d695b26e6fe78cf3975c05 upstream. Several MFD child drivers register their class devices directly under the parent device. This means you cannot blindly do devres conversions so that deregistration ends up being tied to the parent device, something which leads to use-after-free on driver unbind when the class device is released while still being registered. Fixes: 375446df95ee ("leds: 88pm860x: Use devm_led_classdev_register") Cc: stable # 4.6 Cc: Amitoj Kaur Chawla Signed-off-by: Johan Hovold Signed-off-by: Pavel Machek Signed-off-by: Greg Kroah-Hartman commit 91bf2e397c7caf95b8fc337de4e014112998f096 Author: Johan Hovold Date: Mon Jun 1 15:39:47 2020 +0200 leds: lm3533: fix use-after-free on unbind commit d584221e683bbd173738603b83a315f27d27d043 upstream. Several MFD child drivers register their class devices directly under the parent device. This means you cannot blindly do devres conversions so that deregistration ends up being tied to the parent device, something which leads to use-after-free on driver unbind when the class device is released while still being registered. Fixes: 50154e29e5cc ("leds: lm3533: Use devm_led_classdev_register") Cc: stable # 4.6 Cc: Amitoj Kaur Chawla Signed-off-by: Johan Hovold Signed-off-by: Pavel Machek Signed-off-by: Greg Kroah-Hartman commit 320ee2f8dc2610c7930d9e92c86f97bfa9aa3bda Author: Johan Hovold Date: Mon Jun 1 15:39:46 2020 +0200 leds: da903x: fix use-after-free on unbind commit 6f4aa35744f69ed9b0bf5a736c9ca9b44bc1dcea upstream. Several MFD child drivers register their class devices directly under the parent device. This means you cannot blindly do devres conversions so that deregistration ends up being tied to the parent device, something which leads to use-after-free on driver unbind when the class device is released while still being registered. Fixes: eed16255d66b ("leds: da903x: Use devm_led_classdev_register") Cc: stable # 4.6 Cc: Amitoj Kaur Chawla Signed-off-by: Johan Hovold Signed-off-by: Pavel Machek Signed-off-by: Greg Kroah-Hartman commit 31ef93b919b580956d46ce4db5a3bcd2512aa08b Author: Johan Hovold Date: Mon Jun 1 15:39:48 2020 +0200 leds: lm36274: fix use-after-free on unbind commit a0972fff09479dd09b731360a3a0b09e4fb4d415 upstream. Several MFD child drivers register their class devices directly under the parent device. This means you cannot use devres so that deregistration ends up being tied to the parent device, something which leads to use-after-free on driver unbind when the class device is released while still being registered. Fixes: 11e1bbc116a7 ("leds: lm36274: Introduce the TI LM36274 LED driver") Cc: stable # 5.3 Cc: Dan Murphy Signed-off-by: Johan Hovold Signed-off-by: Pavel Machek Signed-off-by: Greg Kroah-Hartman commit a6da8ea3302807ea1ff914e4508aa383bca47e74 Author: Johan Hovold Date: Mon Jun 1 15:39:49 2020 +0200 leds: wm831x-status: fix use-after-free on unbind commit 47a459ecc800a17109d0c496a4e21e478806ee40 upstream. Several MFD child drivers register their class devices directly under the parent device. This means you cannot blindly do devres conversions so that deregistration ends up being tied to the parent device, something which leads to use-after-free on driver unbind when the class device is released while still being registered. Fixes: 8d3b6a4001ce ("leds: wm831x-status: Use devm_led_classdev_register") Cc: stable # 4.6 Cc: Amitoj Kaur Chawla Signed-off-by: Johan Hovold Signed-off-by: Pavel Machek Signed-off-by: Greg Kroah-Hartman commit 36a8b2f49235e63ab3f901fe12e1b6732f075c2e Author: Greg Kroah-Hartman Date: Thu Jul 16 13:53:46 2020 +0200 mtd: properly check all write ioctls for permissions commit f7e6b19bc76471ba03725fe58e0c218a3d6266c3 upstream. When doing a "write" ioctl call, properly check that we have permissions to do so before copying anything from userspace or anything else so we can "fail fast". This includes also covering the MEMWRITE ioctl which previously missed checking for this. Cc: Miquel Raynal Cc: Richard Weinberger Cc: Vignesh Raghavendra Cc: stable Signed-off-by: Greg Kroah-Hartman [rw: Fixed locking issue] Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit b2f1d746c96a16ae97099b9f454d01a9b730c26a Author: Yunhai Zhang Date: Tue Jul 28 09:58:03 2020 +0800 vgacon: Fix for missing check in scrollback handling commit ebfdfeeae8c01fcb2b3b74ffaf03876e20835d2d upstream. vgacon_scrollback_update() always leaves enbough room in the scrollback buffer for the next call, but if the console size changed that room might not actually be enough, and so we need to re-check. The check should be in the loop since vgacon_scrollback_cur->tail is updated in the loop and count may be more than 1 when triggered by CSI M, as Jiri's PoC: #include #include #include #include #include #include #include int main(int argc, char** argv) { int fd = open("/dev/tty1", O_RDWR); unsigned short size[3] = {25, 200, 0}; ioctl(fd, 0x5609, size); // VT_RESIZE write(fd, "\e[1;1H", 6); for (int i = 0; i < 30; i++) write(fd, "\e[10M", 5); } It leads to various crashes as vgacon_scrollback_update writes out of the buffer: BUG: unable to handle page fault for address: ffffc900001752a0 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page RIP: 0010:mutex_unlock+0x13/0x30 ... Call Trace: n_tty_write+0x1a0/0x4d0 tty_write+0x1a0/0x2e0 Or to KASAN reports: BUG: KASAN: slab-out-of-bounds in vgacon_scroll+0x57a/0x8ed This fixes CVE-2020-14331. Reported-by: 张云海 Reported-by: Yang Yingliang Reported-by: Kyungtae Kim Fixes: 15bdab959c9b ([PATCH] vgacon: Add support for soft scrollback) Cc: stable@vger.kernel.org Cc: linux-fbdev@vger.kernel.org Cc: Linus Torvalds Cc: Solar Designer Cc: "Srivatsa S. Bhat" Cc: Anthony Liguori Cc: Yang Yingliang Cc: Bartlomiej Zolnierkiewicz Cc: Jiri Slaby Signed-off-by: Yunhai Zhang Link: https://lore.kernel.org/r/9fb43895-ca91-9b07-ebfd-808cf854ca95@nsfocus.com Signed-off-by: Greg Kroah-Hartman commit b37d4feb9e86763fcdfb25c7f03e326e589fb178 Author: Kees Cook Date: Thu Jun 25 13:37:02 2020 -0700 lkdtm/heap: Avoid edge and middle of slabs commit e12145cf1c3a8077e6d9f575711e38dd7d8a3ebc upstream. Har har, after I moved the slab freelist pointer into the middle of the slab, now it looks like the contents are getting poisoned. Adjust the test to avoid the freelist pointer again. Fixes: 3202fa62fb43 ("slub: relocate freelist pointer to middle of object") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20200625203704.317097-3-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman commit fbda5fd8b46b01952e9eb592011cada626842e58 Author: Matthias Maennich Date: Thu Jun 4 18:41:45 2020 +0200 scripts: add dummy report mode to add_namespace.cocci commit 55c7549819e438f40a3ef1d8ac5c38b73390bcb7 upstream. When running `make coccicheck` in report mode using the add_namespace.cocci file, it will fail for files that contain MODULE_LICENSE. Those match the replacement precondition, but spatch errors out as virtual.ns is not set. In order to fix that, add the virtual rule nsdeps and only do search and replace if that rule has been explicitly requested. In order to make spatch happy in report mode, we also need a dummy rule, as otherwise it errors out with "No rules apply". Using a script:python rule appears unrelated and odd, but this is the shortest I could come up with. Adjust scripts/nsdeps accordingly to set the nsdeps rule when run trough `make nsdeps`. Suggested-by: Julia Lawall Fixes: c7c4e29fb5a4 ("scripts: add_namespace: Fix coccicheck failed") Cc: YueHaibing Cc: jeyu@kernel.org Cc: cocci@systeme.lip6.fr Cc: stable@vger.kernel.org Signed-off-by: Matthias Maennich Reported-by: Shuah Khan Acked-by: Julia Lawall Link: https://lore.kernel.org/r/20200604164145.173925-1-maennich@google.com Signed-off-by: Greg Kroah-Hartman commit cd417f1a17d91ea0a8b1d42b0da09353f82f9626 Author: Eric Biggers Date: Wed Jul 8 13:15:20 2020 -0700 Smack: fix use-after-free in smk_write_relabel_self() commit beb4ee6770a89646659e6a2178538d2b13e2654e upstream. smk_write_relabel_self() frees memory from the task's credentials with no locking, which can easily cause a use-after-free because multiple tasks can share the same credentials structure. Fix this by using prepare_creds() and commit_creds() to correctly modify the task's credentials. Reproducer for "BUG: KASAN: use-after-free in smk_write_relabel_self": #include #include #include static void *thrproc(void *arg) { int fd = open("/sys/fs/smackfs/relabel-self", O_WRONLY); for (;;) write(fd, "foo", 3); } int main() { pthread_t t; pthread_create(&t, NULL, thrproc, NULL); thrproc(NULL); } Reported-by: syzbot+e6416dabb497a650da40@syzkaller.appspotmail.com Fixes: 38416e53936e ("Smack: limited capability for changing process label") Cc: # v4.4+ Signed-off-by: Eric Biggers Signed-off-by: Casey Schaufler Signed-off-by: Greg Kroah-Hartman commit 02b16de25615a052956fa9d9014e3e0c3574d70c Author: Jann Horn Date: Mon Jul 27 14:04:24 2020 +0200 binder: Prevent context manager from incrementing ref 0 commit 4b836a1426cb0f1ef2a6e211d7e553221594f8fc upstream. Binder is designed such that a binder_proc never has references to itself. If this rule is violated, memory corruption can occur when a process sends a transaction to itself; see e.g. . There is a remaining edgecase through which such a transaction-to-self can still occur from the context of a task with BINDER_SET_CONTEXT_MGR access: - task A opens /dev/binder twice, creating binder_proc instances P1 and P2 - P1 becomes context manager - P2 calls ACQUIRE on the magic handle 0, allocating index 0 in its handle table - P1 dies (by closing the /dev/binder fd and waiting a bit) - P2 becomes context manager - P2 calls ACQUIRE on the magic handle 0, allocating index 1 in its handle table [this triggers a warning: "binder: 1974:1974 tried to acquire reference to desc 0, got 1 instead"] - task B opens /dev/binder once, creating binder_proc instance P3 - P3 calls P2 (via magic handle 0) with (void*)1 as argument (two-way transaction) - P2 receives the handle and uses it to call P3 (two-way transaction) - P3 calls P2 (via magic handle 0) (two-way transaction) - P2 calls P2 (via handle 1) (two-way transaction) And then, if P2 does *NOT* accept the incoming transaction work, but instead closes the binder fd, we get a crash. Solve it by preventing the context manager from using ACQUIRE on ref 0. There shouldn't be any legitimate reason for the context manager to do that. Additionally, print a warning if someone manages to find another way to trigger a transaction-to-self bug in the future. Cc: stable@vger.kernel.org Fixes: 457b9a6f09f0 ("Staging: android: add binder driver") Acked-by: Todd Kjos Signed-off-by: Jann Horn Reviewed-by: Martijn Coenen Link: https://lore.kernel.org/r/20200727120424.1627555-1-jannh@google.com Signed-off-by: Greg Kroah-Hartman commit 09b08c444dc28919943b4be14acec423f51f2c8d Author: Adam Ford Date: Tue Jun 30 13:26:36 2020 -0500 omapfb: dss: Fix max fclk divider for omap36xx commit 254503a2b186caa668a188dbbd7ab0d25149c0a5 upstream. The drm/omap driver was fixed to correct an issue where using a divider of 32 breaks the DSS despite the TRM stating 32 is a valid number. Through experimentation, it appears that 31 works, and it is consistent with the value used by the drm/omap driver. This patch fixes the divider for fbdev driver instead of the drm. Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb") Cc: #4.5+ Signed-off-by: Adam Ford Reviewed-by: Tomi Valkeinen Cc: Dave Airlie Cc: Rob Clark [b.zolnierkie: mark patch as applicable to stable 4.5+ (was 4.9+)] Signed-off-by: Bartlomiej Zolnierkiewicz Link: https://patchwork.freedesktop.org/patch/msgid/20200630182636.439015-1-aford173@gmail.com Signed-off-by: Greg Kroah-Hartman commit c9c49205b2f130b5cd258e6f8abdbd3fda429ffe Author: Peilin Ye Date: Fri Jul 10 17:45:26 2020 -0400 Bluetooth: Prevent out-of-bounds read in hci_inquiry_result_with_rssi_evt() commit 629b49c848ee71244203934347bd7730b0ddee8d upstream. Check `num_rsp` before using it as for-loop counter. Add `unlock` label. Cc: stable@vger.kernel.org Signed-off-by: Peilin Ye Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit e70b3552ac337c9480d9a74b3c6459710fe8364c Author: Peilin Ye Date: Fri Jul 10 17:39:18 2020 -0400 Bluetooth: Prevent out-of-bounds read in hci_inquiry_result_evt() commit 75bbd2ea50ba1c5d9da878a17e92eac02fe0fd3a upstream. Check `num_rsp` before using it as for-loop counter. Cc: stable@vger.kernel.org Signed-off-by: Peilin Ye Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 886a27c346901b6b5a3d5b12ca50ca821817185d Author: Peilin Ye Date: Fri Jul 10 12:09:15 2020 -0400 Bluetooth: Fix slab-out-of-bounds read in hci_extended_inquiry_result_evt() commit 51c19bf3d5cfaa66571e4b88ba2a6f6295311101 upstream. Check upon `num_rsp` is insufficient. A malformed event packet with a large `num_rsp` number makes hci_extended_inquiry_result_evt() go out of bounds. Fix it. This patch fixes the following syzbot bug: https://syzkaller.appspot.com/bug?id=4bf11aa05c4ca51ce0df86e500fce486552dc8d2 Reported-by: syzbot+d8489a79b781849b9c46@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Peilin Ye Acked-by: Greg Kroah-Hartman Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit fa7afddeac0b49697763b300a9fea221eb353cc0 Author: Dinghao Liu Date: Tue Jul 28 15:21:51 2020 +0800 Staging: rtl8188eu: rtw_mlme: Fix uninitialized variable authmode commit 11536442a3b4e1de6890ea5e805908debb74f94a upstream. The variable authmode can be uninitialized. The danger would be if it equals to _WPA_IE_ID_ (0xdd) or _WPA2_IE_ID_ (0x33). We can avoid this by setting it to zero instead. This is the approach that was used in the rtl8723bs driver. Fixes: 7b464c9fa5cc ("staging: r8188eu: Add files for new driver - part 4") Co-developed-by: Dan Carpenter Signed-off-by: Dan Carpenter Signed-off-by: Dinghao Liu Cc: stable Link: https://lore.kernel.org/r/20200728072153.9202-1-dinghao.liu@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 3a8d0a1aa5cb13b6437f465c6e1201c23ebb0b4e Author: Rustam Kovhaev Date: Thu Jul 16 08:13:26 2020 -0700 staging: rtl8712: handle firmware load failure commit b4383c971bc5263efe2b0915ba67ebf2bf3f1ee5 upstream. when firmware fails to load we should not call unregister_netdev() this patch fixes a race condition between rtl871x_load_fw_cb() and r871xu_dev_remove() and fixes the bug reported by syzbot Reported-by: syzbot+80899a8a8efe8968cde7@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=80899a8a8efe8968cde7 Signed-off-by: Rustam Kovhaev Cc: stable Link: https://lore.kernel.org/r/20200716151324.1036204-1-rkovhaev@gmail.com Signed-off-by: Greg Kroah-Hartman commit 07f332267d8189d1394b960718f87af30fed8b7a Author: Suren Baghdasaryan Date: Thu Jul 30 12:26:32 2020 -0700 staging: android: ashmem: Fix lockdep warning for write operation commit 3e338d3c95c735dc3265a86016bb4c022ec7cadc upstream. syzbot report [1] describes a deadlock when write operation against an ashmem fd executed at the time when ashmem is shrinking its cache results in the following lock sequence: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); lock(&sb->s_type->i_mutex_key#13); lock(fs_reclaim); lock(&sb->s_type->i_mutex_key#13); kswapd takes fs_reclaim and then inode_lock while generic_perform_write takes inode_lock and then fs_reclaim. However ashmem does not support writing into backing shmem with a write syscall. The only way to change its content is to mmap it and operate on mapped memory. Therefore the race that lockdep is warning about is not valid. Resolve this by introducing a separate lockdep class for the backing shmem inodes. [1]: https://lkml.kernel.org/lkml/0000000000000b5f9d059aa2037f@google.com/ Reported-by: syzbot+7a0d9d0b26efefe61780@syzkaller.appspotmail.com Signed-off-by: Suren Baghdasaryan Cc: stable Reviewed-by: Joel Fernandes (Google) Link: https://lore.kernel.org/r/20200730192632.3088194-1-surenb@google.com Signed-off-by: Greg Kroah-Hartman commit e311da5938f4883ab857c7983b5256fbbcdfad98 Author: Takashi Iwai Date: Tue Aug 4 20:58:15 2020 +0200 ALSA: seq: oss: Serialize ioctls commit 80982c7e834e5d4e325b6ce33757012ecafdf0bb upstream. Some ioctls via OSS sequencer API may race and lead to UAF when the port create and delete are performed concurrently, as spotted by a couple of syzkaller cases. This patch is an attempt to address it by serializing the ioctls with the existing register_mutex. Basically OSS sequencer API is an obsoleted interface and was designed without much consideration of the concurrency. There are very few applications with it, and the concurrent performance isn't asked, hence this "big hammer" approach should be good enough. Reported-by: syzbot+1a54a94bd32716796edd@syzkaller.appspotmail.com Reported-by: syzbot+9d2abfef257f3e2d4713@syzkaller.appspotmail.com Suggested-by: Hillf Danton Cc: Link: https://lore.kernel.org/r/20200804185815.2453-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 07e700f2df372ce6db83a0a75ed6322cce0b4339 Author: Connor McAdams Date: Sun Aug 2 20:29:27 2020 -0400 ALSA: hda/ca0132 - Fix AE-5 microphone selection commands. commit 7fe3530427e52dd53cd7366914864e29215180a4 upstream. The ca0113 command had the wrong group_id, 0x48 when it should've been 0x30. The front microphone selection should now work. Signed-off-by: Connor McAdams Cc: Link: https://lore.kernel.org/r/20200803002928.8638-3-conmanx360@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 65e98f2a989e078615971c0313d063d13c6e0d40 Author: Connor McAdams Date: Sun Aug 2 20:29:25 2020 -0400 ALSA: hda/ca0132 - Fix ZxR Headphone gain control get value. commit a00dc409de455b64e6cb2f6d40cdb8237cdb2e83 upstream. When the ZxR headphone gain control was added, the ca0132_switch_get function was not updated, which meant that the changes to the control state were not saved when entering/exiting alsamixer. Signed-off-by: Connor McAdams Cc: Link: https://lore.kernel.org/r/20200803002928.8638-1-conmanx360@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5fe681ece4ca518dc4b9dc94d99f0e9a0cafe87b Author: Connor McAdams Date: Sun Aug 2 20:29:26 2020 -0400 ALSA: hda/ca0132 - Add new quirk ID for Recon3D. commit cc5edb1bd3f7bfe450f767b12423f6673822427b upstream. Add a new quirk ID for the Recon3D, as tested by me. Signed-off-by: Connor McAdams Cc: Link: https://lore.kernel.org/r/20200803002928.8638-2-conmanx360@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 36c06a64afddf3a97c4188204af0aa2b0fbb137f Author: Huacai Chen Date: Sun Aug 2 17:26:40 2020 +0800 ALSA: hda/realtek: Add alc269/alc662 pin-tables for Loongson-3 laptops commit f1ec5be17b9aafbc5f573da023850566b43d8e5e upstream. There are several Loongson-3 based laptops produced by CZC or Lemote, they use alc269/alc662 codecs and need specific pin-tables, this patch add their pin-tables. Signed-off-by: Huacai Chen Cc: Link: https://lore.kernel.org/r/1596360400-32425-1-git-send-email-chenhc@lemote.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 327897152892af1fb1468ea6857fe6acd88f152d Author: Hui Wang Date: Mon Aug 3 14:46:38 2020 +0800 Revert "ALSA: hda: call runtime_allow() for all hda controllers" commit 07c9983b567d0ef33aefc063299de95a987e12a8 upstream. This reverts commit 9a6418487b56 ("ALSA: hda: call runtime_allow() for all hda controllers"). The reverted patch already introduced some regressions on some machines: - on gemini-lake machines, the error of "azx_get_response timeout" happens in the hda driver. - on the machines with alc662 codec, the audio jack detection doesn't work anymore. Fixes: 9a6418487b56 ("ALSA: hda: call runtime_allow() for all hda controllers") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208511 Cc: Signed-off-by: Hui Wang Link: https://lore.kernel.org/r/20200803064638.6139-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3c97f64be225fad9a03980dc3547eda087fe7634 Author: Forest Crossman Date: Mon Jul 27 23:24:08 2020 -0500 usb: xhci: Fix ASMedia ASM1142 DMA addressing commit ec37198acca7b4c17b96247697406e47aafe0605 upstream. I've confirmed that the ASMedia ASM1142 has the same problem as the ASM2142/ASM3142, in that it too reports that it supports 64-bit DMA addresses when in fact it does not. As with the ASM2142/ASM3142, this can cause problems on systems where the upper bits matter, and adding the XHCI_NO_64BIT_SUPPORT quirk completely fixes the issue. Acked-by: Mathias Nyman Signed-off-by: Forest Crossman Cc: stable Link: https://lore.kernel.org/r/20200728042408.180529-3-cyrozap@gmail.com Signed-off-by: Greg Kroah-Hartman commit 49a9ed2310eb1c25fd3632364fa22c212bac1f91 Author: Forest Crossman Date: Mon Jul 27 23:24:07 2020 -0500 usb: xhci: define IDs for various ASMedia host controllers commit 1841cb255da41e87bed9573915891d056f80e2e7 upstream. Not all ASMedia host controllers have a device ID that matches its part number. #define some of these IDs to make it clearer at a glance which chips require what quirks. Acked-by: Mathias Nyman Signed-off-by: Forest Crossman Link: https://lore.kernel.org/r/20200728042408.180529-2-cyrozap@gmail.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit 7781c9c38d027fcb8563fb667b45c498f2c1e35b Author: Greg Kroah-Hartman Date: Sun Jul 26 11:49:39 2020 +0200 USB: iowarrior: fix up report size handling for some devices commit 17a82716587e9d7c3b246a789add490b2b5dcab6 upstream. In previous patches that added support for new iowarrior devices, the handling of the report size was not done correct. Fix that up and update the copyright date for the driver Reworked from an original patch written by Christoph Jung. Fixes: bab5417f5f01 ("USB: misc: iowarrior: add support for the 100 device") Fixes: 5f6f8da2d7b5 ("USB: misc: iowarrior: add support for the 28 and 28L devices") Fixes: 461d8deb26a7 ("USB: misc: iowarrior: add support for 2 OEMed devices") Cc: stable Reported-by: Christoph Jung Link: https://lore.kernel.org/r/20200726094939.1268978-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 6f2a670531b9517dacbca4fc88f703916f415ae5 Author: Erik Ekman Date: Fri Jul 17 20:51:18 2020 +0200 USB: serial: qcserial: add EM7305 QDL product ID commit d2a4309c1ab6df424b2239fe2920d6f26f808d17 upstream. When running qmi-firmware-update on the Sierra Wireless EM7305 in a Toshiba laptop, it changed product ID to 0x9062 when entering QDL mode: usb 2-4: new high-speed USB device number 78 using xhci_hcd usb 2-4: New USB device found, idVendor=1199, idProduct=9062, bcdDevice= 0.00 usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 2-4: Product: EM7305 usb 2-4: Manufacturer: Sierra Wireless, Incorporated The upgrade could complete after running # echo 1199 9062 > /sys/bus/usb-serial/drivers/qcserial/new_id qcserial 2-4:1.0: Qualcomm USB modem converter detected usb 2-4: Qualcomm USB modem converter now attached to ttyUSB0 Signed-off-by: Erik Ekman Link: https://lore.kernel.org/r/20200717185118.3640219-1-erik@kryo.se Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 1e363f60917e8e48bc9d77c0e24e03a972313165 Author: Stanley Chu Date: Mon Jul 6 14:07:07 2020 +0800 scsi: ufs: Fix and simplify setup_xfer_req variant operation commit 6edfdcfe285e499994b94a0f93e1f46ab2398162 upstream. Add missing setup_xfer_req() call in ufshcd_issue_devman_upiu_cmd() in ufs-bsg path. Relocate existing setup_xfer_req() calls to a common place, i.e., ufshcd_send_command(), to simplify the driver. Link: https://lore.kernel.org/r/20200706060707.32608-3-stanley.chu@mediatek.com Acked-by: Avri Altman Signed-off-by: Stanley Chu Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman