- Feb 01, 2020
-
-
Greg Kroah-Hartman authored
-
Paul Cercueil authored
commit 86b9182d upstream. The ADC in the JZ4740 can work either in high-precision mode with a 2.5V range, or in low-precision mode with a 7.5V range. The code in place in this driver will select the proper scale according to the maximum voltage of the battery. The JZ4770 however only has one mode, with a 6.6V range. If only one scale is available, there's no need to change it (and nothing to change it to), and trying to do so will fail with -EINVAL. Fixes: fb24ccfb ("power: supply: add Ingenic JZ47xx battery driver.") Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Acked-by:
Artur Rojek <contact@artur-rojek.eu> Cc: stable@vger.kernel.org Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Johannes Berg authored
commit 87c9366e upstream. This reverts commit 786b2384 ("um: Enable CONFIG_CONSTRUCTORS"). There are two issues with this commit, uncovered by Anton in tests on some (Debian) systems: 1) I completely forgot to call any constructors if CONFIG_CONSTRUCTORS isn't set. Don't recall now if it just wasn't needed on my system, or if I never tested this case. 2) With that fixed, it works - with CONFIG_CONSTRUCTORS *unset*. If I set CONFIG_CONSTRUCTORS, it fails again, which isn't totally unexpected since whatever wanted to run is likely to have to run before the kernel init etc. that calls the constructors in this case. Basically, some constructors that gcc emits (libc has?) need to run very early during init; the failure mode otherwise was that the ptrace fork test already failed: ---------------------- $ ./linux mem=512M Core dump limits : soft - 0 hard - NONE Checking that ptrace can change system call numbers...check_ptrace : child exited with exitcode 6, while expecting 0; status 0x67f Aborted ---------------------- Thinking more about this, it's clear that we simply cannot support CONFIG_CONSTRUCTORS in UML. All the cases we need now (gcov, kasan) involve not use of the __attribute__((constructor)), but instead some constructor code/entry generated by gcc. Therefore, we cannot distinguish between kernel constructors and system constructors. Thus, revert this commit. Cc: stable@vger.kernel.org [5.4+] Fixes: 786b2384 ("um: Enable CONFIG_CONSTRUCTORS") Reported-by:
Anton Ivanov <anton.ivanov@cambridgegreys.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Acked-by:
Anton Ivanov <anton.ivanov@cambridgegreys.co.uk> Signed-off-by:
Richard Weinberger <richard@nod.at>
-
Andrew Murray authored
commit 4942dc66 upstream. On VHE systems arch.mdcr_el2 is written to mdcr_el2 at vcpu_load time to set options for self-hosted debug and the performance monitors extension. Unfortunately the value of arch.mdcr_el2 is not calculated until kvm_arm_setup_debug() in the run loop after the vcpu has been loaded. This means that the initial brief iterations of the run loop use a zero value of mdcr_el2 - until the vcpu is preempted. This also results in a delay between changes to vcpu->guest_debug taking effect. Fix this by writing to mdcr_el2 in kvm_arm_setup_debug() on VHE systems when a change to arch.mdcr_el2 has been detected. Fixes: d5a21bcc ("KVM: arm64: Move common VHE/non-VHE trap config in separate functions") Cc: <stable@vger.kernel.org> # 4.17.x- Suggested-by:
James Morse <james.morse@arm.com> Acked-by:
Will Deacon <will@kernel.org> Reviewed-by:
Marc Zyngier <maz@kernel.org> Signed-off-by:
Andrew Murray <andrew.murray@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Herbert Xu authored
commit 07bfd9bd upstream. On module unload of pcrypt we must unregister the crypto algorithms first and then tear down the padata structure. As otherwise the crypto algorithms are still alive and can be used while the padata structure is being freed. Fixes: 5068c7a8 ("crypto: pcrypt - Add pcrypt crypto...") Cc: <stable@vger.kernel.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Iuliana Prodan authored
commit 7278fa25 upstream. In commit 'a1cf573e ("crypto: caam - select DMA address size at runtime")' CAAM pointer size (caam_ptr_size) is changed from sizeof(dma_addr_t) to runtime value computed from MCFGR register. Therefore, do not reset MCFGR[PS]. Fixes: a1cf573e ("crypto: caam - select DMA address size at runtime") Signed-off-by:
Iuliana Prodan <iuliana.prodan@nxp.com> Cc: <stable@vger.kernel.org> Cc: Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Alison Wang <alison.wang@nxp.com> Reviewed-by:
Horia Geantă <horia.geanta@nxp.com> Signed-off-by:
-
Daniel Axtens authored
commit 1372a51b upstream. When the kernel XTS implementation was extended to deal with ciphertext stealing in commit 8083b1bf ("crypto: xts - add support for ciphertext stealing"), a check was added to reject inputs that were too short. However, in the vmx enablement - commit 23966841 ("crypto: vmx/xts - use fallback for ciphertext stealing"), that check wasn't added to the vmx implementation. This disparity leads to errors like the following: alg: skcipher: p8_aes_xts encryption unexpectedly succeeded on test vector "random: len=0 klen=64"; expected_error=-22, cfg="random: inplace may_sleep use_finup src_divs=[<flush>66.99%@+10, 33.1%@alignmask+1155]" Return -EINVAL if asked to operate with a cryptlen smaller than the AES block size. This brings vmx in line with the generic implementation. Reported-by:
Erhard Furtner <erhard_f@mailbox.org> Link: https://bugzilla.kernel.org/show_bug.cgi?id=206049 Fixes: 23966841 ("crypto: vmx/xts - use fallback for ciphertext stealing") Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: stable@vger.kernel.org # v5.4+ Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> [dja: commit message] Signed-off-by:
Daniel Axtens <dja@axtens.net> Signed-off-by:
-
Herbert Xu authored
commit 37f96694 upstream. As af_alg_release_parent may be called from BH context (most notably due to an async request that only completes after socket closure, or as reported here because of an RCU-delayed sk_destruct call), we must use bh_lock_sock instead of lock_sock. Reported-by:
<syzbot+c2f1558d49e25cc36e5e@syzkaller.appspotmail.com> Reported-by:
Eric Dumazet <eric.dumazet@gmail.com> Fixes: c840ac6a ("crypto: af_alg - Disallow bind/setkey/...") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Johan Hovold authored
commit b9b9f9fe upstream. USB completion handlers are called in atomic context and must specifically not allocate memory using GFP_KERNEL. Fixes: a1854fae ("rsi: improve RX packet handling in USB interface") Cc: stable <stable@vger.kernel.org> # 4.17 Cc: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Johan Hovold authored
commit 47768297 upstream. Make sure to free the skb on failed receive-URB submission (e.g. on disconnect or currently also due to a missing endpoint). Fixes: a1854fae ("rsi: improve RX packet handling in USB interface") Cc: stable <stable@vger.kernel.org> # 4.17 Cc: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by:
-
Johan Hovold authored
commit 92aafe77 upstream. The driver would fail to stop the command timer in most error paths, something which specifically could lead to the timer being freed while still active on I/O errors during probe. Fix this by making sure that each function starting the timer also stops it in all relevant error paths. Reported-by:
<syzbot+1d1597a5aa3679c65b9f@syzkaller.appspotmail.com> Fixes: b78e91bc ("rsi: Add new firmware loading method") Cc: stable <stable@vger.kernel.org> # 4.12 Cc: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Cc: Amitkumar Karwar <amit.karwar@redpinesignals.com> Signed-off-by:
-
Johan Hovold authored
commit e93cd351 upstream. Make sure to stop both URBs before returning after failed probe as well as on disconnect to avoid use-after-free in the completion handler. Reported-by:
<syzbot+b563b7f8dbe8223a51e8@syzkaller.appspotmail.com> Fixes: a4302bff ("rsi: add bluetooth rx endpoint") Fixes: dad0d04f ("rsi: Add RS9113 wireless driver") Cc: stable <stable@vger.kernel.org> # 3.15 Cc: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> Cc: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Cc: Amitkumar Karwar <amit.karwar@redpinesignals.com> Cc: Fariya Fatima <fariyaf@gmail.com> Signed-off-by:
-
David Howells authored
[ Upstream commit 122d74fa ] The subpacket scanning loop in rxrpc_receive_data() references the subpacket count in the private data part of the sk_buff in the loop termination condition. However, when the final subpacket is pasted into the ring buffer, the function is no longer has a ref on the sk_buff and should not be looking at sp->* any more. This point is actually marked in the code when skb is cleared (but sp is not - which is an error). Fix this by caching sp->nr_subpackets in a local variable and using that instead. Also clear 'sp' to catch accesses after that point. This can show up as an oops in rxrpc_get_skb() if sp->nr_subpackets gets trashed by the sk_buff getting freed and reused in the meantime. Fixes: e2de6c40 ("rxrpc: Use info in skbuff instead of reparsing a jumbo packet") Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Stephen Worley authored
[ Upstream commit f9e95555 ] Include the size of struct nhmsg size when calculating how much of a payload to allocate in a new netlink nexthop notification message. Without this, we will fail to fill the skbuff at certain nexthop group sizes. You can reproduce the failure with the following iproute2 commands: ip link add dummy1 type dummy ip link add dummy2 type dummy ip link add dummy3 type dummy ip link add dummy4 type dummy ip link add dummy5 type dummy ip link add dummy6 type dummy ip link add dummy7 type dummy ip link add dummy8 type dummy ip link add dummy9 type dummy ip link add dummy10 type dummy ip link add dummy11 type dummy ip link add dummy12 type dummy ip link add dummy13 type dummy ip link add dummy14 type dummy ip link add dummy15 type dummy ip link add dummy16 type dummy ip link add dummy17 type dummy ip link add dummy18 type dummy ip link add dummy19 type dummy ip ro add 1.1.1.1/32 dev dummy1 ip ro add 1.1.1.2/32 dev dummy2 ip ro add 1.1.1.3/32 dev dummy3 ip ro add 1.1.1.4/32 dev dummy4 ip ro add 1.1.1.5/32 dev dummy5 ip ro add 1.1.1.6/32 dev dummy6 ip ro add 1.1.1.7/32 dev dummy7 ip ro add 1.1.1.8/32 dev dummy8 ip ro add 1.1.1.9/32 dev dummy9 ip ro add 1.1.1.10/32 dev dummy10 ip ro add 1.1.1.11/32 dev dummy11 ip ro add 1.1.1.12/32 dev dummy12 ip ro add 1.1.1.13/32 dev dummy13 ip ro add 1.1.1.14/32 dev dummy14 ip ro add 1.1.1.15/32 dev dummy15 ip ro add 1.1.1.16/32 dev dummy16 ip ro add 1.1.1.17/32 dev dummy17 ip ro add 1.1.1.18/32 dev dummy18 ip ro add 1.1.1.19/32 dev dummy19 ip next add id 1 via 1.1.1.1 dev dummy1 ip next add id 2 via 1.1.1.2 dev dummy2 ip next add id 3 via 1.1.1.3 dev dummy3 ip next add id 4 via 1.1.1.4 dev dummy4 ip next add id 5 via 1.1.1.5 dev dummy5 ip next add id 6 via 1.1.1.6 dev dummy6 ip next add id 7 via 1.1.1.7 dev dummy7 ip next add id 8 via 1.1.1.8 dev dummy8 ip next add id 9 via 1.1.1.9 dev dummy9 ip next add id 10 via 1.1.1.10 dev dummy10 ip next add id 11 via 1.1.1.11 dev dummy11 ip next add id 12 via 1.1.1.12 dev dummy12 ip next add id 13 via 1.1.1.13 dev dummy13 ip next add id 14 via 1.1.1.14 dev dummy14 ip next add id 15 via 1.1.1.15 dev dummy15 ip next add id 16 via 1.1.1.16 dev dummy16 ip next add id 17 via 1.1.1.17 dev dummy17 ip next add id 18 via 1.1.1.18 dev dummy18 ip next add id 19 via 1.1.1.19 dev dummy19 ip next add id 1111 group 1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19 ip next del id 1111 Fixes: 430a0491 ("nexthop: Add support for nexthop groups") Signed-off-by:
Stephen Worley <sworley@cumulusnetworks.com> Reviewed-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit 6dd4b4f3 ] An 'alloc_etherdev()' called is not ballanced by a corresponding 'free_netdev()' call in one error handling path. Slighly reorder the error handling code to catch the missed case. Fixes: c100e47c ("mlxsw: minimal: Add ethtool support") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Willem de Bruijn authored
[ Upstream commit 6cd021a5 ] Multicast and broadcast packets can be looped from egress to ingress pre segmentation with dev_loopback_xmit. That function unconditionally sets ip_summed to CHECKSUM_UNNECESSARY. udp_rcv_segment segments gso packets in the udp rx path. Segmentation usually executes on egress, and does not expect packets of this type. __udp_gso_segment interprets !CHECKSUM_PARTIAL as CHECKSUM_NONE. But the offsets are not correct for gso_make_checksum. UDP GSO packets are of type CHECKSUM_PARTIAL, with their uh->check set to the correct pseudo header checksum. Reset ip_summed to this type. (CHECKSUM_PARTIAL is allowed on ingress, see comments in skbuff.h) Reported-by:
syzbot <syzkaller@googlegroups.com> Fixes: cf329aa4 ("udp: cope with UDP GRO packet misdirection") Signed-off-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Lorenzo Bianconi authored
[ Upstream commit 02758cb6 ] Fix xdp_result initialization in netsec_process_rx in order to not increase rx counters if there is no bpf program attached to the xdp hook and napi_gro_receive returns GRO_DROP Fixes: ba2b2321 ("net: netsec: add XDP support") Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Acked-by:
Jesper Dangaard Brouer <brouer@redhat.com> Acked-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by:
-
Lorenzo Bianconi authored
[ Upstream commit b5e82e3c ] Fix possible use-after-free in in netsec_process_rx that can occurs if the first packet is sent to the normal networking stack and the following one is dropped by the bpf program attached to the xdp hook. Fix the issue defining the skb pointer in the 'budget' loop Fixes: ba2b2321 ("net: netsec: add XDP support") Signed-off-by:
-
Cong Wang authored
[ Upstream commit 760d228e ] In a complex TC class hierarchy like this: tc qdisc add dev eth0 root handle 1:0 cbq bandwidth 100Mbit \ avpkt 1000 cell 8 tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 100Mbit \ rate 6Mbit weight 0.6Mbit prio 8 allot 1514 cell 8 maxburst 20 \ avpkt 1000 bounded tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip \ sport 80 0xffff flowid 1:3 tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip \ sport 25 0xffff flowid 1:4 tc class add dev eth0 parent 1:1 classid 1:3 cbq bandwidth 100Mbit \ rate 5Mbit weight 0.5Mbit prio 5 allot 1514 cell 8 maxburst 20 \ avpkt 1000 tc class add dev eth0 parent 1:1 classid 1:4 cbq bandwidth 100Mbit \ rate 3Mbit weight 0.3Mbit prio 5 allot 1514 cell 8 maxburst 20 \ avpkt 1000 where filters are installed on qdisc 1:0, so we can't merely search from class 1:1 when creating class 1:3 and class 1:4. We have to walk through all the child classes of the direct parent qdisc. Otherwise we would miss filters those need reverse binding. Fixes: 07d79fc7 ("net_sched: add reverse binding for tc class") Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: Jiri Pirko <jiri@resnulli.us> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
Cong Wang authored
[ Upstream commit 2e24cd75 ] The current implementations of ops->bind_class() are merely searching for classid and updating class in the struct tcf_result, without invoking either of cl_ops->bind_tcf() or cl_ops->unbind_tcf(). This breaks the design of them as qdisc's like cbq use them to count filters too. This is why syzbot triggered the warning in cbq_destroy_class(). In order to fix this, we have to call cl_ops->bind_tcf() and cl_ops->unbind_tcf() like the filter binding path. This patch does so by refactoring out two helper functions __tcf_bind_filter() and __tcf_unbind_filter(), which are lockless and accept a Qdisc pointer, then teaching each implementation to call them correctly. Note, we merely pass the Qdisc pointer as an opaque pointer to each filter, they only need to pass it down to the helper functions without understanding it at all. Fixes: 07d79fc7 ("net_sched: add reverse binding for tc class") Reported-and-tested-by:
<syzbot+0a0596220218fcb603a8@syzkaller.appspotmail.com> Reported-and-tested-by:
<syzbot+63bdb6006961d8c917c6@syzkaller.appspotmail.com> Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: Jiri Pirko <jiri@resnulli.us> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 55cd9f67 ] It is possible for malicious userspace to set TCF_EM_SIMPLE bit even for matches that should not have this bit set. This can fool two places using tcf_em_is_simple() 1) tcf_em_tree_destroy() -> memory leak of em->data if ops->destroy() is NULL 2) tcf_em_tree_dump() wrongly report/leak 4 low-order bytes of a kernel pointer. BUG: memory leak unreferenced object 0xffff888121850a40 (size 32): comm "syz-executor927", pid 7193, jiffies 4294941655 (age 19.840s) hex dump (first 32 bytes): 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000f67036ea>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline] [<00000000f67036ea>] slab_post_alloc_hook mm/slab.h:586 [inline] [<00000000f67036ea>] slab_alloc mm/slab.c:3320 [inline] [<00000000f67036ea>] __do_kmalloc mm/slab.c:3654 [inline] [<00000000f67036ea>] __kmalloc_track_caller+0x165/0x300 mm/slab.c:3671 [<00000000fab0cc8e>] kmemdup+0x27/0x60 mm/util.c:127 [<00000000d9992e0a>] kmemdup include/linux/string.h:453 [inline] [<00000000d9992e0a>] em_nbyte_change+0x5b/0x90 net/sched/em_nbyte.c:32 [<000000007e04f711>] tcf_em_validate net/sched/ematch.c:241 [inline] [<000000007e04f711>] tcf_em_tree_validate net/sched/ematch.c:359 [inline] [<000000007e04f711>] tcf_em_tree_validate+0x332/0x46f net/sched/ematch.c:300 [<000000007a769204>] basic_set_parms net/sched/cls_basic.c:157 [inline] [<000000007a769204>] basic_change+0x1d7/0x5f0 net/sched/cls_basic.c:219 [<00000000e57a5997>] tc_new_tfilter+0x566/0xf70 net/sched/cls_api.c:2104 [<0000000074b68559>] rtnetlink_rcv_msg+0x3b2/0x4b0 net/core/rtnetlink.c:5415 [<00000000b7fe53fb>] netlink_rcv_skb+0x61/0x170 net/netlink/af_netlink.c:2477 [<00000000e83a40d0>] rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5442 [<00000000d62ba933>] netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] [<00000000d62ba933>] netlink_unicast+0x223/0x310 net/netlink/af_netlink.c:1328 [<0000000088070f72>] netlink_sendmsg+0x2c0/0x570 net/netlink/af_netlink.c:1917 [<00000000f70b15ea>] sock_sendmsg_nosec net/socket.c:639 [inline] [<00000000f70b15ea>] sock_sendmsg+0x54/0x70 net/socket.c:659 [<00000000ef95a9be>] ____sys_sendmsg+0x2d0/0x300 net/socket.c:2330 [<00000000b650f1ab>] ___sys_sendmsg+0x8a/0xd0 net/socket.c:2384 [<0000000055bfa74a>] __sys_sendmsg+0x80/0xf0 net/socket.c:2417 [<000000002abac183>] __do_sys_sendmsg net/socket.c:2426 [inline] [<000000002abac183>] __se_sys_sendmsg net/socket.c:2424 [inline] [<000000002abac183>] __x64_sys_sendmsg+0x23/0x30 net/socket.c:2424 Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
<syzbot+03c4738ed29d5d366ddf@syzkaller.appspotmail.com> Cc: Cong Wang <xiyou.wangcong@gmail.com> Acked-by:
-
Sven Auhagen authored
[ Upstream commit 79572c98 ] Recently XDP Support was added to the mvneta driver for software buffer management only. It is still possible to attach an XDP program if hardware buffer management is used. It is not doing anything at that point. The patch disallows attaching XDP programs to mvneta if hardware buffer management is used. I am sorry about that. It is my first submission and I am having some troubles with the format of my emails. v4 -> v5: - Remove extra tabs v3 -> v4: - Please ignore v3 I accidentally submitted my other patch with git-send-mail and v4 is correct v2 -> v3: - My mailserver corrupted the patch resubmission with git-send-email v1 -> v2: - Fixing the patches indentation Signed-off-by:
Sven Auhagen <sven.auhagen@voleatech.de> Signed-off-by:
-
Johan Hovold authored
commit 2d68bb26 upstream. Make sure to use the current alternate setting when verifying the storage interface descriptors to avoid submitting an URB to an invalid endpoint. Failing to do so could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: a1030e92 ("[PATCH] zd1211rw: Convert installer CDROM device into WLAN device") Cc: stable <stable@vger.kernel.org> # 2.6.19 Signed-off-by:
-
Johan Hovold authored
commit 39a4281c upstream. Make sure to use the current alternate setting when verifying the interface descriptors to avoid binding to an invalid interface. Failing to do so could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: 26f1fad2 ("New driver: rtl8xxxu (mac80211)") Cc: stable <stable@vger.kernel.org> # 4.4 Cc: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by:
-
Johan Hovold authored
commit 3428fbcd upstream. Make sure to use the current alternate setting when verifying the interface descriptors to avoid binding to an invalid interface. Failing to do so could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: 71bb244b ("brcm80211: fmac: add USB support for bcm43235/6/8 chipsets") Cc: stable <stable@vger.kernel.org> # 3.4 Cc: Arend van Spriel <arend@broadcom.com> Signed-off-by:
-
Johan Hovold authored
commit 0ef33295 upstream. Make sure to use the current alternate setting when verifying the storage interface descriptors to avoid submitting an URB to an invalid endpoint. Failing to do so could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: 36bcce43 ("ath9k_htc: Handle storage devices") Cc: stable <stable@vger.kernel.org> # 2.6.39 Signed-off-by:
-
Paulo Alcantara (SUSE) authored
commit 0a5a9886 upstream. __smb2_handle_cancelled_cmd() is called under a spin lock held in cifs_mid_q_entry_release(), so make its memory allocation GFP_ATOMIC. This issue was observed when running xfstests generic/028: [ 1722.589204] CIFS VFS: \\192.168.30.26 Cancelling wait for mid 72064 cmd: 5 [ 1722.590687] CIFS VFS: \\192.168.30.26 Cancelling wait for mid 72065 cmd: 17 [ 1722.593529] CIFS VFS: \\192.168.30.26 Cancelling wait for mid 72066 cmd: 6 [ 1723.039014] BUG: sleeping function called from invalid context at mm/slab.h:565 [ 1723.040710] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 30877, name: cifsd [ 1723.045098] CPU: 3 PID: 30877 Comm: cifsd Not tainted 5.5.0-rc4+ #313 [ 1723.046256] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014 [ 1723.048221] Call Trace: [ 1723.048689] dump_stack+0x97/0xe0 [ 1723.049268] ___might_sleep.cold+0xd1/0xe1 [ 1723.050069] kmem_cache_alloc_trace+0x204/0x2b0 [ 1723.051051] __smb2_handle_cancelled_cmd+0x40/0x140 [cifs] [ 1723.052137] smb2_handle_cancelled_mid+0xf6/0x120 [cifs] [ 1723.053247] cifs_mid_q_entry_release+0x44d/0x630 [cifs] [ 1723.054351] ? cifs_reconnect+0x26a/0x1620 [cifs] [ 1723.055325] cifs_demultiplex_thread+0xad4/0x14a0 [cifs] [ 1723.056458] ? cifs_handle_standard+0x2c0/0x2c0 [cifs] [ 1723.057365] ? kvm_sched_clock_read+0x14/0x30 [ 1723.058197] ? sched_clock+0x5/0x10 [ 1723.058838] ? sched_clock_cpu+0x18/0x110 [ 1723.059629] ? lockdep_hardirqs_on+0x17d/0x250 [ 1723.060456] kthread+0x1ab/0x200 [ 1723.061149] ? cifs_handle_standard+0x2c0/0x2c0 [cifs] [ 1723.062078] ? kthread_create_on_node+0xd0/0xd0 [ 1723.062897] ret_from_fork+0x3a/0x50 Signed-off-by:
Paulo Alcantara (SUSE) <pc@cjr.nz> Fixes: 9150c3ad ("CIFS: Close open handle after interrupted close") Cc: Stable <stable@vger.kernel.org> Signed-off-by:
Steve French <stfrench@microsoft.com> Reviewed-by:
Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by:
-
Ronnie Sahlberg authored
commit 731b82bb upstream. Fix two places where we need to adjust down the max response size for ioctl when it is used together with compounding. Signed-off-by:
Ronnie Sahlberg <lsahlber@redhat.com> Signed-off-by:
-
Vincent Whitchurch authored
commit f1f27ad7 upstream. The task which created the MID may be gone by the time cifsd attempts to call the callbacks on MIDs from cifs_reconnect(). This leads to a use-after-free of the task struct in cifs_wake_up_task: ================================================================== BUG: KASAN: use-after-free in __lock_acquire+0x31a0/0x3270 Read of size 8 at addr ffff8880103e3a68 by task cifsd/630 CPU: 0 PID: 630 Comm: cifsd Not tainted 5.5.0-rc6+ #119 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 Call Trace: dump_stack+0x8e/0xcb print_address_description.constprop.5+0x1d3/0x3c0 ? __lock_acquire+0x31a0/0x3270 __kasan_report+0x152/0x1aa ? __lock_acquire+0x31a0/0x3270 ? __lock_acquire+0x31a0/0x3270 kasan_report+0xe/0x20 __lock_acquire+0x31a0/0x3270 ? __wake_up_common+0x1dc/0x630 ? _raw_spin_unlock_irqrestore+0x4c/0x60 ? mark_held_locks+0xf0/0xf0 ? _raw_spin_unlock_irqrestore+0x39/0x60 ? __wake_up_common_lock+0xd5/0x130 ? __wake_up_common+0x630/0x630 lock_acquire+0x13f/0x330 ? try_to_wake_up+0xa3/0x19e0 _raw_spin_lock_irqsave+0x38/0x50 ? try_to_wake_up+0xa3/0x19e0 try_to_wake_up+0xa3/0x19e0 ? cifs_compound_callback+0x178/0x210 ? set_cpus_allowed_ptr+0x10/0x10 cifs_reconnect+0xa1c/0x15d0 ? generic_ip_connect+0x1860/0x1860 ? rwlock_bug.part.0+0x90/0x90 cifs_readv_from_socket+0x479/0x690 cifs_read_from_socket+0x9d/0xe0 ? cifs_readv_from_socket+0x690/0x690 ? mempool_resize+0x690/0x690 ? rwlock_bug.part.0+0x90/0x90 ? memset+0x1f/0x40 ? allocate_buffers+0xff/0x340 cifs_demultiplex_thread+0x388/0x2a50 ? cifs_handle_standard+0x610/0x610 ? rcu_read_lock_held_common+0x120/0x120 ? mark_lock+0x11b/0xc00 ? __lock_acquire+0x14ed/0x3270 ? __kthread_parkme+0x78/0x100 ? lockdep_hardirqs_on+0x3e8/0x560 ? lock_downgrade+0x6a0/0x6a0 ? lockdep_hardirqs_on+0x3e8/0x560 ? _raw_spin_unlock_irqrestore+0x39/0x60 ? cifs_handle_standard+0x610/0x610 kthread+0x2bb/0x3a0 ? kthread_create_worker_on_cpu+0xc0/0xc0 ret_from_fork+0x3a/0x50 Allocated by task 649: save_stack+0x19/0x70 __kasan_kmalloc.constprop.5+0xa6/0xf0 kmem_cache_alloc+0x107/0x320 copy_process+0x17bc/0x5370 _do_fork+0x103/0xbf0 __x64_sys_clone+0x168/0x1e0 do_syscall_64+0x9b/0xec0 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 0: save_stack+0x19/0x70 __kasan_slab_free+0x11d/0x160 kmem_cache_free+0xb5/0x3d0 rcu_core+0x52f/0x1230 __do_softirq+0x24d/0x962 The buggy address belongs to the object at ffff8880103e32c0 which belongs to the cache task_struct of size 6016 The buggy address is located 1960 bytes inside of 6016-byte region [ffff8880103e32c0, ffff8880103e4a40) The buggy address belongs to the page: page:ffffea000040f800 refcount:1 mapcount:0 mapping:ffff8880108da5c0 index:0xffff8880103e4c00 compound_mapcount: 0 raw: 4000000000010200 ffffea00001f2208 ffffea00001e3408 ffff8880108da5c0 raw: ffff8880103e4c00 0000000000050003 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880103e3900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880103e3980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880103e3a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880103e3a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880103e3b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== This can be reliably reproduced by adding the below delay to cifs_reconnect(), running find(1) on the mount, restarting the samba server while find is running, and killing find during the delay: spin_unlock(&GlobalMid_Lock); mutex_unlock(&server->srv_mutex); + msleep(10000); + cifs_dbg(FYI, "%s: issuing mid callbacks\n", __func__); list_for_each_safe(tmp, tmp2, &retry_list) { mid_entry = list_entry(tmp, struct mid_q_entry, qhead); Fix this by holding a reference to the task struct until the MID is freed. Signed-off-by:
Vincent Whitchurch <vincent.whitchurch@axis.com> Signed-off-by:
-
Eric Biggers authored
commit bd56cea0 upstream. The chelsio crypto driver is casting 'struct crypto_aead' directly to 'struct crypto_tfm', which is incorrect because the crypto_tfm isn't the first field of 'struct crypto_aead'. Consequently, the calls to crypto_tfm_set_flags() are modifying some other field in the struct. Also, the driver is setting CRYPTO_TFM_RES_BAD_KEY_LEN in ->setauthsize(), not just in ->setkey(). This is incorrect since this flag is for bad key lengths, not for bad authentication tag lengths. Fix these bugs by removing the broken crypto_tfm_set_flags() calls from ->setauthsize() and by fixing them in ->setkey(). Fixes: 324429d7 ("chcr: Support for Chelsio's Crypto Hardware") Cc: <stable@vger.kernel.org> # v4.9+ Cc: Atul Gupta <atul.gupta@chelsio.com> Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
Guenter Roeck authored
commit 264d2527 upstream. Since commit 57ea974f ("driver core: Rewrite test_async_driver_probe to cover serialization and NUMA affinity"), running the test with NUMA disabled results in warning messages similar to the following. test_async_driver test_async_driver.12: NUMA node mismatch -1 != 0 If CONFIG_NUMA=n, dev_to_node(dev) returns -1, and numa_node_id() returns 0. Both are widely used, so it appears risky to change return values. Augment the check with IS_ENABLED(CONFIG_NUMA) instead to fix the problem. Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com> Fixes: 57ea974f ("driver core: Rewrite test_async_driver_probe to cover serialization and NUMA affinity") Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Cc: stable <stable@vger.kernel.org> Acked-by:
Alexander Duyck <alexander.h.duyck@linux.intel.com> Link: https://lore.kernel.org/r/20191127202453.28087-1-linux@roeck-us.net Signed-off-by:
-
Andy Shevchenko authored
commit e825070f upstream. The commit 41c128cb ("iio: st_gyro: Add lsm9ds0-gyro support") assumes that gyro in LSM9DS0 is the same as others with 0xd4 WAI ID, but datasheet tells slight different story, i.e. the first scale factor for the chip is 245 dps, and not 250 dps. Correct this by introducing a separate settings for LSM9DS0. Fixes: 41c128cb ("iio: st_gyro: Add lsm9ds0-gyro support") Depends-on: 45a4e422 ("iio: gyro: st_gyro: fix L3GD20H support") Cc: Leonard Crestez <leonard.crestez@nxp.com> Cc: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> Cc: <Stable@vger.kernel.org> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Olivier Moysan authored
commit dc26935f upstream. Apply data formatting to single conversion, as this is already done in continuous and trigger modes. Fixes: 102afde6 ("iio: adc: stm32-dfsdm: manage data resolution in trigger mode") Signed-off-by:
Olivier Moysan <olivier.moysan@st.com> Cc: <Stable@vger.kernel.org> Acked-by:
Fabrice Gasnier <fabrice.gasnier@st.com> Signed-off-by:
-
Tomas Winkler authored
commit 0db4a15d upstream. Add Jasper Point (Jasper Lake) device id for MEI Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200124001455.24176-1-tomas.winkler@intel.com Signed-off-by:
-
Tomas Winkler authored
commit 559e575a upstream. Add Comet Point device IDs for Comet Lake H platforms. Cc: <stable@vger.kernel.org> Signed-off-by:
-
Tomas Winkler authored
commit 1e8d19d9 upstream. The mei device and i915 must reside on the same PCH in order for HDCP to work. Make the component matching function enforce this requirement. hdcp | i915 mei | | +----= PCH =----+ Cc: <stable@vger.kernel.org> v5.0+ Cc: Ramalingam C <ramalingam.c@intel.com> Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Link: https://lore.kernel.org/r/20191212084103.2893-1-tomas.winkler@intel.com Signed-off-by:
-
Martin Fuzzey authored
commit eb143f87 upstream. Since commit 43e23b6c ("debugfs: log errors when something goes wrong") debugfs logs attempts to create existing files. However binder attempts to create multiple debugfs files with the same name when a single PID has multiple contexts, this leads to log spamming during an Android boot (17 such messages during boot on my system). Fix this by checking if we already know the PID and only create the debugfs entry for the first context per PID. Do the same thing for binderfs for symmetry. Signed-off-by:
Martin Fuzzey <martin.fuzzey@flowbird.group> Acked-by:
Todd Kjos <tkjos@google.com> Fixes: 43e23b6c ("debugfs: log errors when something goes wrong") Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1578671054-5982-1-git-send-email-martin.fuzzey@flowbird.group Signed-off-by:
-
Lubomir Rintel authored
commit ef9ffc1e upstream. The match data does not have to be a struct device pointer, and indeed very often is not. Attempt to treat it as such easily results in a crash. For the components that are not registered, we don't know which device is missing. Once it it is there, we can use the struct component to get the device and whether it's bound or not. Fixes: 59e73854 ('component: add debugfs support') Signed-off-by:
Lubomir Rintel <lkundrak@v3.sk> Cc: stable <stable@vger.kernel.org> Cc: Arnaud Pouliquen <arnaud.pouliquen@st.com> Link: https://lore.kernel.org/r/20191118115431.63626-1-lkundrak@v3.sk Signed-off-by:
-
Eric Snowberg authored
commit a37f4958 upstream. When lockdown is enabled, debugfs_is_locked_down returns 1. It will then trigger the following: WARNING: CPU: 48 PID: 3747 CPU: 48 PID: 3743 Comm: bash Not tainted 5.4.0-1946.x86_64 #1 Hardware name: Oracle Corporation ORACLE SERVER X7-2/ASM, MB, X7-2, BIOS 41060400 05/20/2019 RIP: 0010:do_dentry_open+0x343/0x3a0 Code: 00 40 08 00 45 31 ff 48 c7 43 28 40 5b e7 89 e9 02 ff ff ff 48 8b 53 28 4c 8b 72 70 4d 85 f6 0f 84 10 fe ff ff e9 f5 fd ff ff <0f> 0b 41 bf ea ff ff ff e9 3b ff ff ff 41 bf e6 ff ff ff e9 b4 fe RSP: 0018:ffffb8740dde7ca0 EFLAGS: 00010202 RAX: ffffffff89e88a40 RBX: ffff928c8e6b6f00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff928dbfd97778 RDI: ffff9285cff685c0 RBP: ffffb8740dde7cc8 R08: 0000000000000821 R09: 0000000000000030 R10: 0000000000000057 R11: ffffb8740dde7a98 R12: ffff926ec781c900 R13: ffff928c8e6b6f10 R14: ffffffff8936e190 R15: 0000000000000001 FS: 00007f45f6777740(0000) GS:ffff928dbfd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fff95e0d5d8 CR3: 0000001ece562006 CR4: 00000000007606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: vfs_open+0x2d/0x30 path_openat+0x2d4/0x1680 ? tty_mode_ioctl+0x298/0x4c0 do_filp_open+0x93/0x100 ? strncpy_from_user+0x57/0x1b0 ? __alloc_fd+0x46/0x150 do_sys_open+0x182/0x230 __x64_sys_openat+0x20/0x30 do_syscall_64+0x60/0x1b0 entry_SYSCALL_64_after_hwframe+0x170/0x1d5 RIP: 0033:0x7f45f5e5ce02 Code: 25 00 00 41 00 3d 00 00 41 00 74 4c 48 8d 05 25 59 2d 00 8b 00 85 c0 75 6d 89 f2 b8 01 01 00 00 48 89 fe bf 9c ff ff ff 0f 05 <48> 3d 00 f0 ff ff 0f 87 a2 00 00 00 48 8b 4c 24 28 64 48 33 0c 25 RSP: 002b:00007fff95e0d2e0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 RAX: ffffffffffffffda RBX: 0000561178c069b0 RCX: 00007f45f5e5ce02 RDX: 0000000000000241 RSI: 0000561178c08800 RDI: 00000000ffffff9c RBP: 00007fff95e0d3e0 R08: 0000000000000020 R09: 0000000000000005 R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000003 R14: 0000000000000001 R15: 0000561178c08800 Change the return type to int and return -EPERM when lockdown is enabled to remove the warning above. Also rename debugfs_is_locked_down to debugfs_locked_down to make it sound less like it returns a boolean. Fixes: 5496197f ("debugfs: Restrict debugfs when the kernel is locked down") Signed-off-by:
Eric Snowberg <eric.snowberg@oracle.com> Reviewed-by:
Matthew Wilcox (Oracle) <willy@infradead.org> Cc: stable <stable@vger.kernel.org> Acked-by:
James Morris <jamorris@linux.microsoft.com> Link: https://lore.kernel.org/r/20191207161603.35907-1-eric.snowberg@oracle.com Signed-off-by:
-
Uwe Kleine-König authored
commit 101aa46b upstream. The main irq handler function starts by first masking disabled interrupts in the status register values to ensure to only handle enabled interrupts. This is important as when the RX path in the hardware is disabled reading the RX fifo results in an external abort. This checking must be done under the port lock, otherwise the following can happen: CPU1 | CPU2 | irq triggers as there are chars | in the RX fifo | | grab port lock imx_uart_int finds RRDY enabled | and calls imx_uart_rxint which | has to wait for port lock | | disable RX (e.g. because we're | using RS485 with !RX_DURING_TX) | | release port lock read from RX fifo with RX | disabled => exception | So take the port lock only once in imx_uart_int() instead of in the functions called from there. Reported-by:
Andre Renaud <arenaud@designa-electronics.com> Cc: stable@vger.kernel.org Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20200121071702.20150-1-u.kleine-koenig@pengutronix.de Signed-off-by:
-
