media: vb2: add waiting_in_dqbuf flag
authorHans Verkuil <hverkuil@xs4all.nl>
Mon, 19 Nov 2018 11:09:00 +0000 (06:09 -0500)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 31 May 2019 13:46:04 +0000 (06:46 -0700)
commit0595e0d173f0946e8758278b736a6812c61c751a
treea90237ba34975c409c89fc11b51cc288e34739a7
parentaec118ecf579a6c70e505b39fc6eb6a2d878c89e
media: vb2: add waiting_in_dqbuf flag

commit d65842f7126aa1a87fb44b7c9980c12630ed4f33 upstream.

Calling VIDIOC_DQBUF can release the core serialization lock pointed to
by vb2_queue->lock if it has to wait for a new buffer to arrive.

However, if userspace dup()ped the video device filehandle, then it is
possible to read or call DQBUF from two filehandles at the same time.

It is also possible to call REQBUFS from one filehandle while the other
is waiting for a buffer. This will remove all the buffers and reallocate
new ones. Removing all the buffers isn't the problem here (that's already
handled correctly by DQBUF), but the reallocating part is: DQBUF isn't
aware that the buffers have changed.

This is fixed by setting a flag whenever the lock is released while waiting
for a buffer to arrive. And checking the flag where needed so we can return
-EBUSY.

Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Reported-by: Syzbot <syzbot+4180ff9ca6810b06c1e9@syzkaller.appspotmail.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/media/common/videobuf2/videobuf2-core.c
include/media/videobuf2-core.h