linux-kernel - Re: [PATCH] SCSI IOCTL: Check for device deletion [was Re: __elv_add

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.02.1105251416340.3472@ubuntu-natty>
Date:	Wed, 25 May 2011 14:44:45 -0400 (EDT)
From:	Parag Warudkar <parag.lkml@...il.com>
To:	Jens Axboe <jaxboe@...ionio.com>
cc:	Parag Warudkar <parag.lkml@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"James.Bottomley@...senpartnership.com" 
	<James.Bottomley@...senpartnership.com>, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org,
	Linux SCSI List <linux-scsi@...r.kernel.org>
Subject: Re: [PATCH] SCSI IOCTL: Check for device deletion [was Re:
 __elv_add_request  OOPS]



On Wed, 25 May 2011, Jens Axboe wrote:

> While this will fix your particular oops, I don't think it's quite
> right. It's fixing one particular piece of fall out from attempting to
> talk to a removed device, it's not necessarily fixing the full class of
> them. The other checks in scsi_set_medium_removal() aren't related to a
> changing state of the device, they are capability checks.

Below patch pushes the check down to ioctl functions and hopefully should 
cover more ioctl-on-gone-device cases by returning -ENXIO if an attempt 
was made to submit request to a non-running device.

With this patch in place - instead of oopsing I now get a proper I/O error 
on resume.

AFAICT from my limited SCSI layer knowledge - these seem to be the right 
places to check. Would be interested in knowing if there are better/more 
complete ways to handle this but if they are going to take time IMHO it 
certainly doesn't hurt to keep the below patch in.

Signed-off-by: Parag Warudkar <parag.lkml@...il.com>

diff --git a/drivers/scsi/scsi_ioctl.c b/drivers/scsi/scsi_ioctl.c
index d9564fb..c32cade 100644
--- a/drivers/scsi/scsi_ioctl.c
+++ b/drivers/scsi/scsi_ioctl.c
@@ -91,6 +91,10 @@ static int ioctl_internal_command(struct scsi_device *sdev, char *cmd,
 	int result;
 	struct scsi_sense_hdr sshdr;
 
+	if (!sdev || sdev->sdev_state == SDEV_DEL 
+		|| sdev->sdev_state > SDEV_QUIESCE)
+		return -ENXIO;
+
 	SCSI_LOG_IOCTL(1, printk("Trying ioctl with scsi command %d\n", *cmd));
 
 	result = scsi_execute_req(sdev, cmd, DMA_NONE, NULL, 0,
@@ -195,8 +199,9 @@ int scsi_ioctl(struct scsi_device *sdev, int cmd, void __user *arg)
 {
 	char scsi_cmd[MAX_COMMAND_SIZE];
 
-	/* No idea how this happens.... */
-	if (!sdev)
+	/* No idea how !sdev happens.... */
+	if (!sdev || sdev->sdev_state == SDEV_DEL 
+		|| sdev->sdev_state > SDEV_QUIESCE)
 		return -ENXIO;
 
 	/*
@@ -288,6 +293,10 @@ int scsi_nonblockable_ioctl(struct scsi_device *sdev, int cmd,
 {
 	int val, result;
 
+	if (!sdev || sdev->sdev_state == SDEV_DEL 
+		|| sdev->sdev_state > SDEV_QUIESCE) 
+		return -ENXIO;
+
 	/* The first set of iocts may be executed even if we're doing
 	 * error processing, as long as the device was opened
 	 * non-blocking */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/