user/sven/linux.git/drivers/char, branch v4.19.85

crypto: chacha20 - Fix chacha20_block() keystream alignment (again)

2019-11-20T17:47:11Z

[ Upstream commit a5e9f557098e54af44ade5d501379be18435bfbf ] In commit 9f480faec58c ("crypto: chacha20 - Fix keystream alignment for chacha20_block()"), I had missed that chacha20_block() can be called directly on the buffer passed to get_random_bytes(), which can have any alignment. So, while my commit didn't break anything, it didn't fully solve the alignment problems. Revert my solution and just update chacha20_block() to use put_unaligned_le32(), so the output buffer need not be aligned. This is simpler, and on many CPUs it's the same speed. But, I kept the 'tmp' buffers in extract_crng_user() and _get_random_bytes() 4-byte aligned, since that alignment is actually needed for _crng_backtrack_protect() too. Reported-by: Stephan Müller Cc: Theodore Ts'o Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

ipmi: fix return value of ipmi_set_my_LUN

2019-11-20T17:46:56Z

[ Upstream commit 060e8fb53fe3455568982d10ab8c3dd605565049 ] Fixes gcc '-Wunused-but-set-variable' warning: drivers/char/ipmi/ipmi_msghandler.c: In function 'ipmi_set_my_LUN': drivers/char/ipmi/ipmi_msghandler.c:1335:13: warning: variable 'rv' set but not used [-Wunused-but-set-variable] int index, rv = 0; 'rv' should be the correct return value. Fixes: 048f7c3e352e ("ipmi: Properly release srcu locks on error conditions") Signed-off-by: YueHaibing Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin

ipmi:dmi: Ignore IPMI SMBIOS entries with a zero base address

2019-11-20T17:46:56Z

[ Upstream commit 1574608f5f4204440d6d9f52b971aba967664764 ] Looking at logs from systems all over the place, it looks like tons of broken systems exist that set the base address to zero. I can only guess that is some sort of non-standard idea to mark the interface as not being present. It can't be zero, anyway, so just complain and ignore it. Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin

ipmi_si: fix potential integer overflow on large shift

2019-11-20T17:46:56Z

[ Upstream commit 97a103e6b584442cd848887ed8d47be2410b7e09 ] Shifting unsigned char b by an int type can lead to sign-extension overflow. For example, if b is 0xff and the shift is 24, then top bit is sign-extended so the final value passed to writeq has all the upper 32 bits set. Fix this by casting b to a 64 bit unsigned before the shift. Detected by CoverityScan, CID#1465246 ("Unintended sign extension") Signed-off-by: Colin Ian King Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin

ipmi_si_pci: fix NULL device in ipmi_si error message

2019-11-20T17:46:55Z

[ Upstream commit 01508d9ebf4fc863f2fc4561c390bf4b7c3301a6 ] I noticed that 4.17.0 logs the follwing during ipmi_si setup: ipmi_si 0000:01:04.6: probing via PCI (NULL device *): Could not setup I/O space ipmi_si 0000:01:04.6: [mem 0xf5ef0000-0xf5ef00ff] regsize 1 spacing 1 irq 21 Fix the "NULL device *) by moving io.dev assignment before its potential use by ipmi_pci_probe_regspacing(). Result: ipmi_si 0000:01:04.6: probing via PCI ipmi_si 0000:01:04.6: Could not setup I/O space ipmi_si 0000:01:04.6: [mem 0xf5ef0000-0xf5ef00ff] regsize 1 spacing 1 irq 21 Signed-off-by: Meelis Roos Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin

ipmi_si: Only schedule continuously in the thread in maintenance mode

2019-10-07T16:56:39Z

[ Upstream commit 340ff31ab00bca5c15915e70ad9ada3030c98cf8 ] ipmi_thread() uses back-to-back schedule() to poll for command completion which, on some machines, can push up CPU consumption and heavily tax the scheduler locks leading to noticeable overall performance degradation. This was originally added so firmware updates through IPMI would complete in a timely manner. But we can't kill the scheduler locks for that one use case. Instead, only run schedule() continuously in maintenance mode, where firmware updates should run. Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin

tpm: Fix TPM 1.2 Shutdown sequence to prevent future TPM operations

2019-10-07T16:56:28Z

commit db4d8cb9c9f2af71c4d087817160d866ed572cc9 upstream TPM 2.0 Shutdown involve sending TPM2_Shutdown to TPM chip and disabling future TPM operations. TPM 1.2 behavior was different, future TPM operations weren't disabled, causing rare issues. This patch ensures that future TPM operations are disabled. Fixes: d1bd4a792d39 ("tpm: Issue a TPM2_Shutdown for TPM2 devices.") Cc: stable@vger.kernel.org Signed-off-by: Vadim Sukhomlinov [dianders: resolved merge conflicts with mainline] Signed-off-by: Douglas Anderson Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin

tpm: use tpm_try_get_ops() in tpm-sysfs.c.

2019-10-07T16:56:27Z

commit 2677ca98ae377517930c183248221f69f771c921 upstream Use tpm_try_get_ops() in tpm-sysfs.c so that we can consider moving other decorations (locking, localities, power management for example) inside it. This direction can be of course taken only after other call sites for tpm_transmit() have been treated in the same way. Signed-off-by: Jarkko Sakkinen Reviewed-by: Stefan Berger Tested-by: Stefan Berger Reviewed-by: Jerry Snitselaar Reviewed-by: James Bottomley Tested-by: Alexander Steffen Signed-off-by: Sasha Levin

hwrng: core - don't wait on add_early_randomness()

2019-10-05T11:10:12Z

commit 78887832e76541f77169a24ac238fccb51059b63 upstream. add_early_randomness() is called by hwrng_register() when the hardware is added. If this hardware and its module are present at boot, and if there is no data available the boot hangs until data are available and can't be interrupted. For instance, in the case of virtio-rng, in some cases the host can be not able to provide enough entropy for all the guests. We can have two easy ways to reproduce the problem but they rely on misconfiguration of the hypervisor or the egd daemon: - if virtio-rng device is configured to connect to the egd daemon of the host but when the virtio-rng driver asks for data the daemon is not connected, - if virtio-rng device is configured to connect to the egd daemon of the host but the egd daemon doesn't provide data. The guest kernel will hang at boot until the virtio-rng driver provides enough data. To avoid that, call rng_get_data() in non-blocking mode (wait=0) from add_early_randomness(). Signed-off-by: Laurent Vivier Fixes: d9e797261933 ("hwrng: add randomness to system from rng...") Cc: Reviewed-by: Theodore Ts'o Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

/dev/mem: Bail out upon SIGKILL.

2019-10-05T11:10:11Z

commit 8619e5bdeee8b2c685d686281f2d2a6017c4bc15 upstream. syzbot found that a thread can stall for minutes inside read_mem() or write_mem() after that thread was killed by SIGKILL [1]. Reading from iomem areas of /dev/mem can be slow, depending on the hardware. While reading 2GB at one read() is legal, delaying termination of killed thread for minutes is bad. Thus, allow reading/writing /dev/mem and /dev/kmem to be preemptible and killable. [ 1335.912419][T20577] read_mem: sz=4096 count=2134565632 [ 1335.943194][T20577] read_mem: sz=4096 count=2134561536 [ 1335.978280][T20577] read_mem: sz=4096 count=2134557440 [ 1336.011147][T20577] read_mem: sz=4096 count=2134553344 [ 1336.041897][T20577] read_mem: sz=4096 count=2134549248 Theoretically, reading/writing /dev/mem and /dev/kmem can become "interruptible". But this patch chose "killable". Future patch will make them "interruptible" so that we can revert to "killable" if some program regressed. [1] https://syzkaller.appspot.com/bug?id=a0e3436829698d5824231251fad9d8e998f94f5e Signed-off-by: Tetsuo Handa Cc: stable Reported-by: syzbot Link: https://lore.kernel.org/r/1566825205-10703-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman