spi: Fix use-after-free with devm_spi_alloc_*
Subsystems (2)
PATCH 1/1 spi: Fix use-after-free with devm_spi_alloc_*
Dear Greg, Dear Sasha,
please consider applying the patch below to v4.9-stable.
It is a backport of upstream commit 794aaf01444d, which has already been applied to all stable kernels going back to v4.14.
Thanks!
Lukas
-- >8 --
From: "William A. Kennington III" <[email protected]>
Date: Wed, 7 Apr 2021 02:55:27 -0700
Subject: [PATCH] spi: Fix use-after-free with devm_spi_alloc_*
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 [<b0396f04>] (refcount_warn_saturate) from [<b03c56a4>] (kobject_put+0x90/0x98) [<b03c5614>] (kobject_put) from [<b0447b4c>] (put_device+0x20/0x24) r4:b6700140 [<b0447b2c>] (put_device) from [<b07515e8>] (devm_spi_release_controller+0x3c/0x40) [<b07515ac>] (devm_spi_release_controller) from [<b045343c>] (release_nodes+0x84/0xc4) r5:b6700180 r4:b6700100 [<b04533b8>] (release_nodes) from [<b0454160>] (devres_release_all+0x5c/0x60) r8:b1638c54 r7:b117ad94 r6:b1638c10 r5:b117ad94 r4:b163dc10 [<b0454104>] (devres_release_all) from [<b044e41c>] (__device_release_driver+0x144/0x1ec) r5:b117ad94 r4:b163dc10 [<b044e2d8>] (__device_release_driver) from [<b044f70c>] (device_driver_detach+0x84/0xa0) r9:00000000 r8:00000000 r7:b117ad94 r6:b163dc54 r5:b1638c10 r4:b163dc10 [<b044f688>] (device_driver_detach) from [<b044d274>] (unbind_store+0xe4/0xf8)
Instead, determine the devm allocation state as a flag on the controller which is guaranteed to be stable during cleanup.
--- drivers/spi/spi.c | 9 ++------- include/linux/spi/spi.h | 3 +++ 2 files changed, 5 insertions(+), 7 deletions(-)
drivers/spi/spi.c +2 -7
@@ -1869,6 +1869,7 @@ struct spi_master *devm_spi_alloc_master(struct device *dev, unsigned int size) master =spi_alloc_master (dev, size);if (master) { + master->devm_allocated = true; *ptr = master;devres_add (dev, ptr); }else {
@@ -2059,11 +2060,6 @@ int devm_spi_register_master(struct device *dev, struct spi_master *master) }EXPORT_SYMBOL_GPL (devm_spi_register_master); -static int devm_spi_match_master (struct device *dev,void *res,void *master) -{ -return *(struct spi_master **)res == master; -} -static int __unregister (struct device *dev,void *null) {spi_unregister_device (to_spi_device (dev));
@@ -2102,8 +2098,7 @@ void spi_unregister_master(struct spi_master *master)/* Release the last reference on the master if its driver * has not yet been converted to devm_spi_alloc_master(). */ -if (!devres_find (master->dev.parent, devm_spi_release_master, - devm_spi_match_master, master)) +if (!master->devm_allocated)put_device (&master->dev);if (IS_ENABLED (CONFIG_SPI_DYNAMIC ))
include/linux/spi/spi.h +3 -0
@@ -443,6 +443,9 @@ struct spi_master {#define SPI_MASTER_MUST_RX BIT(3)/* requires rx */ #define SPI_MASTER_MUST_TX BIT(4)/* requires tx */ +/* flag indicating this is a non-devres managed controller */ +bool devm_allocated; +/* * on some hardware transfer / message size may be constrained * the limit may depend on device transfer settings
Signature · 1 line
2.31.1
Greg Kroah-Hartman
maintainerQuoted 3 lines · Lukas Wunner
Dear Greg, Dear Sasha,
please consider applying the patch below to v4.9-stable.
Please always cc: [email protected] for stuff you want queued up so that we do not miss them...
thanks,
greg k-h
Quoted 7 lines · Greg Kroah-Hartman
Quoted 3 lines · Lukas Wunner
Dear Greg, Dear Sasha,
please consider applying the patch below to v4.9-stable.
Please always cc: [email protected] for stuff you want queued up so that we do not miss them...
Sorry about that. I've just amended the Cc: header as requested and bounced the two messages to stable@, they're visible on lore.kernel.org already.
Thanks,
Lukas