linux-kernel - [PATCH v2 1/2] scsi: sr: Fix sr_probe() missing mutex

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <06e9de38-eeed-1cab-5e08-e889288935b3@0882a8b5-c6c3-11e9-b005-00805fc181fe>
Date:   Sat, 30 May 2020 18:58:25 +0100
From:   Simon Arlott <simon@...iron.net>
To:     "Martin K . Petersen" <martin.petersen@...cle.com>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        Jens Axboe <axboe@...nel.dk>,
        Bart Van Assche <bvanassche@....org>
Cc:     linux-scsi@...r.kernel.org, Merlijn Wajer <merlijn@...hive.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: [PATCH v2 1/2] scsi: sr: Fix sr_probe() missing mutex_destroy

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@...iron.net>
Fixes: 51a858817dcd ("scsi: sr: get rid of sr global mutex")
Cc: stable@...r.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 --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:
-- 
2.17.1

-- 
Simon Arlott