3.16.42-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Al Viro <viro@xxxxxxxxxxxxxxxxxx> commit 137d01df511b3afe1f05499aea05f3bafc0fb221 upstream. What happens is that a write to /dev/sg is given a request with non-zero ->iovec_count combined with zero ->dxfer_len. Or with ->dxferp pointing to an array full of empty iovecs. Having write permission to /dev/sg shouldn't be equivalent to the ability to trigger BUG_ON() while holding spinlocks... Found by Dmitry Vyukov and syzkaller. [ The BUG_ON() got changed to a WARN_ON_ONCE(), but this fixes the underlying issue. - Linus ] Signed-off-by: Al Viro <viro@xxxxxxxxxxxxxxxxxx> Reported-by: Dmitry Vyukov <dvyukov@xxxxxxxxxx> Reviewed-by: Christoph Hellwig <hch@xxxxxx> Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> [bwh: Backported to 3.16: we're not using iov_iter, but can check the byte length after truncation] Signed-off-by: Ben Hutchings <ben@xxxxxxxxxxxxxxx> --- drivers/scsi/sg.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -1716,6 +1716,10 @@ static int sg_start_req(Sg_request *srp, iov_count = iov_shorten(iov, iov_count, hp->dxfer_len); len = hp->dxfer_len; } + if (len == 0) { + kfree(iov); + return -EINVAL; + } res = blk_rq_map_user_iov(q, rq, md, (struct sg_iovec *)iov, iov_count,