Hi Mauro,
On Sunday 11 December 2011 11:22:29 Mauro Carvalho Chehab wrote:
> On 29-11-2011 23:22, Laurent Pinchart wrote:
> > Hi Haogang,
> >
> > On Tuesday 29 November 2011 22:32:25 Haogang Chen wrote:
> >> There is a potential integer overflow in uvc_ioctl_ctrl_map(). When a
> >> large xmap->me
On 29-11-2011 23:22, Laurent Pinchart wrote:
Hi Haogang,
On Tuesday 29 November 2011 22:32:25 Haogang Chen wrote:
There is a potential integer overflow in uvc_ioctl_ctrl_map(). When a
large xmap->menu_count is passed from the userspace, the subsequent call
to kmalloc() will allocate a buffer sm
Hi Haogang,
On Wednesday 30 November 2011 03:28:32 Haogang Chen wrote:
> The hard limit sounds good to me.
OK.
> But if you want to centralize error handling, please make sure that "goto
> done" only frees map, but not map->menu_info in that case.
map->menu_info will be NULL, so it's safe to kf
The hard limit sounds good to me. But if you want to centralize error
handling, please make sure that "goto done" only frees map, but not
map->menu_info in that case.
- Haogang
On Tue, Nov 29, 2011 at 8:22 PM, Laurent Pinchart
wrote:
> Hi Haogang,
>
> On Tuesday 29 November 2011 22:32:25 Haog
Hi Haogang,
On Tuesday 29 November 2011 22:32:25 Haogang Chen wrote:
> There is a potential integer overflow in uvc_ioctl_ctrl_map(). When a
> large xmap->menu_count is passed from the userspace, the subsequent call
> to kmalloc() will allocate a buffer smaller than expected.
> map->menu_count and
There is a potential integer overflow in uvc_ioctl_ctrl_map(). When a
large xmap->menu_count is passed from the userspace, the subsequent call
to kmalloc() will allocate a buffer smaller than expected.
map->menu_count and map->menu_info would later be used in a loop (e.g.
in uvc_query_v4l2_ctrl), w
