--- /dev/null
+From 0e3e0c9369c822b7f1dd11504eeb98cfd4aabf24 Mon Sep 17 00:00:00 2001
+From: Bernhard Wimmer <be.wimm@gmail.com>
+Date: Wed, 21 Apr 2021 23:33:20 +0200
+Subject: media: ccs: Fix the op_pll_multiplier address
+
+From: Bernhard Wimmer <be.wimm@gmail.com>
+
+commit 0e3e0c9369c822b7f1dd11504eeb98cfd4aabf24 upstream.
+
+According to the CCS spec the op_pll_multiplier address is 0x030e,
+not 0x031e.
+
+Signed-off-by: Bernhard Wimmer <be.wimm@gmail.com>
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Cc: stable@vger.kernel.org
+Fixes: 6493c4b777c2 ("media: smiapp: Import CCS definitions")
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/i2c/ccs/ccs-limits.c | 4 ++++
+ drivers/media/i2c/ccs/ccs-limits.h | 4 ++++
+ drivers/media/i2c/ccs/ccs-regs.h | 6 +++++-
+ 3 files changed, 13 insertions(+), 1 deletion(-)
+
+--- a/drivers/media/i2c/ccs/ccs-limits.c
++++ b/drivers/media/i2c/ccs/ccs-limits.c
+@@ -1,5 +1,9 @@
+ // SPDX-License-Identifier: GPL-2.0-only OR BSD-3-Clause
+ /* Copyright (C) 2019--2020 Intel Corporation */
++/*
++ * Generated by Documentation/driver-api/media/drivers/ccs/mk-ccs-regs;
++ * do not modify.
++ */
+
+ #include "ccs-limits.h"
+ #include "ccs-regs.h"
+--- a/drivers/media/i2c/ccs/ccs-limits.h
++++ b/drivers/media/i2c/ccs/ccs-limits.h
+@@ -1,5 +1,9 @@
+ /* SPDX-License-Identifier: GPL-2.0-only OR BSD-3-Clause */
+ /* Copyright (C) 2019--2020 Intel Corporation */
++/*
++ * Generated by Documentation/driver-api/media/drivers/ccs/mk-ccs-regs;
++ * do not modify.
++ */
+
+ #ifndef __CCS_LIMITS_H__
+ #define __CCS_LIMITS_H__
+--- a/drivers/media/i2c/ccs/ccs-regs.h
++++ b/drivers/media/i2c/ccs/ccs-regs.h
+@@ -1,5 +1,9 @@
+ /* SPDX-License-Identifier: GPL-2.0-only OR BSD-3-Clause */
+ /* Copyright (C) 2019--2020 Intel Corporation */
++/*
++ * Generated by Documentation/driver-api/media/drivers/ccs/mk-ccs-regs;
++ * do not modify.
++ */
+
+ #ifndef __CCS_REGS_H__
+ #define __CCS_REGS_H__
+@@ -202,7 +206,7 @@
+ #define CCS_R_OP_PIX_CLK_DIV (0x0308 | CCS_FL_16BIT)
+ #define CCS_R_OP_SYS_CLK_DIV (0x030a | CCS_FL_16BIT)
+ #define CCS_R_OP_PRE_PLL_CLK_DIV (0x030c | CCS_FL_16BIT)
+-#define CCS_R_OP_PLL_MULTIPLIER (0x031e | CCS_FL_16BIT)
++#define CCS_R_OP_PLL_MULTIPLIER (0x030e | CCS_FL_16BIT)
+ #define CCS_R_PLL_MODE 0x0310
+ #define CCS_PLL_MODE_SHIFT 0U
+ #define CCS_PLL_MODE_MASK 0x1
--- /dev/null
+From 8c8b9a9be2afa8bd6a72ad1130532baab9fab89d Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Fri, 21 May 2021 15:28:38 +0200
+Subject: media: dtv5100: fix control-request directions
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 8c8b9a9be2afa8bd6a72ad1130532baab9fab89d upstream.
+
+The direction of the pipe argument must match the request-type direction
+bit or control requests may fail depending on the host-controller-driver
+implementation.
+
+Fix the control requests which erroneously used usb_rcvctrlpipe().
+
+Fixes: 8466028be792 ("V4L/DVB (8734): Initial support for AME DTV-5100 USB2.0 DVB-T")
+Cc: stable@vger.kernel.org # 2.6.28
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/dvb-usb/dtv5100.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/media/usb/dvb-usb/dtv5100.c
++++ b/drivers/media/usb/dvb-usb/dtv5100.c
+@@ -26,6 +26,7 @@ static int dtv5100_i2c_msg(struct dvb_us
+ u8 *wbuf, u16 wlen, u8 *rbuf, u16 rlen)
+ {
+ struct dtv5100_state *st = d->priv;
++ unsigned int pipe;
+ u8 request;
+ u8 type;
+ u16 value;
+@@ -34,6 +35,7 @@ static int dtv5100_i2c_msg(struct dvb_us
+ switch (wlen) {
+ case 1:
+ /* write { reg }, read { value } */
++ pipe = usb_rcvctrlpipe(d->udev, 0);
+ request = (addr == DTV5100_DEMOD_ADDR ? DTV5100_DEMOD_READ :
+ DTV5100_TUNER_READ);
+ type = USB_TYPE_VENDOR | USB_DIR_IN;
+@@ -41,6 +43,7 @@ static int dtv5100_i2c_msg(struct dvb_us
+ break;
+ case 2:
+ /* write { reg, value } */
++ pipe = usb_sndctrlpipe(d->udev, 0);
+ request = (addr == DTV5100_DEMOD_ADDR ? DTV5100_DEMOD_WRITE :
+ DTV5100_TUNER_WRITE);
+ type = USB_TYPE_VENDOR | USB_DIR_OUT;
+@@ -54,7 +57,7 @@ static int dtv5100_i2c_msg(struct dvb_us
+
+ memcpy(st->data, rbuf, rlen);
+ msleep(1); /* avoid I2C errors */
+- return usb_control_msg(d->udev, usb_rcvctrlpipe(d->udev, 0), request,
++ return usb_control_msg(d->udev, pipe, request,
+ type, value, index, st->data, rlen,
+ DTV5100_USB_TIMEOUT);
+ }
+@@ -141,7 +144,7 @@ static int dtv5100_probe(struct usb_inte
+
+ /* initialize non qt1010/zl10353 part? */
+ for (i = 0; dtv5100_init[i].request; i++) {
+- ret = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
++ ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
+ dtv5100_init[i].request,
+ USB_TYPE_VENDOR | USB_DIR_OUT,
+ dtv5100_init[i].value,
--- /dev/null
+From 53ae298fde7adcc4b1432bce2dbdf8dac54dfa72 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Fri, 21 May 2021 15:28:39 +0200
+Subject: media: gspca/sq905: fix control-request direction
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 53ae298fde7adcc4b1432bce2dbdf8dac54dfa72 upstream.
+
+The direction of the pipe argument must match the request-type direction
+bit or control requests may fail depending on the host-controller-driver
+implementation.
+
+Fix the USB_REQ_SYNCH_FRAME request which erroneously used
+usb_sndctrlpipe().
+
+Fixes: 27d35fc3fb06 ("V4L/DVB (10639): gspca - sq905: New subdriver.")
+Cc: stable@vger.kernel.org # 2.6.30
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/gspca/sq905.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/media/usb/gspca/sq905.c
++++ b/drivers/media/usb/gspca/sq905.c
+@@ -116,7 +116,7 @@ static int sq905_command(struct gspca_de
+ }
+
+ ret = usb_control_msg(gspca_dev->dev,
+- usb_sndctrlpipe(gspca_dev->dev, 0),
++ usb_rcvctrlpipe(gspca_dev->dev, 0),
+ USB_REQ_SYNCH_FRAME, /* request */
+ USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+ SQ905_PING, 0, gspca_dev->usb_buf, 1,
--- /dev/null
+From b4bb4d425b7b02424afea2dfdcd77b3b4794175e Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 24 May 2021 13:09:19 +0200
+Subject: media: gspca/sunplus: fix zero-length control requests
+
+From: Johan Hovold <johan@kernel.org>
+
+commit b4bb4d425b7b02424afea2dfdcd77b3b4794175e upstream.
+
+The direction of the pipe argument must match the request-type direction
+bit or control requests may fail depending on the host-controller-driver
+implementation.
+
+Control transfers without a data stage are treated as OUT requests by
+the USB stack and should be using usb_sndctrlpipe(). Failing to do so
+will now trigger a warning.
+
+Fix the single zero-length control request which was using the
+read-register helper, and update the helper so that zero-length reads
+fail with an error message instead.
+
+Fixes: 6a7eba24e4f0 ("V4L/DVB (8157): gspca: all subdrivers")
+Cc: stable@vger.kernel.org # 2.6.27
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/gspca/sunplus.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/media/usb/gspca/sunplus.c
++++ b/drivers/media/usb/gspca/sunplus.c
+@@ -242,6 +242,10 @@ static void reg_r(struct gspca_dev *gspc
+ gspca_err(gspca_dev, "reg_r: buffer overflow\n");
+ return;
+ }
++ if (len == 0) {
++ gspca_err(gspca_dev, "reg_r: zero-length read\n");
++ return;
++ }
+ if (gspca_dev->usb_err < 0)
+ return;
+ ret = usb_control_msg(gspca_dev->dev,
+@@ -250,7 +254,7 @@ static void reg_r(struct gspca_dev *gspc
+ USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+ 0, /* value */
+ index,
+- len ? gspca_dev->usb_buf : NULL, len,
++ gspca_dev->usb_buf, len,
+ 500);
+ if (ret < 0) {
+ pr_err("reg_r err %d\n", ret);
+@@ -727,7 +731,7 @@ static int sd_start(struct gspca_dev *gs
+ case MegaImageVI:
+ reg_w_riv(gspca_dev, 0xf0, 0, 0);
+ spca504B_WaitCmdStatus(gspca_dev);
+- reg_r(gspca_dev, 0xf0, 4, 0);
++ reg_w_riv(gspca_dev, 0xf0, 4, 0);
+ spca504B_WaitCmdStatus(gspca_dev);
+ break;
+ default:
--- /dev/null
+From da3a1858c3a37c09446e1470c48352897d59d11b Mon Sep 17 00:00:00 2001
+From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Date: Fri, 23 Apr 2021 17:19:11 +0200
+Subject: media: i2c: ccs-core: fix pm_runtime_get_sync() usage count
+
+From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+
+commit da3a1858c3a37c09446e1470c48352897d59d11b upstream.
+
+The pm_runtime_get_sync() internally increments the
+dev->power.usage_count without decrementing it, even on errors.
+
+There is a bug at ccs_pm_get_init(): when this function returns
+an error, the stream is not started, and RPM usage_count
+should not be incremented. However, if the calls to
+v4l2_ctrl_handler_setup() return errors, it will be kept
+incremented.
+
+At ccs_suspend() the best is to replace it by the new
+pm_runtime_resume_and_get(), introduced by:
+commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
+in order to properly decrement the usage counter automatically,
+in the case of errors.
+
+Fixes: 96e3a6b92f23 ("media: smiapp: Avoid maintaining power state information")
+Cc: stable@vger.kernel.org
+Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/i2c/ccs/ccs-core.c | 32 ++++++++++++++++++++++----------
+ 1 file changed, 22 insertions(+), 10 deletions(-)
+
+--- a/drivers/media/i2c/ccs/ccs-core.c
++++ b/drivers/media/i2c/ccs/ccs-core.c
+@@ -1880,21 +1880,33 @@ static int ccs_pm_get_init(struct ccs_se
+ struct i2c_client *client = v4l2_get_subdevdata(&sensor->src->sd);
+ int rval;
+
++ /*
++ * It can't use pm_runtime_resume_and_get() here, as the driver
++ * relies at the returned value to detect if the device was already
++ * active or not.
++ */
+ rval = pm_runtime_get_sync(&client->dev);
+- if (rval < 0) {
+- pm_runtime_put_noidle(&client->dev);
++ if (rval < 0)
++ goto error;
+
+- return rval;
+- } else if (!rval) {
+- rval = v4l2_ctrl_handler_setup(&sensor->pixel_array->
+- ctrl_handler);
+- if (rval)
+- return rval;
++ /* Device was already active, so don't set controls */
++ if (rval == 1)
++ return 0;
+
+- return v4l2_ctrl_handler_setup(&sensor->src->ctrl_handler);
+- }
++ /* Restore V4L2 controls to the previously suspended device */
++ rval = v4l2_ctrl_handler_setup(&sensor->pixel_array->ctrl_handler);
++ if (rval)
++ goto error;
+
++ rval = v4l2_ctrl_handler_setup(&sensor->src->ctrl_handler);
++ if (rval)
++ goto error;
++
++ /* Keep PM runtime usage_count incremented on success */
+ return 0;
++error:
++ pm_runtime_put(&client->dev);
++ return rval;
+ }
+
+ static int ccs_set_stream(struct v4l2_subdev *subdev, int enable)
--- /dev/null
+From 25d5ce3a606a1eb23a9265d615a92a876ff9cb5f Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 24 May 2021 13:09:20 +0200
+Subject: media: rtl28xxu: fix zero-length control request
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 25d5ce3a606a1eb23a9265d615a92a876ff9cb5f upstream.
+
+The direction of the pipe argument must match the request-type direction
+bit or control requests may fail depending on the host-controller-driver
+implementation.
+
+Control transfers without a data stage are treated as OUT requests by
+the USB stack and should be using usb_sndctrlpipe(). Failing to do so
+will now trigger a warning.
+
+Fix the zero-length i2c-read request used for type detection by
+attempting to read a single byte instead.
+
+Reported-by: syzbot+faf11bbadc5a372564da@syzkaller.appspotmail.com
+Fixes: d0f232e823af ("[media] rtl28xxu: add heuristic to detect chip type")
+Cc: stable@vger.kernel.org # 4.0
+Cc: Antti Palosaari <crope@iki.fi>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
++++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+@@ -612,8 +612,9 @@ static int rtl28xxu_read_config(struct d
+ static int rtl28xxu_identify_state(struct dvb_usb_device *d, const char **name)
+ {
+ struct rtl28xxu_dev *dev = d_to_priv(d);
++ u8 buf[1];
+ int ret;
+- struct rtl28xxu_req req_demod_i2c = {0x0020, CMD_I2C_DA_RD, 0, NULL};
++ struct rtl28xxu_req req_demod_i2c = {0x0020, CMD_I2C_DA_RD, 1, buf};
+
+ dev_dbg(&d->intf->dev, "\n");
+
--- /dev/null
+From 4c6e0976295add7f0ed94d276c04a3d6f1ea8f83 Mon Sep 17 00:00:00 2001
+From: Benjamin Drung <bdrung@posteo.de>
+Date: Sat, 5 Jun 2021 22:15:36 +0200
+Subject: media: uvcvideo: Fix pixel format change for Elgato Cam Link 4K
+
+From: Benjamin Drung <bdrung@posteo.de>
+
+commit 4c6e0976295add7f0ed94d276c04a3d6f1ea8f83 upstream.
+
+The Elgato Cam Link 4K HDMI video capture card reports to support three
+different pixel formats, where the first format depends on the connected
+HDMI device.
+
+```
+$ v4l2-ctl -d /dev/video0 --list-formats-ext
+ioctl: VIDIOC_ENUM_FMT
+ Type: Video Capture
+
+ [0]: 'NV12' (Y/CbCr 4:2:0)
+ Size: Discrete 3840x2160
+ Interval: Discrete 0.033s (29.970 fps)
+ [1]: 'NV12' (Y/CbCr 4:2:0)
+ Size: Discrete 3840x2160
+ Interval: Discrete 0.033s (29.970 fps)
+ [2]: 'YU12' (Planar YUV 4:2:0)
+ Size: Discrete 3840x2160
+ Interval: Discrete 0.033s (29.970 fps)
+```
+
+Changing the pixel format to anything besides the first pixel format
+does not work:
+
+```
+$ v4l2-ctl -d /dev/video0 --try-fmt-video pixelformat=YU12
+Format Video Capture:
+ Width/Height : 3840/2160
+ Pixel Format : 'NV12' (Y/CbCr 4:2:0)
+ Field : None
+ Bytes per Line : 3840
+ Size Image : 12441600
+ Colorspace : sRGB
+ Transfer Function : Rec. 709
+ YCbCr/HSV Encoding: Rec. 709
+ Quantization : Default (maps to Limited Range)
+ Flags :
+```
+
+User space applications like VLC might show an error message on the
+terminal in that case:
+
+```
+libv4l2: error set_fmt gave us a different result than try_fmt!
+```
+
+Depending on the error handling of the user space applications, they
+might display a distorted video, because they use the wrong pixel format
+for decoding the stream.
+
+The Elgato Cam Link 4K responds to the USB video probe
+VS_PROBE_CONTROL/VS_COMMIT_CONTROL with a malformed data structure: The
+second byte contains bFormatIndex (instead of being the second byte of
+bmHint). The first byte is always zero. The third byte is always 1.
+
+The firmware bug was reported to Elgato on 2020-12-01 and it was
+forwarded by the support team to the developers as feature request.
+There is no firmware update available since then. The latest firmware
+for Elgato Cam Link 4K as of 2021-03-23 has MCU 20.02.19 and FPGA 67.
+
+Therefore correct the malformed data structure for this device. The
+change was successfully tested with VLC, OBS, and Chromium using
+different pixel formats (YUYV, NV12, YU12), resolutions (3840x2160,
+1920x1080), and frame rates (29.970 and 59.940 fps).
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Benjamin Drung <bdrung@posteo.de>
+Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/uvc/uvc_video.c | 27 +++++++++++++++++++++++++++
+ 1 file changed, 27 insertions(+)
+
+--- a/drivers/media/usb/uvc/uvc_video.c
++++ b/drivers/media/usb/uvc/uvc_video.c
+@@ -127,10 +127,37 @@ int uvc_query_ctrl(struct uvc_device *de
+ static void uvc_fixup_video_ctrl(struct uvc_streaming *stream,
+ struct uvc_streaming_control *ctrl)
+ {
++ static const struct usb_device_id elgato_cam_link_4k = {
++ USB_DEVICE(0x0fd9, 0x0066)
++ };
+ struct uvc_format *format = NULL;
+ struct uvc_frame *frame = NULL;
+ unsigned int i;
+
++ /*
++ * The response of the Elgato Cam Link 4K is incorrect: The second byte
++ * contains bFormatIndex (instead of being the second byte of bmHint).
++ * The first byte is always zero. The third byte is always 1.
++ *
++ * The UVC 1.5 class specification defines the first five bits in the
++ * bmHint bitfield. The remaining bits are reserved and should be zero.
++ * Therefore a valid bmHint will be less than 32.
++ *
++ * Latest Elgato Cam Link 4K firmware as of 2021-03-23 needs this fix.
++ * MCU: 20.02.19, FPGA: 67
++ */
++ if (usb_match_one_id(stream->dev->intf, &elgato_cam_link_4k) &&
++ ctrl->bmHint > 255) {
++ u8 corrected_format_index = ctrl->bmHint >> 8;
++
++ uvc_dbg(stream->dev, VIDEO,
++ "Correct USB video probe response from {bmHint: 0x%04x, bFormatIndex: %u} to {bmHint: 0x%04x, bFormatIndex: %u}\n",
++ ctrl->bmHint, ctrl->bFormatIndex,
++ 1, corrected_format_index);
++ ctrl->bmHint = 1;
++ ctrl->bFormatIndex = corrected_format_index;
++ }
++
+ for (i = 0; i < stream->nformats; ++i) {
+ if (stream->format[i].index == ctrl->bFormatIndex) {
+ format = &stream->format[i];
--- /dev/null
+From 0a045eac8d0427b64577a24d74bb8347c905ac65 Mon Sep 17 00:00:00 2001
+From: Pavel Skripkin <paskripkin@gmail.com>
+Date: Mon, 17 May 2021 21:18:14 +0200
+Subject: media: zr364xx: fix memory leak in zr364xx_start_readpipe
+
+From: Pavel Skripkin <paskripkin@gmail.com>
+
+commit 0a045eac8d0427b64577a24d74bb8347c905ac65 upstream.
+
+syzbot reported memory leak in zr364xx driver.
+The problem was in non-freed urb in case of
+usb_submit_urb() fail.
+
+backtrace:
+ [<ffffffff82baedf6>] kmalloc include/linux/slab.h:561 [inline]
+ [<ffffffff82baedf6>] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74
+ [<ffffffff82f7cce8>] zr364xx_start_readpipe+0x78/0x130 drivers/media/usb/zr364xx/zr364xx.c:1022
+ [<ffffffff84251dfc>] zr364xx_board_init drivers/media/usb/zr364xx/zr364xx.c:1383 [inline]
+ [<ffffffff84251dfc>] zr364xx_probe+0x6a3/0x851 drivers/media/usb/zr364xx/zr364xx.c:1516
+ [<ffffffff82bb6507>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
+ [<ffffffff826018a9>] really_probe+0x159/0x500 drivers/base/dd.c:576
+
+Fixes: ccbf035ae5de ("V4L/DVB (12278): zr364xx: implement V4L2_CAP_STREAMING")
+Cc: stable@vger.kernel.org
+Reported-by: syzbot+af4fa391ef18efdd5f69@syzkaller.appspotmail.com
+Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/zr364xx/zr364xx.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/media/usb/zr364xx/zr364xx.c
++++ b/drivers/media/usb/zr364xx/zr364xx.c
+@@ -1032,6 +1032,7 @@ static int zr364xx_start_readpipe(struct
+ DBG("submitting URB %p\n", pipe_info->stream_urb);
+ retval = usb_submit_urb(pipe_info->stream_urb, GFP_KERNEL);
+ if (retval) {
++ usb_free_urb(pipe_info->stream_urb);
+ printk(KERN_ERR KBUILD_MODNAME ": start read pipe failed\n");
+ return retval;
+ }
pci-aardvark-fix-checking-for-pio-non-posted-request.patch
pci-aardvark-implement-workaround-for-the-readback-value-of-vend_id.patch
media-subdev-disallow-ioctl-for-saa6588-davinci.patch
+media-i2c-ccs-core-fix-pm_runtime_get_sync-usage-count.patch
+media-dtv5100-fix-control-request-directions.patch
+media-zr364xx-fix-memory-leak-in-zr364xx_start_readpipe.patch
+media-ccs-fix-the-op_pll_multiplier-address.patch
+media-gspca-sq905-fix-control-request-direction.patch
+media-gspca-sunplus-fix-zero-length-control-requests.patch
+media-rtl28xxu-fix-zero-length-control-request.patch
+media-uvcvideo-fix-pixel-format-change-for-elgato-cam-link-4k.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
