kernel.git/drivers/spi/spi.c, branch linux-4.4.y

spi: Fix use-after-free with devm_spi_alloc_*

2021-06-03T06:22:06Z

commit 794aaf01444d4e765e2b067cba01cc69c1c68ed9 upstream. We can't rely on the contents of the devres list during spi_unregister_controller(), as the list is already torn down at the time we perform devres_find() for devm_spi_release_controller. This causes devices registered with devm_spi_alloc_{master,slave}() to be mistakenly identified as legacy, non-devm managed devices and have their reference counters decremented below 0. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 660 at lib/refcount.c:28 refcount_warn_saturate+0x108/0x174 [] (refcount_warn_saturate) from [] (kobject_put+0x90/0x98) [] (kobject_put) from [] (put_device+0x20/0x24) r4:b6700140 [] (put_device) from [] (devm_spi_release_controller+0x3c/0x40) [] (devm_spi_release_controller) from [] (release_nodes+0x84/0xc4) r5:b6700180 r4:b6700100 [] (release_nodes) from [] (devres_release_all+0x5c/0x60) r8:b1638c54 r7:b117ad94 r6:b1638c10 r5:b117ad94 r4:b163dc10 [] (devres_release_all) from [] (__device_release_driver+0x144/0x1ec) r5:b117ad94 r4:b163dc10 [] (__device_release_driver) from [] (device_driver_detach+0x84/0xa0) r9:00000000 r8:00000000 r7:b117ad94 r6:b163dc54 r5:b1638c10 r4:b163dc10 [] (device_driver_detach) from [] (unbind_store+0xe4/0xf8) Instead, determine the devm allocation state as a flag on the controller which is guaranteed to be stable during cleanup. Fixes: 5e844cc37a5c ("spi: Introduce device-managed SPI controller allocation") Signed-off-by: William A. Kennington III Link: https://lore.kernel.org/r/20210407095527.2771582-1-wak@google.com Signed-off-by: Mark Brown [lukas: backport to v4.4.270] Signed-off-by: Lukas Wunner Signed-off-by: Greg Kroah-Hartman

spi: Prevent adding devices below an unregistering controller

2020-12-29T12:42:31Z

commit ddf75be47ca748f8b12d28ac64d624354fddf189 upstream CONFIG_OF_DYNAMIC and CONFIG_ACPI allow adding SPI devices at runtime using a DeviceTree overlay or DSDT patch. CONFIG_SPI_SLAVE allows the same via sysfs. But there are no precautions to prevent adding a device below a controller that's being removed. Such a device is unusable and may not even be able to unbind cleanly as it becomes inaccessible once the controller has been torn down. E.g. it is then impossible to quiesce the device's interrupt. of_spi_notify() and acpi_spi_notify() do hold a ref on the controller, but otherwise run lockless against spi_unregister_controller(). Fix by holding the spi_add_lock in spi_unregister_controller() and bailing out of spi_add_device() if the controller has been unregistered concurrently. Fixes: ce79d54ae447 ("spi/of: Add OF notifier handler") Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v3.19+ Cc: Geert Uytterhoeven Cc: Octavian Purdila Cc: Pantelis Antoniou Link: https://lore.kernel.org/r/a8c3205088a969dc8410eec1eba9aface60f36af.1596451035.git.lukas@wunner.de Signed-off-by: Mark Brown [sudip: adjust context] Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman

spi: Introduce device-managed SPI controller allocation

2020-12-11T12:36:45Z

[ Upstream commit 5e844cc37a5cbaa460e68f9a989d321d63088a89 ] SPI driver probing currently comprises two steps, whereas removal comprises only one step: spi_alloc_master() spi_register_master() spi_unregister_master() That's because spi_unregister_master() calls device_unregister() instead of device_del(), thereby releasing the reference on the spi_master which was obtained by spi_alloc_master(). An SPI driver's private data is contained in the same memory allocation as the spi_master struct. Thus, once spi_unregister_master() has been called, the private data is inaccessible. But some drivers need to access it after spi_unregister_master() to perform further teardown steps. Introduce devm_spi_alloc_master(), which releases a reference on the spi_master struct only after the driver has unbound, thereby keeping the memory allocation accessible. Change spi_unregister_master() to not release a reference if the spi_master was allocated by the new devm function. The present commit is small enough to be backportable to stable. It allows fixing drivers which use the private data in their ->remove() hook after it's been freed. It also allows fixing drivers which neglect to release a reference on the spi_master in the probe error path. Long-term, most SPI drivers shall be moved over to the devm function introduced herein. The few that can't shall be changed in a treewide commit to explicitly release the last reference on the master. That commit shall amend spi_unregister_master() to no longer release a reference, thereby completing the migration. As a result, the behaviour will be less surprising and more consistent with subsystems such as IIO, which also includes the private data in the allocation of the generic iio_dev struct, but calls device_del() in iio_device_unregister(). Signed-off-by: Lukas Wunner Link: https://lore.kernel.org/r/272bae2ef08abd21388c98e23729886663d19192.1605121038.git.lukas@wunner.de Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

spi: unbinding slave before calling spi_destroy_queue

2020-10-17T09:03:31Z

We make a mistake while backport 'commit 84855678add8 ("spi: Fix controller unregister order")'. What we should do is call __unreigster for each device before spi_destroy_queue. This problem exist in linux-4.4.y/linux-4.9.y. Signed-off-by: yangerkun

spi: Fix controller unregister order

2020-06-20T08:23:17Z

[ Upstream commit 84855678add8aba927faf76bc2f130a40f94b6f7 ] When an SPI controller unregisters, it unbinds all its slave devices. For this, their drivers may need to access the SPI bus, e.g. to quiesce interrupts. However since commit ffbbdd21329f ("spi: create a message queueing infrastructure"), spi_destroy_queue() is executed before unbinding the slaves. It sets ctlr->running = false, thereby preventing SPI bus access and causing unbinding of slave devices to fail. Fix by unbinding slaves before calling spi_destroy_queue(). Fixes: ffbbdd21329f ("spi: create a message queueing infrastructure") Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v3.4+ Cc: Linus Walleij Link: https://lore.kernel.org/r/8aaf9d44c153fe233b17bc2dec4eb679898d7e7b.1589557526.git.lukas@wunner.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

spi: No need to assign dummy value in spi_unregister_controller()

2020-06-20T08:23:17Z

[ Upstream commit ebc37af5e0a134355ea2b62ed4141458bdbd5389 ] The device_for_each_child() doesn't require the returned value to be checked. Thus, drop the dummy variable completely and have no warning anymore: drivers/spi/spi.c: In function ‘spi_unregister_controller’: drivers/spi/spi.c:2480:6: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable] int dummy; ^~~~~ Signed-off-by: Andy Shevchenko Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

spi: Fix zero length xfer bug

2019-06-11T10:24:06Z

[ Upstream commit 5442dcaa0d90fc376bdfc179a018931a8f43dea4 ] This fixes a bug for messages containing both zero length and unidirectional xfers. The function spi_map_msg will allocate dummy tx and/or rx buffers for use with unidirectional transfers when the hardware can only do a bidirectional transfer. That dummy buffer will be used in place of a NULL buffer even when the xfer length is 0. Then in the function __spi_map_msg, if he hardware can dma, the zero length xfer will have spi_map_buf called on the dummy buffer. Eventually, __sg_alloc_table is called and returns -EINVAL because nents == 0. This fix prevents the error by not using the dummy buffer when the xfer length is zero. Signed-off-by: Chris Lesiak Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

spi: Fix scatterlist elements size in spi_map_buf

2018-07-03T09:21:35Z

commit ce99319a182fe766be67f96338386f3ec73e321c upstream. When SPI transfers can be offloaded using DMA, the SPI core need to build a scatterlist to make sure that the buffer to be transferred is dma-able. This patch fixes the scatterlist entry size computation in the case where the maximum acceptable scatterlist entry supported by the DMA controller is less than PAGE_SIZE, when the buffer is vmalloced. For each entry, the actual size is given by the minimum between the desc_len (which is the max buffer size supported by the DMA controller) and the remaining buffer length until we cross a page boundary. Fixes: 65598c13fd66 ("spi: Fix per-page mapping of unaligned vmalloc-ed buffer") Signed-off-by: Maxime Chevallier Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman

Merge remote-tracking branch 'spi/fix/core' into spi-linus

2015-12-16T13:28:31Z

spi: fix parent-device reference leak

2015-12-16T12:28:25Z

Fix parent-device reference leak due to SPI-core taking an unnecessary reference to the parent when allocating the master structure, a reference that was never released. Note that driver core takes its own reference to the parent when the master device is registered. Fixes: 49dce689ad4e ("spi doesn't need class_device") Signed-off-by: Johan Hovold Signed-off-by: Mark Brown Cc: stable@vger.kernel.org