From: Hans Verkuil <hansverk@xxxxxxxxx> These two patches fix syzkaller race conditions. The basic problem is the same for both: in some specific cases an ioctl can release the core serialization mutex, thus allowing another thread to access the same vb2 queue through a dup()ped filehandle. This can happen in VIDIOC_DQBUF and read()/write() (this calls dqbuf internally, so it is really the same problem): if no new buffer is available the DQBUF ioctl will block and wait for a new buffer to arrive. Before it waits it releases the serialization lock, and afterwards it reacquires it. This is intentional, since you do not want to block other ioctls while waiting for a buffer. But this means that you need to flag that you are waiting for a buffer and check the flag in the appropriate places. The same can happen in the stop_streaming operation: the driver may have to release the serialization lock while waiting for streaming to stop (vivid does this). The same approach is used to prevent new read()s/write()s or QBUF ioctls while it is in stop_streaming. These flags are always checked/set with the serialization mutex locked. Regards, Hans Hans Verkuil (2): vb2: add waiting_in_dqbuf flag vb2: don't allow queueing buffers when canceling queue .../media/common/videobuf2/videobuf2-core.c | 32 ++++++++++++++++++- include/media/videobuf2-core.h | 2 ++ 2 files changed, 33 insertions(+), 1 deletion(-) -- 2.19.1