media: V4L2: fix VIDIOC_CREATE_BUFS in 64- / 32-bit compatibility mode
authorGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Sat, 26 Apr 2014 15:51:31 +0000 (12:51 -0300)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 7 Jun 2014 20:25:40 +0000 (13:25 -0700)
commit3c3fa08f4c7770ad35bb10755fb9b1c80e34dee4
tree8175b8e01f1592d3a06f426aaa6cc9c2081c8a8e
parent2e008074b2f19ba550393e3a33334fd1dd5da082
media: V4L2: fix VIDIOC_CREATE_BUFS in 64- / 32-bit compatibility mode

commit 97d9d23dda6f37d90aefeec4ed619d52df525382 upstream.

If a struct contains 64-bit fields, it is aligned on 64-bit boundaries
within containing structs in 64-bit compilations. This is the case with
struct v4l2_window, which contains pointers and is embedded into struct
v4l2_format, and that one is embedded into struct v4l2_create_buffers.
Unlike some other structs, used as a part of the kernel ABI as ioctl()
arguments, that are packed, these structs aren't packed. This isn't a
problem per se, but the ioctl-compat code for VIDIOC_CREATE_BUFS contains
a bug, that triggers in such 64-bit builds. That code wrongly assumes,
that in struct v4l2_create_buffers, struct v4l2_format immediately follows
the __u32 memory field, which in fact isn't the case. This bug wasn't
visible until now, because until recently hardly any applications used
this ioctl() and mostly embedded 32-bit only drivers implemented it. This
is changing now with addition of this ioctl() to some USB drivers, e.g.
UVC. This patch fixes the bug by copying parts of struct
v4l2_create_buffers separately.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/media/v4l2-core/v4l2-compat-ioctl32.c