user/sven/linux.git, branch v5.5.1

Linux 5.5.1

2020-02-01T09:33:01Z

power/supply: ingenic-battery: Don't change scale if there's only one

2020-02-01T09:33:00Z

commit 86b9182df8bb12610d4d6feac45a69f3ed57bfd2 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: fb24ccfbe1e0 ("power: supply: add Ingenic JZ47xx battery driver.") Signed-off-by: Paul Cercueil Acked-by: Artur Rojek Cc: stable@vger.kernel.org Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman

Revert "um: Enable CONFIG_CONSTRUCTORS"

2020-02-01T09:33:00Z

commit 87c9366e17259040a9118e06b6dc8de986e5d3d1 upstream. This reverts commit 786b2384bf1c ("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: 786b2384bf1c ("um: Enable CONFIG_CONSTRUCTORS") Reported-by: Anton Ivanov Signed-off-by: Johannes Berg Acked-by: Anton Ivanov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Richard Weinberger

KVM: arm64: Write arch.mdcr_el2 changes since last vcpu_load on VHE

2020-02-01T09:33:00Z

commit 4942dc6638b07b5326b6d2faa142635c559e7cd5 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: d5a21bcc2995 ("KVM: arm64: Move common VHE/non-VHE trap config in separate functions") Cc: # 4.17.x- Suggested-by: James Morse Acked-by: Will Deacon Reviewed-by: Marc Zyngier Signed-off-by: Andrew Murray Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman

crypto: pcrypt - Fix user-after-free on module unload

2020-02-01T09:33:00Z

commit 07bfd9bdf568a38d9440c607b72342036011f727 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: 5068c7a883d1 ("crypto: pcrypt - Add pcrypt crypto...") Cc: Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: caam - do not reset pointer size from MCFGR register

2020-02-01T09:33:00Z

commit 7278fa25aa0ebcc0e62c39b12071069df13f7e77 upstream. In commit 'a1cf573ee95 ("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: a1cf573ee95 ("crypto: caam - select DMA address size at runtime") Signed-off-by: Iuliana Prodan Cc: Cc: Andrey Smirnov Cc: Alison Wang Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: vmx - reject xts inputs that are too short

2020-02-01T09:33:00Z

commit 1372a51b88fa0d5a8ed2803e4975c98da3f08463 upstream. When the kernel XTS implementation was extended to deal with ciphertext stealing in commit 8083b1bf8163 ("crypto: xts - add support for ciphertext stealing"), a check was added to reject inputs that were too short. However, in the vmx enablement - commit 239668419349 ("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=[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 Link: https://bugzilla.kernel.org/show_bug.cgi?id=206049 Fixes: 239668419349 ("crypto: vmx/xts - use fallback for ciphertext stealing") Cc: Ard Biesheuvel Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: Michael Ellerman [dja: commit message] Signed-off-by: Daniel Axtens Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: af_alg - Use bh_lock_sock in sk_destruct

2020-02-01T09:32:59Z

commit 37f96694cf73ba116993a9d2d99ad6a75fa7fdb0 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 Fixes: c840ac6af3f8 ("crypto: af_alg - Disallow bind/setkey/...") Cc: Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

rsi: fix non-atomic allocation in completion handler

2020-02-01T09:32:59Z

commit b9b9f9fea21830f85cf0148cd8dce001ae55ead1 upstream. USB completion handlers are called in atomic context and must specifically not allocate memory using GFP_KERNEL. Fixes: a1854fae1414 ("rsi: improve RX packet handling in USB interface") Cc: stable # 4.17 Cc: Prameela Rani Garnepudi Signed-off-by: Johan Hovold Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman

rsi: fix memory leak on failed URB submission

2020-02-01T09:32:59Z

commit 47768297481184932844ab01a86752ba31a38861 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: a1854fae1414 ("rsi: improve RX packet handling in USB interface") Cc: stable # 4.17 Cc: Prameela Rani Garnepudi Signed-off-by: Johan Hovold Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman