]> www.infradead.org Git - users/jedix/linux-maple.git/commit
sg: fix dxferp in from_to case
authorDouglas Gilbert <dgilbert@interlog.com>
Thu, 3 Mar 2016 05:31:29 +0000 (00:31 -0500)
committerChuck Anderson <chuck.anderson@oracle.com>
Thu, 26 May 2016 22:46:23 +0000 (15:46 -0700)
commitedd39033099c9a6279a9b7f77d37a49d8910428e
treec019022ad4ceabd6987da85952cbbc18e98e8915
parent7579e30c2939567cdd78d6b159f58b8690b298cb
sg: fix dxferp in from_to case

Orabug: 23331104

[ Upstream commit 5ecee0a3ee8d74b6950cb41e8989b0c2174568d4 ]

One of the strange things that the original sg driver did was let the
user provide both a data-out buffer (it followed the sg_header+cdb)
_and_ specify a reply length greater than zero. What happened was that
the user data-out buffer was copied into some kernel buffers and then
the mid level was told a read type operation would take place with the
data from the device overwriting the same kernel buffers. The user would
then read those kernel buffers back into the user space.

From what I can tell, the above action was broken by commit fad7f01e61bf
("sg: set dxferp to NULL for READ with the older SG interface") in 2008
and syzkaller found that out recently.

Make sure that a user space pointer is passed through when data follows
the sg_header structure and command.  Fix the abnormal case when a
non-zero reply_len is also given.

Fixes: fad7f01e61bf737fe8a3740d803f000db57ecac6
Cc: <stable@vger.kernel.org> #v2.6.28+
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Reviewed-by: Ewan Milne <emilne@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 685a50b681ddd07ff2b7714797b5793adcc691e7)

Signed-off-by: Dan Duval <dan.duval@oracle.com>
drivers/scsi/sg.c