Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754676Ab3HFDzL (ORCPT ); Mon, 5 Aug 2013 23:55:11 -0400 Received: from mail-we0-f179.google.com ([74.125.82.179]:53025 "EHLO mail-we0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754442Ab3HFDzJ (ORCPT ); Mon, 5 Aug 2013 23:55:09 -0400 MIME-Version: 1.0 In-Reply-To: <1375740121-23350-1-git-send-email-roland@kernel.org> References: <1375740121-23350-1-git-send-email-roland@kernel.org> From: Peter Chang Date: Mon, 5 Aug 2013 20:54:48 -0700 Message-ID: Subject: Re: [PATCH] [SCSI] sg: Fix user memory corruption when SG_IO is interrupted by a signal To: Roland Dreier Cc: Jens Axboe , Doug Gilbert , James Bottomley , Costa Sapuntzakis , =?ISO-8859-1?Q?J=F6rn_Engel?= , linux-kernel@vger.kernel.org, "linux-scsi@vger.kernel.org" Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1897 Lines: 42 2013/8/5 Roland Dreier : > From: Roland Dreier > > There is a nasty bug in the SCSI SG_IO ioctl that in some circumstances > leads to one process writing data into the address space of some other > random unrelated process if the ioctl is interrupted by a signal. > What happens is the following: > > - A process issues an SG_IO ioctl with direction DXFER_FROM_DEV (ie the > underlying SCSI command will transfer data from the SCSI device to > the buffer provided in the ioctl) > > - Before the command finishes, a signal is sent to the process waiting > in the ioctl. This will end up waking up the sg_ioctl() code: > > result = wait_event_interruptible(sfp->read_wait, > (srp_done(sfp, srp) || sdp->detached)); > > but neither srp_done() nor sdp->detached is true, so we end up just > setting srp->orphan and returning to userspace: > > srp->orphan = 1; > write_unlock_irq(&sfp->rq_list_lock); > return result; /* -ERESTARTSYS because signal hit process */ > > At this point the original process is done with the ioctl and > blithely goes ahead handling the signal, reissuing the ioctl, etc. i think that an additional issue here is that part of reissuing the ioctl is re-queueing the command. since the re-queue is at the front of the block queue there are issues if the command is non-idempotent. we have a local fix that gets rid of most of the orphan stuff and re-waiting if a non-fatal signal was waiting. simpler than unmapping but maybe we're missing some other interesting case? \p -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/