On 24/11/2020 17:00, Alan Stern wrote: > The gspca driver leaks memory when a probe fails. gspca_dev_probe2() > calls v4l2_device_register(), which takes a reference to the > underlying device node (in this case, a USB interface). But the > failure pathway neglects to call v4l2_device_disconnect(), the routine > responsible for dropping this reference. Consequently the memory for > the USB interface and its device never gets released. > > This patch adds the missing function call. > > Signed-off-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> > Reported-and-tested-by: syzbot+44e64397bd81d5e84cba@xxxxxxxxxxxxxxxxxxxxxxxxx > CC: <stable@xxxxxxxxxxxxxxx> > > --- > > This doesn't fully fix syzbot's test case, because the test goes on and > encounters another memory leak in a different driver. > > > [as1949] > > > drivers/media/usb/gspca/gspca.c | 1 + > 1 file changed, 1 insertion(+) > > Index: usb-devel/drivers/media/usb/gspca/gspca.c > =================================================================== > --- usb-devel.orig/drivers/media/usb/gspca/gspca.c > +++ usb-devel/drivers/media/usb/gspca/gspca.c > @@ -1575,6 +1575,7 @@ out: > input_unregister_device(gspca_dev->input_dev); > #endif > v4l2_ctrl_handler_free(gspca_dev->vdev.ctrl_handler); > + v4l2_device_disconnect(&gspca_dev->v4l2_dev); Close, but no cigar. This should call v4l2_device_unregister(), the counterpart of video_device_register. This unregister function also calls v4l2_device_disconnect, but the code makes a lot more sense if the v4l2_device_register is matched with the v4l2_device_unregister. Regards, Hans > kfree(gspca_dev->usb_buf); > kfree(gspca_dev); > return ret; >
