summaryrefslogtreecommitdiff
path: root/drivers/char
AgeCommit message (Collapse)AuthorFilesLines
2022-05-12Merge commit '49caedb668e476c100d727f2174724e0610a2b92' of ↵Sujoy Ray11-67/+294
https://github.com/openbmc/linux into openbmc/dev-5.15-intel-bump_v5.15.36 Signed-off-by: Sujoy Ray <sujoy.ray@intel.com>
2022-04-14Merge tag 'v5.15.34' into dev-5.15Joel Stanley10-66/+290
This is the 5.15.34 stable release Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-04-13virtio_console: eliminate anonymous module_init & module_exitRandy Dunlap1-4/+4
[ Upstream commit fefb8a2a941338d871e2d83fbd65fbfa068857bd ] Eliminate anonymous module_init() and module_exit(), which can lead to confusion or ambiguity when reading System.map, crashes/oops/bugs, or an initcall_debug log. Give each of these init and exit functions unique driver-specific names to eliminate the anonymous names. Example 1: (System.map) ffffffff832fc78c t init ffffffff832fc79e t init ffffffff832fc8f8 t init Example 2: (initcall_debug log) calling init+0x0/0x12 @ 1 initcall init+0x0/0x12 returned 0 after 15 usecs calling init+0x0/0x60 @ 1 initcall init+0x0/0x60 returned 0 after 2 usecs calling init+0x0/0x9a @ 1 initcall init+0x0/0x9a returned 0 after 74 usecs Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Amit Shah <amit@kernel.org> Cc: virtualization@lists.linux-foundation.org Cc: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20220316192010.19001-3-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08hwrng: nomadik - Change clk_disable to clk_disable_unprepareMiaoqian Lin1-2/+2
[ Upstream commit 7f0f1f3ef62ed7a40e30aff28115bd94c4211d1d ] The corresponding API for clk_prepare_enable is clk_disable_unprepare, other than clk_disable_unprepare. Fix this by changing clk_disable to clk_disable_unprepare. Fixes: beca35d05cc2 ("hwrng: nomadik - use clk_prepare_enable()") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08hwrng: atmel - disable trng on failure pathClaudiu Beznea1-0/+1
[ Upstream commit a223ea9f89ab960eb254ba78429efd42eaf845eb ] Call atmel_trng_disable() on failure path of probe. Fixes: a1fa98d8116f ("hwrng: atmel - disable TRNG during suspend") Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08hwrng: cavium - HW_RANDOM_CAVIUM should depend on ARCH_THUNDERGeert Uytterhoeven1-1/+1
[ Upstream commit ab7d88549e2f7ae116afd303f32e1950cb790a1d ] The Cavium ThunderX Random Number Generator is only present on Cavium ThunderX SoCs, and not available as an independent PCIe endpoint. Hence add a dependency on ARCH_THUNDER, to prevent asking the user about this driver when configuring a kernel without Cavium Thunder SoC support. Fixes: cc2f1908c6b8f625 ("hwrng: cavium - Add Cavium HWRNG driver for ThunderX SoC.") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08hwrng: cavium - Check health status while reading random dataSunil Goutham3-17/+190
[ Upstream commit 680efb33546be8960ccbb2f4e0e43034d9c93b30 ] This RNG device is present on Marvell OcteonTx2 silicons as well and also provides entropy health status. HW continuously checks health condition of entropy and reports faults. Fault is in terms of co-processor cycles since last fault detected. This doesn't get cleared and only updated when new fault is detected. Also there are chances of detecting false positives. So to detect a entropy failure SW has to check if failures are persistent ie cycles elapsed is frequently updated by HW. This patch adds support to detect health failures using below algo. 1. Consider any fault detected before 10ms as a false positive and ignore. 10ms is chosen randomly, no significance. 2. Upon first failure detection make a note of cycles elapsed and when this error happened in realtime (cntvct). 3. Upon subsequent failure, check if this is new or a old one by comparing current cycles with the ones since last failure. cycles or time since last failure is calculated using cycles and time info captured at (2). HEALTH_CHECK status register is not available to VF, hence had to map PF registers. Also since cycles are in terms of co-processor cycles, had to retrieve co-processor clock rate from RST device. Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08tpm: fix reference counting for struct tpm_chipLino Sanfilippo3-38/+75
commit 7e0438f83dc769465ee663bb5dcf8cc154940712 upstream. The following sequence of operations results in a refcount warning: 1. Open device /dev/tpmrm. 2. Remove module tpm_tis_spi. 3. Write a TPM command to the file descriptor opened at step 1. ------------[ cut here ]------------ WARNING: CPU: 3 PID: 1161 at lib/refcount.c:25 kobject_get+0xa0/0xa4 refcount_t: addition on 0; use-after-free. Modules linked in: tpm_tis_spi tpm_tis_core tpm mdio_bcm_unimac brcmfmac sha256_generic libsha256 sha256_arm hci_uart btbcm bluetooth cfg80211 vc4 brcmutil ecdh_generic ecc snd_soc_core crc32_arm_ce libaes raspberrypi_hwmon ac97_bus snd_pcm_dmaengine bcm2711_thermal snd_pcm snd_timer genet snd phy_generic soundcore [last unloaded: spi_bcm2835] CPU: 3 PID: 1161 Comm: hold_open Not tainted 5.10.0ls-main-dirty #2 Hardware name: BCM2711 [<c0410c3c>] (unwind_backtrace) from [<c040b580>] (show_stack+0x10/0x14) [<c040b580>] (show_stack) from [<c1092174>] (dump_stack+0xc4/0xd8) [<c1092174>] (dump_stack) from [<c0445a30>] (__warn+0x104/0x108) [<c0445a30>] (__warn) from [<c0445aa8>] (warn_slowpath_fmt+0x74/0xb8) [<c0445aa8>] (warn_slowpath_fmt) from [<c08435d0>] (kobject_get+0xa0/0xa4) [<c08435d0>] (kobject_get) from [<bf0a715c>] (tpm_try_get_ops+0x14/0x54 [tpm]) [<bf0a715c>] (tpm_try_get_ops [tpm]) from [<bf0a7d6c>] (tpm_common_write+0x38/0x60 [tpm]) [<bf0a7d6c>] (tpm_common_write [tpm]) from [<c05a7ac0>] (vfs_write+0xc4/0x3c0) [<c05a7ac0>] (vfs_write) from [<c05a7ee4>] (ksys_write+0x58/0xcc) [<c05a7ee4>] (ksys_write) from [<c04001a0>] (ret_fast_syscall+0x0/0x4c) Exception stack(0xc226bfa8 to 0xc226bff0) bfa0: 00000000 000105b4 00000003 beafe664 00000014 00000000 bfc0: 00000000 000105b4 000103f8 00000004 00000000 00000000 b6f9c000 beafe684 bfe0: 0000006c beafe648 0001056c b6eb6944 ---[ end trace d4b8409def9b8b1f ]--- The reason for this warning is the attempt to get the chip->dev reference in tpm_common_write() although the reference counter is already zero. Since commit 8979b02aaf1d ("tpm: Fix reference count to main device") the extra reference used to prevent a premature zero counter is never taken, because the required TPM_CHIP_FLAG_TPM2 flag is never set. Fix this by moving the TPM 2 character device handling from tpm_chip_alloc() to tpm_add_char_device() which is called at a later point in time when the flag has been set in case of TPM2. Commit fdc915f7f719 ("tpm: expose spaces via a device link /dev/tpmrm<n>") already introduced function tpm_devs_release() to release the extra reference but did not implement the required put on chip->devs that results in the call of this function. Fix this by putting chip->devs in tpm_chip_unregister(). Finally move the new implementation for the TPM 2 handling into a new function to avoid multiple checks for the TPM_CHIP_FLAG_TPM2 flag in the good case and error cases. Cc: stable@vger.kernel.org Fixes: fdc915f7f719 ("tpm: expose spaces via a device link /dev/tpmrm<n>") Fixes: 8979b02aaf1d ("tpm: Fix reference count to main device") Co-developed-by: Jason Gunthorpe <jgg@ziepe.ca> Signed-off-by: Jason Gunthorpe <jgg@ziepe.ca> Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de> Tested-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-08virtio_console: break out of buf poll on removeMichael S. Tsirkin1-0/+7
[ Upstream commit 0e7174b9d5877130fec41fb4a16e0c2ee4958d44 ] A common pattern for device reset is currently: vdev->config->reset(vdev); .. cleanup .. reset prevents new interrupts from arriving and waits for interrupt handlers to finish. However if - as is common - the handler queues a work request which is flushed during the cleanup stage, we have code adding buffers / trying to get buffers while device is reset. Not good. This was reproduced by running modprobe virtio_console modprobe -r virtio_console in a loop. Fix this up by calling virtio_break_device + flush before reset. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1786239 Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-03-28tpm: use try_get_ops() in tpm-space.cJames Bottomley1-4/+4
commit fb5abce6b2bb5cb3d628aaa63fa821da8c4600f9 upstream. As part of the series conversion to remove nested TPM operations: https://lore.kernel.org/all/20190205224723.19671-1-jarkko.sakkinen@linux.intel.com/ exposure of the chip->tpm_mutex was removed from much of the upper level code. In this conversion, tpm2_del_space() was missed. This didn't matter much because it's usually called closely after a converted operation, so there's only a very tiny race window where the chip can be removed before the space flushing is done which causes a NULL deref on the mutex. However, there are reports of this window being hit in practice, so fix this by converting tpm2_del_space() to use tpm_try_get_ops(), which performs all the teardown checks before acquring the mutex. Cc: stable@vger.kernel.org # 5.4.x Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-28tpm: Fix error handling in async workTadeusz Struk1-1/+7
commit 2e8e4c8f6673247e22efc7985ce5497accd16f88 upstream. When an invalid (non existing) handle is used in a TPM command, that uses the resource manager interface (/dev/tpmrm0) the resource manager tries to load it from its internal cache, but fails and the tpm_dev_transmit returns an -EINVAL error to the caller. The existing async handler doesn't handle these error cases currently and the condition in the poll handler never returns mask with EPOLLIN set. The result is that the poll call blocks and the application gets stuck until the user_read_timer wakes it up after 120 sec. Change the tpm_dev_async_work function to handle error conditions returned from tpm_dev_transmit they are also reflected in the poll mask and a correct error code could passed back to the caller. Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: <linux-integrity@vger.kernel.org> Cc: <stable@vger.kernel.org> Cc: <linux-kernel@vger.kernel.org> Fixes: 9e1b74a63f77 ("tpm: add support for nonblocking operation") Tested-by: Jarkko Sakkinen<jarkko@kernel.org> Signed-off-by: Tadeusz Struk <tstruk@gmail.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Cc: Tadeusz Struk <tadeusz.struk@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-11Merge commit '2befcc6bb0bb1e0a4a31391a359adcab3925b6e4' of ↵Sujoy Ray17-132/+498
https://github.com/openbmc/linux into openbmc/linux_5.15.24_bump Signed-off-by: Sujoy Ray <sujoy.ray@intel.com>
2022-03-08Merge tag 'v5.15.26' into dev-5.15Joel Stanley1-1/+4
This is the 5.15.26 stable release Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-02-23random: wake up /dev/random writers after zapJason A. Donenfeld1-1/+4
[ Upstream commit 042e293e16e3aa9794ce60c29f5b7b0c8170f933 ] When account() is called, and the amount of entropy dips below random_write_wakeup_bits, we wake up the random writers, so that they can write some more in. However, the RNDZAPENTCNT/RNDCLEARPOOL ioctl sets the entropy count to zero -- a potential reduction just like account() -- but does not unblock writers. This commit adds the missing logic to that ioctl to unblock waiting writers. Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-31Merge tag 'v5.15.18' into dev-5.15Joel Stanley3-61/+95
This is the 5.15.18 stable release Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-01-27tpm: fix NPE on probe for missing devicePatrick Williams1-2/+2
commit 84cc69589700b90a4c8d27b481a51fce8cca6051 upstream. When using the tpm_tis-spi driver on a system missing the physical TPM, a null pointer exception was observed. [ 0.938677] Unable to handle kernel NULL pointer dereference at virtual address 00000004 [ 0.939020] pgd = 10c753cb [ 0.939237] [00000004] *pgd=00000000 [ 0.939808] Internal error: Oops: 5 [#1] SMP ARM [ 0.940157] CPU: 0 PID: 48 Comm: kworker/u4:1 Not tainted 5.15.10-dd1e40c #1 [ 0.940364] Hardware name: Generic DT based system [ 0.940601] Workqueue: events_unbound async_run_entry_fn [ 0.941048] PC is at tpm_tis_remove+0x28/0xb4 [ 0.941196] LR is at tpm_tis_core_init+0x170/0x6ac This is due to an attempt in 'tpm_tis_remove' to use the drvdata, which was not initialized in 'tpm_tis_core_init' prior to the first error. Move the initialization of drvdata earlier so 'tpm_tis_remove' has access to it. Signed-off-by: Patrick Williams <patrick@stwcx.xyz> Fixes: 79ca6f74dae0 ("tpm: fix Atmel TPM crash caused by too frequent queries") Cc: stable@vger.kernel.org Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-27tpm: fix potential NULL pointer access in tpm_del_char_deviceLino Sanfilippo1-5/+13
commit eabad7ba2c752392ae50f24a795093fb115b686d upstream. Some SPI controller drivers unregister the controller in the shutdown handler (e.g. BCM2835). If such a controller is used with a TPM 2 slave chip->ops may be accessed when it is already NULL: At system shutdown the pre-shutdown handler tpm_class_shutdown() shuts down TPM 2 and sets chip->ops to NULL. Then at SPI controller unregistration tpm_tis_spi_remove() is called and eventually calls tpm_del_char_device() which tries to shut down TPM 2 again. Thereby it accesses chip->ops again: (tpm_del_char_device calls tpm_chip_start which calls tpm_clk_enable which calls chip->ops->clk_enable). Avoid the NULL pointer access by testing if chip->ops is valid and skipping the TPM 2 shutdown procedure in case it is NULL. Cc: stable@vger.kernel.org Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de> Fixes: 39d0099f9439 ("powerpc/pseries: Add shutdown() to vio_driver and vio_bus") Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Tested-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-27random: do not throw away excess input to crng_fast_loadJason A. Donenfeld1-7/+12
[ Upstream commit 73c7733f122e8d0107f88655a12011f68f69e74b ] When crng_fast_load() is called by add_hwgenerator_randomness(), we currently will advance to crng_init==1 once we've acquired 64 bytes, and then throw away the rest of the buffer. Usually, that is not a problem: When add_hwgenerator_randomness() gets called via EFI or DT during setup_arch(), there won't be any IRQ randomness. Therefore, the 64 bytes passed by EFI exactly matches what is needed to advance to crng_init==1. Usually, DT seems to pass 64 bytes as well -- with one notable exception being kexec, which hands over 128 bytes of entropy to the kexec'd kernel. In that case, we'll advance to crng_init==1 once 64 of those bytes are consumed by crng_fast_load(), but won't continue onward feeding in bytes to progress to crng_init==2. This commit fixes the issue by feeding any leftover bytes into the next phase in add_hwgenerator_randomness(). [linux@dominikbrodowski.net: rewrite commit message] Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27char/mwave: Adjust io port register sizeKees Cook1-1/+1
[ Upstream commit f5912cc19acd7c24b2dbf65a6340bf194244f085 ] Using MKWORD() on a byte-sized variable results in OOB read. Expand the size of the reserved area so both MKWORD and MKBYTE continue to work without overflow. Silences this warning on a -Warray-bounds build: drivers/char/mwave/3780i.h:346:22: error: array subscript 'short unsigned int[0]' is partly outside array bounds of 'DSP_ISA_SLAVE_CONTROL[1]' [-Werror=array-bounds] 346 | #define MKWORD(var) (*((unsigned short *)(&var))) | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/char/mwave/3780i.h:356:40: note: in definition of macro 'OutWordDsp' 356 | #define OutWordDsp(index,value) outw(value,usDspBaseIO+index) | ^~~~~ drivers/char/mwave/3780i.c:373:41: note: in expansion of macro 'MKWORD' 373 | OutWordDsp(DSP_IsaSlaveControl, MKWORD(rSlaveControl)); | ^~~~~~ drivers/char/mwave/3780i.c:358:31: note: while referencing 'rSlaveControl' 358 | DSP_ISA_SLAVE_CONTROL rSlaveControl; | ^~~~~~~~~~~~~ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20211203084206.3104326-1-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27tpm_tis: Fix an error handling path in 'tpm_tis_core_init()'Christophe Jaillet1-1/+1
[ Upstream commit e96d52822f5ac0a25de78f95cd23421bcbc93584 ] Commit 79ca6f74dae0 ("tpm: fix Atmel TPM crash caused by too frequent queries") has moved some code around without updating the error handling path. This is now pointless to 'goto out_err' when neither 'clk_enable()' nor 'ioremap()' have been called yet. Make a direct return instead to avoid undoing things that have not been done. Fixes: 79ca6f74dae0 ("tpm: fix Atmel TPM crash caused by too frequent queries") Signed-off-by: Christophe Jaillet <christophe.jaillet@wanadoo.fr> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27tpm: add request_locality before write TPM_INT_ENABLEChen Jun1-0/+8
[ Upstream commit 0ef333f5ba7f24f5d8478425c163d3097f1c7afd ] Locality is not appropriately requested before writing the int mask. Add the missing boilerplate. Fixes: e6aef069b6e9 ("tpm_tis: convert to using locality callbacks") Signed-off-by: Chen Jun <chenjun102@huawei.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-16random: fix crash on multiple early calls to add_bootloader_randomness()Dominik Brodowski1-20/+36
commit f7e67b8e803185d0aabe7f29d25a35c8be724a78 upstream. Currently, if CONFIG_RANDOM_TRUST_BOOTLOADER is enabled, multiple calls to add_bootloader_randomness() are broken and can cause a NULL pointer dereference, as noted by Ivan T. Ivanov. This is not only a hypothetical problem, as qemu on arm64 may provide bootloader entropy via EFI and via devicetree. On the first call to add_hwgenerator_randomness(), crng_fast_load() is executed, and if the seed is long enough, crng_init will be set to 1. On subsequent calls to add_bootloader_randomness() and then to add_hwgenerator_randomness(), crng_fast_load() will be skipped. Instead, wait_event_interruptible() and then credit_entropy_bits() will be called. If the entropy count for that second seed is large enough, that proceeds to crng_reseed(). However, both wait_event_interruptible() and crng_reseed() depends (at least in numa_crng_init()) on workqueues. Therefore, test whether system_wq is already initialized, which is a sufficient indicator that workqueue_init_early() has progressed far enough. If we wind up hitting the !system_wq case, we later want to do what would have been done there when wqs are up, so set a flag, and do that work later from the rand_initialize() call. Reported-by: Ivan T. Ivanov <iivanov@suse.de> Fixes: 18b915ac6b0a ("efi/random: Treat EFI_RNG_PROTOCOL output as bootloader randomness") Cc: stable@vger.kernel.org Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> [Jason: added crng_need_done state and related logic.] Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-16random: fix data race on crng init timeEric Biggers1-7/+10
commit 009ba8568be497c640cab7571f7bfd18345d7b24 upstream. _extract_crng() does plain loads of crng->init_time and crng_global_init_time, which causes undefined behavior if crng_reseed() and RNDRESEEDCRNG modify these corrently. Use READ_ONCE() and WRITE_ONCE() to make the behavior defined. Don't fix the race on crng->init_time by protecting it with crng->lock, since it's not a problem for duplicate reseedings to occur. I.e., the lockless access with READ_ONCE() is fine. Fixes: d848e5f8e1eb ("random: add new ioctl RNDRESEEDCRNG") Fixes: e192be9d9a30 ("random: replace non-blocking pool with a Chacha20-based CRNG") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com> Acked-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-16random: fix data race on crng_node_poolEric Biggers1-20/+22
commit 5d73d1e320c3fd94ea15ba5f79301da9a8bcc7de upstream. extract_crng() and crng_backtrack_protect() load crng_node_pool with a plain load, which causes undefined behavior if do_numa_crng_init() modifies it concurrently. Fix this by using READ_ONCE(). Note: as per the previous discussion https://lore.kernel.org/lkml/20211219025139.31085-1-ebiggers@kernel.org/T/#u, READ_ONCE() is believed to be sufficient here, and it was requested that it be used here instead of smp_load_acquire(). Also change do_numa_crng_init() to set crng_node_pool using cmpxchg_release() instead of mb() + cmpxchg(), as the former is sufficient here but is more lightweight. Fixes: 1e7f583af67b ("random: make /dev/urandom scalable for silly userspace programs") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com> Acked-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-14Merge tag 'v5.15.14' into dev-5.15Joel Stanley2-11/+17
This is the 5.15.14 stable release Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-01-14tpm: tpm_tis: Add tpm_tis_i2c driverAmir Mizinski3-0/+276
I2C support for TPM devices on the TIS interface is currently available only as a proprietary driver implementation for each TPM vendor. This patch implements the infrastructure for a TCG-compliant TPM TIS I2C driver with the functionality required to communicate with a TPM device over I2C according to the "TCG PC Client PTP Interface Specification" and "Device Driver Design Principles for TPM 2.0" References: [1] "TCG PC Client Platform TPM Profile(PTP) Interface Specification for TPM 2.0" Version 01.03 Revision 22 at: https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/ [2] "TCG PC Client Device Driver Design Principles for TPM 2.0" Version 1.0 Revision 27 at: https://trustedcomputinggroup.org/resource/tcg-pc-client-device-driver-design-principles-for-tpm-2-0/ OpenBMC-Staging-Count: 1 Signed-off-by: Amir Mizinski <amirmizi6@gmail.com> Tested-by: Eddie James <eajames@linux.ibm.com> Tested-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20211104140211.6258-5-amirmizi6@gmail.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-01-14tpm: tpm_tis: Verify TPM_STS register is valid after locality requestAmir Mizinski1-1/+5
An invalid TPM_STS value could be used when the following two events occur: TPM does not update TPM_STS register after a locality request (TPM_STS Initial value = 0xFF), and a TPM_STS register read occurs in the tpm_tis_status(chip) function call. In probe_itpm(), a call to tpm_tis_send_data() function is made after a request_locality() call, and the condition ("if ((status & TPM_STS_COMMAND_READY) == 0)") is checked. At this moment if the status value is 0xFF, then it is considered, wrongly, in “ready” state (by checking only one bit). However, at this moment the TPM is, in fact, in "Idle" state and remains in "Idle" state because "tpm_tis_ready(chip);" was not executed. Waiting for the condition TPM_STS.tpmGo == 0, will ensure that the TPM status register has the correct value. OpenBMC-Staging-Count: 1 Suggested-by: Benoit Houyere <benoit.houyere@st.com> Signed-off-by: Amir Mizinski <amirmizi6@gmail.com> Link: https://lore.kernel.org/r/20211104140211.6258-4-amirmizi6@gmail.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-01-14tpm: tpm_tis: Rewrite "tpm_tis_req_canceled()"Amir Mizinski1-4/+1
tpm_tis_req_canceled() function is used to check if the caller requested to abort the current operation. It was found that in some cases tpm_tis_req_canceled() wrongly returned true. Since a cancel request sets the TPM_STS.commandReady field to TRUE, the tpm_tis_req_canceled() function should check only the TPM_STS.commandReady field value. The case for TPM_VID_WINBOND is wrong and was therefore removed. Also, the default comparison is wrong. Only cmdReady bit needs to be compared instead of the full lower status register byte. OpenBMC-Staging-Count: 1 Signed-off-by: Amir Mizinski <amirmizi6@gmail.com> Link: https://lore.kernel.org/r/20211104140211.6258-3-amirmizi6@gmail.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-01-14tpm_tis: Fix expected bit handlingAmir Mizinski1-34/+27
Currently, the driver polls the TPM_STS.stsValid field until TRUE; then it reads TPM_STS register again to verify only that TPM_STS.expect field is FALSE (i.e., it ignores TPM_STS.stsValid). Since TPM_STS.stsValid represents the TPM_STS.expect validity, a check of only one of these fields is wrong. Fix this condition so that both fields are checked in the same TPM_STS register read. Modify the signature of wait_for_tpm_stat() to tpm_tis_wait_for_stat(), adding an additional "expected" parameter to its call. tpm_tis_wait_for_stat() is now polling the TPM_STS with a mask and waits for the value in "expected". This modification adds the ability to check if certain TPM_STS bits have been cleared. For example, use the new parameter to check in status that TPM_STS_VALID is set and also that TPM_STS_EXPECT is zeroed. This prevents a racy check. OpenBMC-Staging-Count: 1 Suggested-by: Benoit Houyere <benoit.houyere@st.com> Signed-off-by: Amir Mizinski <amirmizi6@gmail.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Link: https://lore.kernel.org/r/20211104140211.6258-2-amirmizi6@gmail.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-01-14tpm: fix NPE on probe for missing devicePatrick Williams1-2/+2
When using the tpm_tis-spi driver on a system missing the physical TPM, a null pointer exception was observed. [ 0.938677] Unable to handle kernel NULL pointer dereference at virtual address 00000004 [ 0.939020] pgd = 10c753cb [ 0.939237] [00000004] *pgd=00000000 [ 0.939808] Internal error: Oops: 5 [#1] SMP ARM [ 0.940157] CPU: 0 PID: 48 Comm: kworker/u4:1 Not tainted 5.15.10-dd1e40c #1 [ 0.940364] Hardware name: Generic DT based system [ 0.940601] Workqueue: events_unbound async_run_entry_fn [ 0.941048] PC is at tpm_tis_remove+0x28/0xb4 [ 0.941196] LR is at tpm_tis_core_init+0x170/0x6ac This is due to an attempt in 'tpm_tis_remove' to use the drvdata, which was not initialized in 'tpm_tis_core_init' prior to the first error. Move the initialization of drvdata earlier so 'tpm_tis_remove' has access to it. OpenBMC-Staging-Count: 1 Signed-off-by: Patrick Williams <patrick@stwcx.xyz> Fixes: 79ca6f74dae0 ("tpm: fix Atmel TPM crash caused by too frequent queries") Cc: stable@vger.kernel.org Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-01-14tpm_tis: Fix an error handling path in 'tpm_tis_core_init()'Christophe Jaillet1-1/+1
Commit 79ca6f74dae0 ("tpm: fix Atmel TPM crash caused by too frequent queries") has moved some code around without updating the error handling path. This is now pointless to 'goto out_err' when neither 'clk_enable()' nor 'ioremap()' have been called yet. Make a direct return instead to avoid undoing things that have not been done. OpenBMC-Staging-Count: 1 Fixes: 79ca6f74dae0 ("tpm: fix Atmel TPM crash caused by too frequent queries") Signed-off-by: Christophe Jaillet <christophe.jaillet@wanadoo.fr> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-01-14tpm: add request_locality before write TPM_INT_ENABLEChen Jun1-0/+8
Locality is not appropriately requested before writing the int mask. Add the missing boilerplate. OpenBMC-Staging-Count: 1 Fixes: e6aef069b6e9 ("tpm_tis: convert to using locality callbacks") Signed-off-by: Chen Jun <chenjun102@huawei.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-12-29ipmi: fix initialization when workqueue allocation failsThadeu Lima de Souza Cascardo1-6/+9
commit 75d70d76cb7b927cace2cb34265d68ebb3306b13 upstream. If the workqueue allocation fails, the driver is marked as not initialized, and timer and panic_notifier will be left registered. Instead of removing those when workqueue allocation fails, do the workqueue initialization before doing it, and cleanup srcu_struct if it fails. Fixes: 1d49eb91e86e ("ipmi: Move remove_work to dedicated workqueue") Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Cc: Corey Minyard <cminyard@mvista.com> Cc: Ioanna Alifieraki <ioanna-maria.alifieraki@canonical.com> Cc: stable@vger.kernel.org Message-Id: <20211217154410.1228673-2-cascardo@canonical.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-29ipmi: ssif: initialize ssif_info->client earlyMian Yousaf Kaukab1-3/+4
commit 34f35f8f14bc406efc06ee4ff73202c6fd245d15 upstream. During probe ssif_info->client is dereferenced in error path. However, it is set when some of the error checking has already been done. This causes following kernel crash if an error path is taken: [ 30.645593][ T674] ipmi_ssif 0-000e: ipmi_ssif: Not probing, Interface already present [ 30.657616][ T674] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000088 ... [ 30.657723][ T674] pc : __dev_printk+0x28/0xa0 [ 30.657732][ T674] lr : _dev_err+0x7c/0xa0 ... [ 30.657772][ T674] Call trace: [ 30.657775][ T674] __dev_printk+0x28/0xa0 [ 30.657778][ T674] _dev_err+0x7c/0xa0 [ 30.657781][ T674] ssif_probe+0x548/0x900 [ipmi_ssif 62ce4b08badc1458fd896206d9ef69a3c31f3d3e] [ 30.657791][ T674] i2c_device_probe+0x37c/0x3c0 ... Initialize ssif_info->client before any error path can be taken. Clear i2c_client data in the error path to prevent the dangling pointer from leaking. Fixes: c4436c9149c5 ("ipmi_ssif: avoid registering duplicate ssif interface") Cc: stable@vger.kernel.org # 5.4.x Suggested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mian Yousaf Kaukab <ykaukab@suse.de> Message-Id: <20211208093239.4432-1-ykaukab@suse.de> Signed-off-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-29ipmi: bail out if init_srcu_struct failsThadeu Lima de Souza Cascardo1-1/+3
commit 2b5160b12091285c5aca45980f100a9294af7b04 upstream. In case, init_srcu_struct fails (because of memory allocation failure), we might proceed with the driver initialization despite srcu_struct not being entirely initialized. Fixes: 913a89f009d9 ("ipmi: Don't initialize anything in the core until something uses it") Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Cc: Corey Minyard <cminyard@mvista.com> Cc: stable@vger.kernel.org Message-Id: <20211217154410.1228673-1-cascardo@canonical.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-29ipmi: Fix UAF when uninstall ipmi_si and ipmi_msghandler moduleWu Bo1-1/+1
[ Upstream commit ffb76a86f8096a8206be03b14adda6092e18e275 ] Hi, When testing install and uninstall of ipmi_si.ko and ipmi_msghandler.ko, the system crashed. The log as follows: [ 141.087026] BUG: unable to handle kernel paging request at ffffffffc09b3a5a [ 141.087241] PGD 8fe4c0d067 P4D 8fe4c0d067 PUD 8fe4c0f067 PMD 103ad89067 PTE 0 [ 141.087464] Oops: 0010 [#1] SMP NOPTI [ 141.087580] CPU: 67 PID: 668 Comm: kworker/67:1 Kdump: loaded Not tainted 4.18.0.x86_64 #47 [ 141.088009] Workqueue: events 0xffffffffc09b3a40 [ 141.088009] RIP: 0010:0xffffffffc09b3a5a [ 141.088009] Code: Bad RIP value. [ 141.088009] RSP: 0018:ffffb9094e2c3e88 EFLAGS: 00010246 [ 141.088009] RAX: 0000000000000000 RBX: ffff9abfdb1f04a0 RCX: 0000000000000000 [ 141.088009] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 [ 141.088009] RBP: 0000000000000000 R08: ffff9abfffee3cb8 R09: 00000000000002e1 [ 141.088009] R10: ffffb9094cb73d90 R11: 00000000000f4240 R12: ffff9abfffee8700 [ 141.088009] R13: 0000000000000000 R14: ffff9abfdb1f04a0 R15: ffff9abfdb1f04a8 [ 141.088009] FS: 0000000000000000(0000) GS:ffff9abfffec0000(0000) knlGS:0000000000000000 [ 141.088009] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 141.088009] CR2: ffffffffc09b3a30 CR3: 0000008fe4c0a001 CR4: 00000000007606e0 [ 141.088009] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 141.088009] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 141.088009] PKRU: 55555554 [ 141.088009] Call Trace: [ 141.088009] ? process_one_work+0x195/0x390 [ 141.088009] ? worker_thread+0x30/0x390 [ 141.088009] ? process_one_work+0x390/0x390 [ 141.088009] ? kthread+0x10d/0x130 [ 141.088009] ? kthread_flush_work_fn+0x10/0x10 [ 141.088009] ? ret_from_fork+0x35/0x40] BUG: unable to handle kernel paging request at ffffffffc0b28a5a [ 200.223240] PGD 97fe00d067 P4D 97fe00d067 PUD 97fe00f067 PMD a580cbf067 PTE 0 [ 200.223464] Oops: 0010 [#1] SMP NOPTI [ 200.223579] CPU: 63 PID: 664 Comm: kworker/63:1 Kdump: loaded Not tainted 4.18.0.x86_64 #46 [ 200.224008] Workqueue: events 0xffffffffc0b28a40 [ 200.224008] RIP: 0010:0xffffffffc0b28a5a [ 200.224008] Code: Bad RIP value. [ 200.224008] RSP: 0018:ffffbf3c8e2a3e88 EFLAGS: 00010246 [ 200.224008] RAX: 0000000000000000 RBX: ffffa0799ad6bca0 RCX: 0000000000000000 [ 200.224008] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 [ 200.224008] RBP: 0000000000000000 R08: ffff9fe43fde3cb8 R09: 00000000000000d5 [ 200.224008] R10: ffffbf3c8cb53d90 R11: 00000000000f4240 R12: ffff9fe43fde8700 [ 200.224008] R13: 0000000000000000 R14: ffffa0799ad6bca0 R15: ffffa0799ad6bca8 [ 200.224008] FS: 0000000000000000(0000) GS:ffff9fe43fdc0000(0000) knlGS:0000000000000000 [ 200.224008] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 200.224008] CR2: ffffffffc0b28a30 CR3: 00000097fe00a002 CR4: 00000000007606e0 [ 200.224008] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 200.224008] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 200.224008] PKRU: 55555554 [ 200.224008] Call Trace: [ 200.224008] ? process_one_work+0x195/0x390 [ 200.224008] ? worker_thread+0x30/0x390 [ 200.224008] ? process_one_work+0x390/0x390 [ 200.224008] ? kthread+0x10d/0x130 [ 200.224008] ? kthread_flush_work_fn+0x10/0x10 [ 200.224008] ? ret_from_fork+0x35/0x40 [ 200.224008] kernel fault(0x1) notification starting on CPU 63 [ 200.224008] kernel fault(0x1) notification finished on CPU 63 [ 200.224008] CR2: ffffffffc0b28a5a [ 200.224008] ---[ end trace c82a412d93f57412 ]--- The reason is as follows: T1: rmmod ipmi_si. ->ipmi_unregister_smi() -> ipmi_bmc_unregister() -> __ipmi_bmc_unregister() -> kref_put(&bmc->usecount, cleanup_bmc_device); -> schedule_work(&bmc->remove_work); T2: rmmod ipmi_msghandler. ipmi_msghander module uninstalled, and the module space will be freed. T3: bmc->remove_work doing cleanup the bmc resource. -> cleanup_bmc_work() -> platform_device_unregister(&bmc->pdev); -> platform_device_del(pdev); -> device_del(&pdev->dev); -> kobject_uevent(&dev->kobj, KOBJ_REMOVE); -> kobject_uevent_env() -> dev_uevent() -> if (dev->type && dev->type->name) 'dev->type'(bmc_device_type) pointer space has freed when uninstall ipmi_msghander module, 'dev->type->name' cause the system crash. drivers/char/ipmi/ipmi_msghandler.c: 2820 static const struct device_type bmc_device_type = { 2821 .groups = bmc_dev_attr_groups, 2822 }; Steps to reproduce: Add a time delay in cleanup_bmc_work() function, and uninstall ipmi_si and ipmi_msghandler module. 2910 static void cleanup_bmc_work(struct work_struct *work) 2911 { 2912 struct bmc_device *bmc = container_of(work, struct bmc_device, 2913 remove_work); 2914 int id = bmc->pdev.id; /* Unregister overwrites id */ 2915 2916 msleep(3000); <--- 2917 platform_device_unregister(&bmc->pdev); 2918 ida_simple_remove(&ipmi_bmc_ida, id); 2919 } Use 'remove_work_wq' instead of 'system_wq' to solve this issues. Fixes: b2cfd8ab4add ("ipmi: Rework device id and guid handling to catch changing BMCs") Signed-off-by: Wu Bo <wubo40@huawei.com> Message-Id: <1640070034-56671-1-git-send-email-wubo40@huawei.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-12-22Merge tag 'v5.15.10' into dev-5.15Joel Stanley2-4/+15
This is the 5.15.10 stable release Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-12-17parisc/agp: Annotate parisc agp init functions with __initHelge Deller1-3/+3
[ Upstream commit 8d88382b7436551a9ebb78475c546b670790cbf6 ] Signed-off-by: Helge Deller <deller@gmx.de> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-12-08ipmi: msghandler: Make symbol 'remove_work_wq' staticWei Yongjun1-1/+1
commit 5a3ba99b62d8486de0316334e72ac620d4b94fdd upstream. The sparse tool complains as follows: drivers/char/ipmi/ipmi_msghandler.c:194:25: warning: symbol 'remove_work_wq' was not declared. Should it be static? This symbol is not used outside of ipmi_msghandler.c, so marks it static. Fixes: 1d49eb91e86e ("ipmi: Move remove_work to dedicated workqueue") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Message-Id: <20211123083618.2366808-1-weiyongjun1@huawei.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-08ipmi: Move remove_work to dedicated workqueueIoanna Alifieraki1-1/+12
commit 1d49eb91e86e8c1c1614c72e3e958b6b7e2472a9 upstream. Currently when removing an ipmi_user the removal is deferred as a work on the system's workqueue. Although this guarantees the free operation will occur in non atomic context, it can race with the ipmi_msghandler module removal (see [1]) . In case a remove_user work is scheduled for removal and shortly after ipmi_msghandler module is removed we can end up in a situation where the module is removed fist and when the work is executed the system crashes with : BUG: unable to handle page fault for address: ffffffffc05c3450 PF: supervisor instruction fetch in kernel mode PF: error_code(0x0010) - not-present page because the pages of the module are gone. In cleanup_ipmi() there is no easy way to detect if there are any pending works to flush them before removing the module. This patch creates a separate workqueue and schedules the remove_work works on it. When removing the module the workqueue is drained when destroyed to avoid the race. [1] https://bugs.launchpad.net/bugs/1950666 Cc: stable@vger.kernel.org # 5.1 Fixes: 3b9a907223d7 (ipmi: fix sleep-in-atomic in free_user at cleanup SRCU user->release_barrier) Signed-off-by: Ioanna Alifieraki <ioanna-maria.alifieraki@canonical.com> Message-Id: <20211115131645.25116-1-ioanna-maria.alifieraki@canonical.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-26Merge tag 'v5.15.5' into dev-5.15Joel Stanley9-23/+60
This is the 5.15.5 stable release Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-11-18ipmi: kcs_bmc: Fix a memory leak in the error handling path of ↵Christophe JAILLET1-1/+3
'kcs_bmc_serio_add_device()' [ Upstream commit f281d010b87454e72475b668ad66e34961f744e0 ] In the unlikely event where 'devm_kzalloc()' fails and 'kzalloc()' succeeds, 'port' would be leaking. Test each allocation separately to avoid the leak. Fixes: 3a3d2f6a4c64 ("ipmi: kcs_bmc: Add serio adaptor") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Message-Id: <ecbfa15e94e64f4b878ecab1541ea46c74807670.1631048724.git.christophe.jaillet@wanadoo.fr> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18tpm_tis_spi: Add missing SPI IDMark Brown1-0/+1
[ Upstream commit 7eba41fe8c7bb01ff3d4b757bd622375792bc720 ] In commit c46ed2281bbe ("tpm_tis_spi: add missing SPI device ID entries") we added SPI IDs for all the DT aliases to handle the fact that we always use SPI modaliases to load modules even when probed via DT however the mentioned commit missed that the SPI and OF device ID entries did not match and were different and so DT nodes with compatible "tcg,tpm_tis-spi" will not match. Add an extra ID for tpm_tis-spi rather than just fix the existing one since what's currently there is going to be better for anyone actually using SPI IDs to instantiate. Fixes: c46ed2281bbe ("tpm_tis_spi: add missing SPI device ID entries") Fixes: 96c8395e2166 ("spi: Revert modalias changes") Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18tpm: fix Atmel TPM crash caused by too frequent queriesHao Wu2-8/+22
[ Upstream commit 79ca6f74dae067681a779fd573c2eb59649989bc ] The Atmel TPM 1.2 chips crash with error `tpm_try_transmit: send(): error -62` since kernel 4.14. It is observed from the kernel log after running `tpm_sealdata -z`. The error thrown from the command is as follows ``` $ tpm_sealdata -z Tspi_Key_LoadKey failed: 0x00001087 - layer=tddl, code=0087 (135), I/O error ``` The issue was reproduced with the following Atmel TPM chip: ``` $ tpm_version T0 TPM 1.2 Version Info: Chip Version: 1.2.66.1 Spec Level: 2 Errata Revision: 3 TPM Vendor ID: ATML TPM Version: 01010000 Manufacturer Info: 41544d4c ``` The root cause of the issue is due to the TPM calls to msleep() were replaced with usleep_range() [1], which reduces the actual timeout. Via experiments, it is observed that the original msleep(5) actually sleeps for 15ms. Because of a known timeout issue in Atmel TPM 1.2 chip, the shorter timeout than 15ms can cause the error described above. A few further changes in kernel 4.16 [2] and 4.18 [3, 4] further reduced the timeout to less than 1ms. With experiments, the problematic timeout in the latest kernel is the one for `wait_for_tpm_stat`. To fix it, the patch reverts the timeout of `wait_for_tpm_stat` to 15ms for all Atmel TPM 1.2 chips, but leave it untouched for Ateml TPM 2.0 chip, and chips from other vendors. As explained above, the chosen 15ms timeout is the actual timeout before this issue introduced, thus the old value is used here. Particularly, TPM_ATML_TIMEOUT_WAIT_STAT_MIN is set to 14700us, TPM_ATML_TIMEOUT_WAIT_STAT_MIN is set to 15000us according to the existing TPM_TIMEOUT_RANGE_US (300us). The fixed has been tested in the system with the affected Atmel chip with no issues observed after boot up. References: [1] 9f3fc7bcddcb tpm: replace msleep() with usleep_range() in TPM 1.2/2.0 generic drivers [2] cf151a9a44d5 tpm: reduce tpm polling delay in tpm_tis_core [3] 59f5a6b07f64 tpm: reduce poll sleep time in tpm_transmit() [4] 424eaf910c32 tpm: reduce polling time to usecs for even finer granularity Fixes: 9f3fc7bcddcb ("tpm: replace msleep() with usleep_range() in TPM 1.2/2.0 generic drivers") Link: https://patchwork.kernel.org/project/linux-integrity/patch/20200926223150.109645-1-hao.wu@rubrik.com/ Signed-off-by: Hao Wu <hao.wu@rubrik.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18hwrng: mtk - Force runtime pm ops for sleep opsMarkus Schneider-Pargmann1-2/+7
[ Upstream commit b6f5f0c8f72d348b2d07b20d7b680ef13a7ffe98 ] Currently mtk_rng_runtime_suspend/resume is called for both runtime pm and system sleep operations. This is wrong as these should only be runtime ops as the name already suggests. Currently freezing the system will lead to a call to mtk_rng_runtime_suspend even if the device currently isn't active. This leads to a clock warning because it is disabled/unprepared although it isn't enabled/prepared currently. This patch fixes this by only setting the runtime pm ops and forces to call the runtime pm ops from the system sleep ops as well if active but not otherwise. Fixes: 81d2b34508c6 ("hwrng: mtk - add runtime PM support") Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ipmi: Disable some operations during a panicCorey Minyard2-8/+19
[ Upstream commit b36eb5e7b75a756baa64909a176dd4269ee05a8b ] Don't do kfree or other risky things when oops_in_progress is set. It's easy enough to avoid doing them Signed-off-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ipmi:watchdog: Set panic count to proper value on a panicCorey Minyard1-4/+4
commit db05ddf7f321634c5659a0cf7ea56594e22365f7 upstream. You will get two decrements when the messages on a panic are sent, not one, since commit 2033f6858970 ("ipmi: Free receive messages when in an oops") was added, but the watchdog code had a bug where it didn't set the value properly. Reported-by: Anton Lundin <glance@acc.umu.se> Cc: <Stable@vger.kernel.org> # v5.4+ Fixes: 2033f6858970 ("ipmi: Free receive messages when in an oops") Signed-off-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18tpm: Check for integer overflow in tpm2_map_response_body()Dan Carpenter1-0/+3
commit a0bcce2b2a169e10eb265c8f0ebdd5ae4c875670 upstream. The "4 * be32_to_cpu(data->count)" multiplication can potentially overflow which would lead to memory corruption. Add a check for that. Cc: stable@vger.kernel.org Fixes: 745b361e989a ("tpm: infrastructure for TPM spaces") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18char: xillybus: fix msg_ep UAF in xillyusb_probe()Ziyang Xuan1-0/+1
commit 15c9a359094ec6251578b02387436bc64f11a477 upstream. When endpoint_alloc() return failed in xillyusb_setup_base_eps(), 'xdev->msg_ep' will be freed but not set to NULL. That lets program enter fail handling to cleanup_dev() in xillyusb_probe(). Check for 'xdev->msg_ep' is invalid in cleanup_dev() because 'xdev->msg_ep' did not set to NULL when was freed. So the UAF problem for 'xdev->msg_ep' is triggered. ================================================================== BUG: KASAN: use-after-free in fifo_mem_release+0x1f4/0x210 CPU: 0 PID: 166 Comm: kworker/0:2 Not tainted 5.15.0-rc5+ #19 Call Trace: dump_stack_lvl+0xe2/0x152 print_address_description.constprop.0+0x21/0x140 ? fifo_mem_release+0x1f4/0x210 kasan_report.cold+0x7f/0x11b ? xillyusb_probe+0x530/0x700 ? fifo_mem_release+0x1f4/0x210 fifo_mem_release+0x1f4/0x210 ? __sanitizer_cov_trace_pc+0x1d/0x50 endpoint_dealloc+0x35/0x2b0 cleanup_dev+0x90/0x120 xillyusb_probe+0x59a/0x700 ... Freed by task 166: kasan_save_stack+0x1b/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0x109/0x140 kfree+0x117/0x4c0 xillyusb_probe+0x606/0x700 Set 'xdev->msg_ep' to NULL after being freed in xillyusb_setup_base_eps() to fix the UAF problem. Fixes: a53d1202aef1 ("char: xillybus: Add driver for XillyUSB (Xillybus variant for USB)") Cc: stable <stable@vger.kernel.org> Acked-by: Eli Billauer <eli.billauer@gmail.com> Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com> Link: https://lore.kernel.org/r/20211016052047.1611983-1-william.xuanziyang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-05ipmi: ipmb_dev_int: add quick fix for raw I2C type registrationJae Hyun Yoo1-0/+4
This commit adds quick fix for cases of run time registration through sysfs. It should be fixed later by adding parsing code for ipmb_id instead. This is a temporary fix. Do not upstream it. Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@intel.com>
generated by cgit v1.2.3 (git 2.39.0) at 2024-06-11 16:33:48 +0300