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] [day] [month] [year] [list]
Date:	Fri, 4 Mar 2016 13:37:29 +0100
From:	Jan Kara <jack@...e.cz>
To:	Ricardo Ribalda Delgado <ricardo.ribalda@...il.com>
Cc:	albert@...tec.dk, Jan Kara <jack@...e.cz>,
	Pawel Osciak <pawel@...iak.com>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Hans Verkuil <hans.verkuil@...co.com>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] [media] vb2-memops: Fix over allocation of frame
 vectors

On Thu 03-03-16 20:12:48, Ricardo Ribalda Delgado wrote:
> On page unaligned frames, create_framevec forces get_vaddr_frames to
> allocate an extra page at the end of the buffer. Under some
> circumstances, this leads to -EINVAL on VIDIOC_QBUF.
> 
> E.g:
> We have vm_a that vm_area that goes from 0x1000 to 0x3000. And a
> frame that goes from 0x1800 to 0x2800, i.e. 2 pages.
> 
> frame_vector_create will be called with the following params:
> 
> get_vaddr_frames(0x1800 , 2, write, 1, vec);
> 
> get_vaddr will allocate the first page after checking that the memory
> 0x1800-0x27ff is valid, but it will not allocate the second page because
> the range 0x2800-0x37ff is out of the vm_a range. This results in
> create_framevec returning -EFAULT
> 
> Error Trace:
> [ 9083.793015] video0: VIDIOC_QBUF: 00:00:00.00000000 index=1,
> type=vid-cap, flags=0x00002002, field=any, sequence=0,
> memory=userptr, bytesused=0, offset/userptr=0x7ff2b023ca80, length=5765760
> [ 9083.793028] timecode=00:00:00 type=0, flags=0x00000000,
> frames=0, userbits=0x00000000
> [ 9083.793117] video0: VIDIOC_QBUF: error -22: 00:00:00.00000000
> index=2, type=vid-cap, flags=0x00000000, field=any, sequence=0,
> memory=userptr, bytesused=0, offset/userptr=0x7ff2b07bc500, length=5765760
> 
> Fixes: 21fb0cb7ec65 ("[media] vb2: Provide helpers for mapping virtual addresses")
> Reported-by: Albert Antony <albert@...tec.dk>
> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@...il.com>

The patch looks good. Thanks for fixing this! You can add:

Reviewed-by: Jan Kara <jack@...e.cz>

								Honza
> ---
> 
> Maybe we should cc stable.
> 
> This error has not pop-out yet because userptr is usually called with memory
> on the heap and malloc usually overallocate. This error has been a pain to trace :).
> 
> Regards!
> 
> 
> 
>  drivers/media/v4l2-core/videobuf2-memops.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-memops.c b/drivers/media/v4l2-core/videobuf2-memops.c
> index dbec5923fcf0..e4e4976c6849 100644
> --- a/drivers/media/v4l2-core/videobuf2-memops.c
> +++ b/drivers/media/v4l2-core/videobuf2-memops.c
> @@ -49,7 +49,7 @@ struct frame_vector *vb2_create_framevec(unsigned long start,
>  	vec = frame_vector_create(nr);
>  	if (!vec)
>  		return ERR_PTR(-ENOMEM);
> -	ret = get_vaddr_frames(start, nr, write, 1, vec);
> +	ret = get_vaddr_frames(start & PAGE_MASK, nr, write, 1, vec);
>  	if (ret < 0)
>  		goto out_destroy;
>  	/* We accept only complete set of PFNs */
> -- 
> 2.7.0
> 
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR

Powered by blists - more mailing lists