diff mbox series

[v2,1/2] scsi: sr: Fix sr_probe() missing mutex_destroy

Message ID 06e9de38-eeed-1cab-5e08-e889288935b3@0882a8b5-c6c3-11e9-b005-00805fc181fe
State New
Headers show
Series [v2,1/2] scsi: sr: Fix sr_probe() missing mutex_destroy | expand

Commit Message

Simon Arlott May 30, 2020, 5:58 p.m. UTC 
If the device minor cannot be allocated or the cdrom fails to be
registered then the mutex should be destroyed.

Signed-off-by: Simon Arlott <simon@octiron.net>
Fixes: 51a858817dcd ("scsi: sr: get rid of sr global mutex")
Cc: stable@vger.kernel.org
---
On 30/05/2020 17:41, James Bottomley wrote:
> On Sat, 2020-05-30 at 09:24 -0700, Bart Van Assche wrote:
>> Please add Fixes: and Cc: stable tags.

I've added a Fixes: tag and Cc:'d stable.

> This isn't really a bug, is it?  mutex_destroy is a nop unless lock
> debugging is enabled in which case it checks the lock is unlocked and
> marks it as unusable to detect a use after destroy.  Since the
> structure containing the mutex is kfree'd in the next statement, kasan
> would also detect any use after free.  That's not to say we shouldn't
> do this to be fully correct ... just that it has no potential ever to
> have user visible impact so there doesn't seem to be much point
> cluttering up the stable process with it.

If the current lock debugging implementation in stable will be ok with
it then I'd agree there's no reason to put it in stable kernels, except
that the commit this fixes was added to stable with this bug and one in
sr_block_release (72655c0ebd1d).

 drivers/scsi/sr.c | 1 +
 1 file changed, 1 insertion(+)
diff mbox series

Patch

diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index d2fe3fa470f9..8d062d4f3ce0 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -817,6 +817,7 @@  static int sr_probe(struct device *dev)
 
 fail_put:
 	put_disk(disk);
+	mutex_destroy(&cd->lock);
 fail_free:
 	kfree(cd);
 fail: