linux-kernel - Re: [PATCH] [SCSI] sg: Fix user memory corruption when SG

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 5 Aug 2013 20:54:48 -0700
From:	Peter Chang <dpf@...gle.com>
To:	Roland Dreier <roland@...nel.org>
Cc:	Jens Axboe <axboe@...nel.dk>, Doug Gilbert <dgilbert@...erlog.com>,
	James Bottomley <JBottomley@...allels.com>,
	Costa Sapuntzakis <costa@...estorage.com>,
	Jörn Engel <joern@...estorage.com>,
	linux-kernel@...r.kernel.org,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>
Subject: Re: [PATCH] [SCSI] sg: Fix user memory corruption when SG_IO is
 interrupted by a signal

2013/8/5 Roland Dreier <roland@...nel.org>:
> From: Roland Dreier <roland@...estorage.com>
>
> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/