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.

Quoted 1 line

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

Signed-off-by Douglas Gilbert <[email protected]>

Reviewed-by Ewan Milne <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/scsi/sg.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/scsi/sg.c +2 -1

@@ -633,7 +633,8 @@ sg_write(struct file *filp, const char _
 	else
 		hp->dxfer_direction = (mxsize > 0) ? SG_DXFER_FROM_DEV : SG_DXFER_NONE;
 	hp->dxfer_len = mxsize;
-	if (hp->dxfer_direction == SG_DXFER_TO_DEV)
+	if ((hp->dxfer_direction == SG_DXFER_TO_DEV) ||
+	    (hp->dxfer_direction == SG_DXFER_TO_FROM_DEV))
 		hp->dxferp = (char __user *)buf + cmd_size;
 	else
 		hp->dxferp = NULL;

Patches currently in stable-queue which might be from [email protected] are

queue-3.14/sg-fix-dxferp-in-from_to-case.patch