[PATCH] media: zr364xx: propagate errors from zr364xx_start_readpipe()
zr364xx_start_readpipe() can fail but callers do not care about that.
This can result in various negative consequences. The patch adds missed
error handling.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov
---
drivers/media/usb/zr364xx/zr364xx.c | 31 ++---
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/media/usb/zr364xx/zr364xx.c
b/drivers/media/usb/zr364xx/zr364xx.c
index 8c670934d920..d65d3c2a034e 100644
--- a/drivers/media/usb/zr364xx/zr364xx.c
+++ b/drivers/media/usb/zr364xx/zr364xx.c
@@ -1327,6 +1327,7 @@ static int zr364xx_board_init(struct zr364xx_camera *cam)
{
struct zr364xx_pipeinfo *pipe = cam->pipe;
unsigned long i;
+ int err;
DBG("board init: %p\n", cam);
memset(pipe, 0, sizeof(*pipe));
@@ -1359,9 +1360,8 @@ static int zr364xx_board_init(struct zr364xx_camera *cam)
if (i == 0) {
printk(KERN_INFO KBUILD_MODNAME ": out of memory. Aborting\n");
- kfree(cam->pipe->transfer_buffer);
- cam->pipe->transfer_buffer = NULL;
- return -ENOMEM;
+ err = -ENOMEM;
+ goto err_free;
} else
cam->buffer.dwFrames = i;
@@ -1376,9 +1376,17 @@ static int zr364xx_board_init(struct zr364xx_camera *cam)
/*** end create system buffers ***/
/* start read pipe */
- zr364xx_start_readpipe(cam);
+ err = zr364xx_start_readpipe(cam);
+ if (err)
+ goto err_free;
+
DBG(": board initialized\n");
return 0;
+
+err_free:
+ kfree(cam->pipe->transfer_buffer);
+ cam->pipe->transfer_buffer = NULL;
+ return err;
}
static int zr364xx_probe(struct usb_interface *intf,
@@ -1575,10 +1583,19 @@ static int zr364xx_resume(struct usb_interface *intf)
if (!cam->was_streaming)
return 0;
- zr364xx_start_readpipe(cam);
+ res = zr364xx_start_readpipe(cam);
+ if (res)
+ return res;
+
res = zr364xx_prepare(cam);
- if (!res)
- zr364xx_start_acquire(cam);
+ if (res)
+ goto err_prepare;
+
+ zr364xx_start_acquire(cam);
+ return 0;
+
+err_prepare:
+ zr364xx_stop_readpipe(cam);
return res;
}
#endif
--
2.26.2
[PATCH] usb: gadget: goku_udc: fix potential crashes in probe
goku_probe() goes to error label "err" and invokes goku_remove() in case of failures of pci_enable_device(), pci_resource_start() and ioremap(). goku_remove() gets a device from pci_get_drvdata(pdev) and works with it without any checks, in particular it dereferences a corresponding pointer. But goku_probe() did not set this device yet. So, one can expect various crashes. The patch moves setting the device just after allocation of memory for it. Found by Linux Driver Verification project (linuxtesting.org). Reported-by: Pavel Andrianov Signed-off-by: Evgeny Novikov --- drivers/usb/gadget/udc/goku_udc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/udc/goku_udc.c b/drivers/usb/gadget/udc/goku_udc.c index 25c1d6ab5adb..3e1267d38774 100644 --- a/drivers/usb/gadget/udc/goku_udc.c +++ b/drivers/usb/gadget/udc/goku_udc.c @@ -1760,6 +1760,7 @@ static int goku_probe(struct pci_dev *pdev, const struct pci_device_id *id) goto err; } + pci_set_drvdata(pdev, dev); spin_lock_init(>lock); dev->pdev = pdev; dev->gadget.ops = _ops; @@ -1793,7 +1794,6 @@ static int goku_probe(struct pci_dev *pdev, const struct pci_device_id *id) } dev->regs = (struct goku_udc_regs __iomem *) base; - pci_set_drvdata(pdev, dev); INFO(dev, "%s\n", driver_desc); INFO(dev, "version: " DRIVER_VERSION " %s\n", dmastr()); INFO(dev, "irq %d, pci mem %p\n", pdev->irq, base); -- 2.26.2
[PATCH] media: dvb-frontends: rtl2832_sdr: set error code in probe
If rtl2832_sdr_probe() encounters an unsupported tuner it cleans up
everything and returns 0. This can result in various bad things later.
The patch sets the error code on the corresponding path.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov
---
drivers/media/dvb-frontends/rtl2832_sdr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/dvb-frontends/rtl2832_sdr.c
b/drivers/media/dvb-frontends/rtl2832_sdr.c
index 720756728f2d..ef6feb299d46 100644
--- a/drivers/media/dvb-frontends/rtl2832_sdr.c
+++ b/drivers/media/dvb-frontends/rtl2832_sdr.c
@@ -1411,6 +1411,7 @@ static int rtl2832_sdr_probe(struct platform_device *pdev)
default:
v4l2_ctrl_handler_init(>hdl, 0);
dev_err(>dev, "Unsupported tuner\n");
+ ret = -ENODEV;
goto err_v4l2_ctrl_handler_free;
}
if (dev->hdl.error) {
--
2.26.2
[media] st-hva: potential null pointer dereference in hva_hw_its_irq_thread()
If ctx_id >= HVA_MAX_INSTANCES in hva_hw_its_irq_thread(), it dereferences ctx that is initialized to NULL. I can not provide the patch since I do not know the logic of the driver and I have not a capability to test it. Found by Linux Driver Verification project (linuxtesting.org). -- Best regards, Evgeny Novikov
[PATCH] mtd: rawnand: mtk: avoid underflow in mtk_nfc_nand_chip_init()
If of_get_property() will set nsels to negative values the driver may
allocate insufficient memory for chip. Moreover, there may be underflow
for devm_kzalloc(). This can result in various bad consequences later.
The patch causes mtk_nfc_nand_chip_init() to fail for negative values of
nsels.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov
---
drivers/mtd/nand/raw/mtk_nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/mtk_nand.c b/drivers/mtd/nand/raw/mtk_nand.c
index ad1b55dab211..df98a2eec240 100644
--- a/drivers/mtd/nand/raw/mtk_nand.c
+++ b/drivers/mtd/nand/raw/mtk_nand.c
@@ -1376,7 +1376,7 @@ static int mtk_nfc_nand_chip_init(struct device *dev,
struct mtk_nfc *nfc,
return -ENODEV;
nsels /= sizeof(u32);
- if (!nsels || nsels > MTK_NAND_MAX_NSELS) {
+ if (nsels <= 0 || nsels > MTK_NAND_MAX_NSELS) {
dev_err(dev, "invalid reg property size %d\n", nsels);
return -EINVAL;
}
--
2.26.2
Re: [PATCH 4.19 047/125] media: davinci: vpif_capture: fix potential double free
Hi Pavel, Maybe I miss something, but it seems that in 4.19 vpif_probe() ignores error codes from vpif_probe_complete() and returns 0 even if it fails. That was fixed by commit 64f883cd98c6, but it was not backported to 4.19. In addition, this commit contains a fix of one more bug. Regarding your second note. I investigated other drivers that use the same mechanism and did not find out any driver that performs clean up in the complete handler. In particular, this is the case for very similar driver vpif_display.c. I am not an expert in this subsystem, so, I can not reason why this is so. -- Best regards, Evgeny Novikov 01.09.2020, 21:43, "Pavel Machek" : > Hi! > >> [ Upstream commit 602649eadaa0c977e362e641f51ec306bc1d365d ] >> >> In case of errors vpif_probe_complete() releases memory for vpif_obj.sd >> and unregisters the V4L2 device. But then this is done again by >> vpif_probe() itself. The patch removes the cleaning from >> vpif_probe_complete(). > >> Signed-off-by: Evgeny Novikov >> Signed-off-by: Hans Verkuil >> Signed-off-by: Mauro Carvalho Chehab >> Signed-off-by: Sasha Levin >> --- >> drivers/media/platform/davinci/vpif_capture.c | 2 -- >> 1 file changed, 2 deletions(-) >> >> diff --git a/drivers/media/platform/davinci/vpif_capture.c >> b/drivers/media/platform/davinci/vpif_capture.c >> index a96f53ce80886..cf1d11e6dd8c4 100644 >> --- a/drivers/media/platform/davinci/vpif_capture.c >> +++ b/drivers/media/platform/davinci/vpif_capture.c >> @@ -1489,8 +1489,6 @@ probe_out: >> /* Unregister video device */ >> video_unregister_device(>video_dev); >> } >> - kfree(vpif_obj.sd); >> - v4l2_device_unregister(_obj.v4l2_dev); >> >> return err; >> } > > This one is wrong. Unlike mainline, 4.19 does check return value of > vpif_probe_complete(), and thus it will lead to memory leak in 4.19. > > Furthermore, I believe mainline still has a problems after this > patch. There is sync and async path where vpif_probe_complete(), and > while this fixes the sync path in mainline, I believe it will cause > memory leak on the async path. > > Best regards, > Pavel > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [ldv-project] [PATCH] drivers: watchdog: rdc321x_wdt: Fix race condition bugs
07.08.2020, 19:21, "Guenter Roeck" :
> On Fri, Aug 07, 2020 at 04:59:02PM +0530, madhuparnabhowmi...@gmail.com wrote:
>> From: Madhuparna Bhowmik
>>
>> In rdc321x_wdt_probe(), rdc321x_wdt_device.queue is initialized
>> after misc_register(), hence if ioctl is called before its
>> initialization which can call rdc321x_wdt_start() function,
>> it will see an uninitialized value of rdc321x_wdt_device.queue,
>> hence initialize it before misc_register().
>> Also, rdc321x_wdt_device.default_ticks is accessed in reset()
>> function called from write callback, thus initialize it before
>> misc_register().
>>
>> Found by Linux Driver Verification project (linuxtesting.org).
>>
>> Signed-off-by: Madhuparna Bhowmik
>
> Reviewed-by: Guenter Roeck
>
> Having said that ... this is yet another potentially obsolete driver.
> You are really wasting your (and, fwiw, my) time.
Static analysis tools are not aware about obsolete drivers.
It would be great if there will be some formal way to filter them out.
Maybe some file will enumerate all obsolete drivers, or there will be
something within their source code, or something else.
--
Best regards,
Evgeny Novikov
>
> Florian, any thoughts if support for this chip can/should be deprecated
> or even removed ?
>
> Guenter
>
>> ---
>> drivers/watchdog/rdc321x_wdt.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/watchdog/rdc321x_wdt.c b/drivers/watchdog/rdc321x_wdt.c
>> index 57187efeb86f..f0c94ea51c3e 100644
>> --- a/drivers/watchdog/rdc321x_wdt.c
>> +++ b/drivers/watchdog/rdc321x_wdt.c
>> @@ -231,6 +231,8 @@ static int rdc321x_wdt_probe(struct platform_device
>> *pdev)
>>
>> rdc321x_wdt_device.sb_pdev = pdata->sb_pdev;
>> rdc321x_wdt_device.base_reg = r->start;
>> + rdc321x_wdt_device.queue = 0;
>> + rdc321x_wdt_device.default_ticks = ticks;
>>
>> err = misc_register(_wdt_misc);
>> if (err < 0) {
>> @@ -245,14 +247,11 @@ static int rdc321x_wdt_probe(struct platform_device
>> *pdev)
>> rdc321x_wdt_device.base_reg, RDC_WDT_RST);
>>
>> init_completion(_wdt_device.stop);
>> - rdc321x_wdt_device.queue = 0;
>>
>> clear_bit(0, _wdt_device.inuse);
>>
>> timer_setup(_wdt_device.timer, rdc321x_wdt_trigger, 0);
>>
>> - rdc321x_wdt_device.default_ticks = ticks;
>> -
>> dev_info(>dev, "watchdog init success\n");
>>
>> return 0;
>> --
>> 2.17.1
>
> ___
> ldv-project mailing list
> ldv-proj...@linuxtesting.org
> http://linuxtesting.org/cgi-bin/mailman/listinfo/ldv-project
[PATCH] mtd: rawnand: vf610: disable clk on error handling path in probe
vf610_nfc_probe() does not invoke clk_disable_unprepare() on one error
handling path. The patch fixes that.
Found by Linux Driver Verification project (linuxtesting.org).
Fixes: 6f0ce4dfc5a3 ("mtd: rawnand: vf610: Avoid a potential NULL pointer
dereference")
Signed-off-by: Evgeny Novikov
---
drivers/mtd/nand/raw/vf610_nfc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/raw/vf610_nfc.c b/drivers/mtd/nand/raw/vf610_nfc.c
index 7248c5901183..fcca45e2abe2 100644
--- a/drivers/mtd/nand/raw/vf610_nfc.c
+++ b/drivers/mtd/nand/raw/vf610_nfc.c
@@ -852,8 +852,10 @@ static int vf610_nfc_probe(struct platform_device *pdev)
}
of_id = of_match_device(vf610_nfc_dt_ids, >dev);
- if (!of_id)
- return -ENODEV;
+ if (!of_id) {
+ err = -ENODEV;
+ goto err_disable_clk;
+ }
nfc->variant = (enum vf610_nfc_variant)of_id->data;
--
2.26.2
[PATCH] HID: u2fzero: handle errors of u2fzero_fill_in_urb() in probe
u2fzero_probe() does not handle errors of u2fzero_fill_in_urb(). The
patch fixes that.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov
---
drivers/hid/hid-u2fzero.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-u2fzero.c b/drivers/hid/hid-u2fzero.c
index 95e0807878c7..0632f6c3aa66 100644
--- a/drivers/hid/hid-u2fzero.c
+++ b/drivers/hid/hid-u2fzero.c
@@ -315,7 +315,11 @@ static int u2fzero_probe(struct hid_device *hdev,
if (ret)
return ret;
- u2fzero_fill_in_urb(dev);
+ ret = u2fzero_fill_in_urb(dev);
+ if (ret) {
+ hid_hw_stop(hdev);
+ return ret;
+ }
dev->present = true;
--
2.26.2
[PATCH] USB: lvtest: return proper error code in probe
lvs_rh_probe() can return some nonnegative value from usb_control_msg()
when it is less than "USB_DT_HUB_NONVAR_SIZE + 2" that is considered as
a failure. Make lvs_rh_probe() return -EINVAL in this case.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov
---
drivers/usb/misc/lvstest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/misc/lvstest.c b/drivers/usb/misc/lvstest.c
index 407fe7570f3b..f8686139d6f3 100644
--- a/drivers/usb/misc/lvstest.c
+++ b/drivers/usb/misc/lvstest.c
@@ -426,7 +426,7 @@ static int lvs_rh_probe(struct usb_interface *intf,
USB_DT_SS_HUB_SIZE, USB_CTRL_GET_TIMEOUT);
if (ret < (USB_DT_HUB_NONVAR_SIZE + 2)) {
dev_err(>dev, "wrong root hub descriptor read %d\n", ret);
- return ret;
+ return ret < 0 ? ret : -EINVAL;
}
/* submit urb to poll interrupt endpoint */
--
2.26.2
media: ddbridge: potential buffer overflow in open
ddb_open() accesses iminor(inode) of the ddbs array that has 64 elements at most. There will be a buffer overflow if iminor(inode) is greater than 63. Found by Linux Driver Verification project (linuxtesting.org).
Re: hwmon: (sis5595) potential null pointer dereference in probe
04.08.2020, 17:33, "Guenter Roeck" : > On 8/4/20 4:50 AM, Evgeny Novikov wrote: >> sis5595_pci_probe() registers platform driver callbacks and just then >> initializes global pointer variable s_bridge. sis5595_probe() may >> dereference it before this happens that can result in null pointer >> dereference. > > sis5595_probe() is only called after the device is registered, > which happens in sis5595_device_add() after s_bridge is set. This is > a southbridge, so there won't be any hot insertion/removal events. > Thank you for this hint. We need to tune our models appropriately. >> We can not swap registration of platform driver callbacks with >> initialization of s_bridge since sm_sis5595_exit() assumes the >> current order. Perhaps it has sense to implement a pci_driver.remove >> callback that will take care about deregistration of platform driver >> callbacks. > > Agreed regarding the remove function. However, given the age of the chip, > I'd rather remove the driver than spending time on cleanup efforts. > This looks like a perfect candidate for depreciation. > This is completely up to you. Anyway the driver does not have the bug. Best regards, Evgeny > Guenter
hwmon: (sis5595) potential null pointer dereference in probe
sis5595_pci_probe() registers platform driver callbacks and just then initializes global pointer variable s_bridge. sis5595_probe() may dereference it before this happens that can result in null pointer dereference. We can not swap registration of platform driver callbacks with initialization of s_bridge since sm_sis5595_exit() assumes the current order. Perhaps it has sense to implement a pci_driver.remove callback that will take care about deregistration of platform driver callbacks. Found by Linux Driver Verification project (linuxtesting.org).
Re: [PATCH] media: davinci: vpif_capture: fix potential double free
Hi Lad, 25.07.2020, 01:06, "Lad, Prabhakar" : > Hi Evgeny, > > On Fri, Jul 24, 2020 at 9:00 PM Evgeny Novikov wrote: >> Hi Lad, >> >> Yet again I can not demonstrate you a nice error trace corresponding to the >> bug fixed by the patch. Indeed, there is a branch in vpif_probe() that >> explicitly invokes vpif_probe_complete() and the patch targets the possible >> issue that can happen during this. >> >> When I developed the patch I saw on vpif_display.ko. It looks very similar >> regarding things touched by the patch. In particular, it does not free >> vpif_obj.sd in its vpif_probe_complete(). But now I see that it does this in >> vpif_remove()! > > Makes sense. > >> Do you think that vpif_capture.ko should do the same? If so, I guess that I >> should fix the patch appropriately since likely it just replaces one (very >> rare) bug with another one (on a typical execution path). > > Yes it should. vpif_remove() from vpif_capture.ko already both frees vpif_obj.sd and unregisters the V4L2 device. So, there is no need to fix the patch. BTW, other drivers, e.g. drivers/media/platform/renesas-ceu.c, do not clean up memory allocated by probe within v4l2_async_notifier_operations.complete as well. -- Best regards, Evgeny Novikov > Cheers, > --Prabhakar > >> -- >> Evgeny Novikov >> Linux Verification Center, ISP RAS >> http://linuxtesting.org >> >> 24.07.2020, 17:17, "Lad, Prabhakar" : >> > Hi Evgeny, >> > >> > Thank you for the patch. >> > >> > On Thu, Jul 23, 2020 at 6:04 PM Evgeny Novikov wrote: >> >> In case of errors vpif_probe_complete() releases memory for vpif_obj.sd >> >> and unregisters the V4L2 device. But then this is done again by >> >> vpif_probe() itself. The patch removes the cleaning from >> >> vpif_probe_complete(). >> >> >> >> Found by Linux Driver Verification project (linuxtesting.org). >> >> >> >> Signed-off-by: Evgeny Novikov >> >> --- >> >> drivers/media/platform/davinci/vpif_capture.c | 2 -- >> >> 1 file changed, 2 deletions(-) >> >> >> >> diff --git a/drivers/media/platform/davinci/vpif_capture.c >> b/drivers/media/platform/davinci/vpif_capture.c >> >> index d9ec439faefa..72a0e94e2e21 100644 >> >> --- a/drivers/media/platform/davinci/vpif_capture.c >> >> +++ b/drivers/media/platform/davinci/vpif_capture.c >> >> @@ -1482,8 +1482,6 @@ static int vpif_probe_complete(void) >> >> /* Unregister video device */ >> >> video_unregister_device(>video_dev); >> >> } >> >> - kfree(vpif_obj.sd); >> >> - v4l2_device_unregister(_obj.v4l2_dev); >> > >> > vpif_probe_complete() is a async callback and probe() should have >> > already completed by then. >> > >> > Cheers, >> > --Prabhakar >> > >> >> return err; >> >> } >> >> -- >> >> 2.16.4
Re: [PATCH] media: davinci: vpif_capture: fix potential double free
Hi Markus, It seems that Lad Prabhakar detected a critical issue introduced by the patch instead of a minor bug fixed by it. So, we should take care of this first, but I will address your notes as well. -- Evgeny Novikov Linux Verification Center, ISP RAS http://linuxtesting.org 23.07.2020, 23:15, "Markus Elfring" : >> In case of errors vpif_probe_complete() releases memory for vpif_obj.sd >> and unregisters the V4L2 device. But then this is done again by >> vpif_probe() itself. The patch removes the cleaning from >> vpif_probe_complete(). > > * An imperative wording can be preferred for the change description, > can't it? > > * Would you like to add the tag “Fixes” to the commit message? > > Regards, > Markus
Re: [PATCH] media: davinci: vpif_capture: fix potential double free
Hi Lad, Yet again I can not demonstrate you a nice error trace corresponding to the bug fixed by the patch. Indeed, there is a branch in vpif_probe() that explicitly invokes vpif_probe_complete() and the patch targets the possible issue that can happen during this. When I developed the patch I saw on vpif_display.ko. It looks very similar regarding things touched by the patch. In particular, it does not free vpif_obj.sd in its vpif_probe_complete(). But now I see that it does this in vpif_remove()! Do you think that vpif_capture.ko should do the same? If so, I guess that I should fix the patch appropriately since likely it just replaces one (very rare) bug with another one (on a typical execution path). -- Evgeny Novikov Linux Verification Center, ISP RAS http://linuxtesting.org 24.07.2020, 17:17, "Lad, Prabhakar" : > Hi Evgeny, > > Thank you for the patch. > > On Thu, Jul 23, 2020 at 6:04 PM Evgeny Novikov wrote: >> In case of errors vpif_probe_complete() releases memory for vpif_obj.sd >> and unregisters the V4L2 device. But then this is done again by >> vpif_probe() itself. The patch removes the cleaning from >> vpif_probe_complete(). >> >> Found by Linux Driver Verification project (linuxtesting.org). >> >> Signed-off-by: Evgeny Novikov >> --- >> drivers/media/platform/davinci/vpif_capture.c | 2 -- >> 1 file changed, 2 deletions(-) >> >> diff --git a/drivers/media/platform/davinci/vpif_capture.c >> b/drivers/media/platform/davinci/vpif_capture.c >> index d9ec439faefa..72a0e94e2e21 100644 >> --- a/drivers/media/platform/davinci/vpif_capture.c >> +++ b/drivers/media/platform/davinci/vpif_capture.c >> @@ -1482,8 +1482,6 @@ static int vpif_probe_complete(void) >> /* Unregister video device */ >> video_unregister_device(>video_dev); >> } >> - kfree(vpif_obj.sd); >> - v4l2_device_unregister(_obj.v4l2_dev); > > vpif_probe_complete() is a async callback and probe() should have > already completed by then. > > Cheers, > --Prabhakar > >> return err; >> } >> -- >> 2.16.4
[PATCH] media: camss: fix memory leaks on error handling paths in probe
camss_probe() does not free camss on error handling paths. The patch
introduces an additional error label for this purpose. Besides, it
removes call of v4l2_async_notifier_cleanup() from
camss_of_parse_ports() since its caller, camss_probe(), cleans up all
its resources itself.
Found by Linux Driver Verification project (linuxtesting.org).
Co-Developed-by: Anton Vasilyev
Signed-off-by: Evgeny Novikov
Signed-off-by: Anton Vasilyev
---
drivers/media/platform/qcom/camss/camss.c | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/camss.c
b/drivers/media/platform/qcom/camss/camss.c
index 3fdc9f964a3c..2483641799df 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -504,7 +504,6 @@ static int camss_of_parse_ports(struct camss *camss)
return num_subdevs;
err_cleanup:
- v4l2_async_notifier_cleanup(>notifier);
of_node_put(node);
return ret;
}
@@ -835,29 +834,38 @@ static int camss_probe(struct platform_device *pdev)
camss->csid_num = 4;
camss->vfe_num = 2;
} else {
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_free;
}
camss->csiphy = devm_kcalloc(dev, camss->csiphy_num,
sizeof(*camss->csiphy), GFP_KERNEL);
- if (!camss->csiphy)
- return -ENOMEM;
+ if (!camss->csiphy) {
+ ret = -ENOMEM;
+ goto err_free;
+ }
camss->csid = devm_kcalloc(dev, camss->csid_num, sizeof(*camss->csid),
GFP_KERNEL);
- if (!camss->csid)
- return -ENOMEM;
+ if (!camss->csid) {
+ ret = -ENOMEM;
+ goto err_free;
+ }
camss->vfe = devm_kcalloc(dev, camss->vfe_num, sizeof(*camss->vfe),
GFP_KERNEL);
- if (!camss->vfe)
- return -ENOMEM;
+ if (!camss->vfe) {
+ ret = -ENOMEM;
+ goto err_free;
+ }
v4l2_async_notifier_init(>notifier);
num_subdevs = camss_of_parse_ports(camss);
- if (num_subdevs < 0)
- return num_subdevs;
+ if (num_subdevs < 0) {
+ ret = num_subdevs;
+ goto err_cleanup;
+ }
ret = camss_init_subdevices(camss);
if (ret < 0)
@@ -936,6 +944,8 @@ static int camss_probe(struct platform_device *pdev)
v4l2_device_unregister(>v4l2_dev);
err_cleanup:
v4l2_async_notifier_cleanup(>notifier);
+err_free:
+ kfree(camss);
return ret;
}
--
2.16.4
[PATCH] media: davinci: vpif_capture: fix potential double free
In case of errors vpif_probe_complete() releases memory for vpif_obj.sd and unregisters the V4L2 device. But then this is done again by vpif_probe() itself. The patch removes the cleaning from vpif_probe_complete(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Evgeny Novikov --- drivers/media/platform/davinci/vpif_capture.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c index d9ec439faefa..72a0e94e2e21 100644 --- a/drivers/media/platform/davinci/vpif_capture.c +++ b/drivers/media/platform/davinci/vpif_capture.c @@ -1482,8 +1482,6 @@ static int vpif_probe_complete(void) /* Unregister video device */ video_unregister_device(>video_dev); } - kfree(vpif_obj.sd); - v4l2_device_unregister(_obj.v4l2_dev); return err; } -- 2.16.4
Re: [PATCH] usb: gadget: net2280: fix memory leak on probe error handling paths
23.07.2020, 04:00, "Alan Stern" : > On Wed, Jul 22, 2020 at 10:56:09PM +0300, Evgeny Novikov wrote: >> Hi Alan, >> >> I have neither an appropriate hardware nor an experience to deal with >> issues that you mentioned. Our framework does not allow to detect them >> as well at the moment. At last, it seems that rather many drivers can >> suffer from these issues. So, it would be much better if somebody else >> will suggest necessary fixes and test them carefully. > > Heh... Working from home, I no longer have access to the appropriate > hardware either. But at least I do have the necessary experience. :-) > >> BTW, you have already discussed the race within net2280_remove() with >> my colleague about 3 years ago. But you did not achieve a consensus at >> that time and no fixes were made after all. > > I don't recall that. Do you have a pointer to the email thread in the > archives? https://lkml.org/lkml/2017/8/16/345 - this is the top message of that thread. Evgeny >> Anyway, one can consider both issues independently on the one fixed by >> the patch. > > Yes. I'll write and submit a series of patches. > > Alan Stern
Re: [PATCH] usb: gadget: net2280: fix memory leak on probe error handling paths
Hi Alan,
I have neither an appropriate hardware nor an experience to deal with issues
that you mentioned. Our framework does not allow to detect them as well at the
moment. At last, it seems that rather many drivers can suffer from these
issues. So, it would be much better if somebody else will suggest necessary
fixes and test them carefully.
BTW, you have already discussed the race within net2280_remove() with my
colleague about 3 years ago. But you did not achieve a consensus at that time
and no fixes were made after all.
Anyway, one can consider both issues independently on the one fixed by the
patch.
--
Evgeny Novikov
Linux Verification Center, ISP RAS
http://linuxtesting.org
22.07.2020, 17:17, "Alan Stern" :
> On Tue, Jul 21, 2020 at 11:15:58PM +0300, Evgeny Novikov wrote:
>> Driver does not release memory for device on error handling paths in
>> net2280_probe() when gadget_release() is not registered yet.
>>
>> The patch fixes the bug like in other similar drivers.
>>
>> Found by Linux Driver Verification project (linuxtesting.org).
>>
>> Signed-off-by: Evgeny Novikov
>> ---
>> drivers/usb/gadget/udc/net2280.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/gadget/udc/net2280.c
>> b/drivers/usb/gadget/udc/net2280.c
>> index 5eff85eeaa5a..d5fe071b2db2 100644
>> --- a/drivers/usb/gadget/udc/net2280.c
>> +++ b/drivers/usb/gadget/udc/net2280.c
>> @@ -3781,8 +3781,10 @@ static int net2280_probe(struct pci_dev *pdev, const
>> struct pci_device_id *id)
>> return 0;
>>
>> done:
>> - if (dev)
>> + if (dev) {
>> net2280_remove(pdev);
>> + kfree(dev);
>> + }
>> return retval;
>> }
>
> This patch seems to be the tip of an iceberg. Following through its
> implications led to a couple of discoveries.
>
> usb_del_gadget_udc() calls device_unregister(>dev). Once this
> call returns, gadget has to be regarded as a stale pointer. But the
> very next line of code does:
>
> memset(>dev, 0x00, sizeof(gadget->dev));
>
> for no apparent reason. I'm amazed this hasn't caused problems already.
> Is there any justification for keeping this memset? It's hard to
> imagine that it does any good.
>
> Similarly, net2280_remove() calls usb_del_gadget_udc(>gadget) at
> its start, and so dev must be a stale pointer for the entire remainder
> of the routine. But it gets used repeatedly. Surely we ought to have
> a device_get() and device_put() in there.
>
> Alan Stern
[PATCH] usb: gadget: net2280: fix memory leak on probe error handling paths
Driver does not release memory for device on error handling paths in
net2280_probe() when gadget_release() is not registered yet.
The patch fixes the bug like in other similar drivers.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov
---
drivers/usb/gadget/udc/net2280.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/net2280.c b/drivers/usb/gadget/udc/net2280.c
index 5eff85eeaa5a..d5fe071b2db2 100644
--- a/drivers/usb/gadget/udc/net2280.c
+++ b/drivers/usb/gadget/udc/net2280.c
@@ -3781,8 +3781,10 @@ static int net2280_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
return 0;
done:
- if (dev)
+ if (dev) {
net2280_remove(pdev);
+ kfree(dev);
+ }
return retval;
}
--
2.16.4
Re: [PATCH] media: isif: reset global state
Hi Lad,
I will try to answer your question below.
17.07.2020, 12:55, "Lad, Prabhakar" :
> HI Evgeny,
>
> Thank you for the patch.
>
> On Tue, Jul 14, 2020 at 6:20 PM Evgeny Novikov wrote:
>> isif_probe() invokes iounmap() on error handling paths, but it does not
>> reset the global state. So, later it can invoke iounmap() even when
>> ioremap() fails. This is the case also for isif_remove(). The patch
>> resets the global state after invoking iounmap() to avoid this.
>>
>> Found by Linux Driver Verification project (linuxtesting.org).
>>
>> Signed-off-by: Evgeny Novikov
>> ---
>> drivers/media/platform/davinci/isif.c | 11 +--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/platform/davinci/isif.c
>> b/drivers/media/platform/davinci/isif.c
>> index c98edb67cfb2..c53cecd072b1 100644
>> --- a/drivers/media/platform/davinci/isif.c
>> +++ b/drivers/media/platform/davinci/isif.c
>> @@ -1075,10 +1075,14 @@ static int isif_probe(struct platform_device *pdev)
>> release_mem_region(res->start, resource_size(res));
>> i--;
>> fail_nobase_res:
>> - if (isif_cfg.base_addr)
>> + if (isif_cfg.base_addr) {
>> iounmap(isif_cfg.base_addr);
>> - if (isif_cfg.linear_tbl0_addr)
>> + isif_cfg.base_addr = NULL;
>> + }
>> + if (isif_cfg.linear_tbl0_addr) {
>> iounmap(isif_cfg.linear_tbl0_addr);
>> + isif_cfg.linear_tbl0_addr = NULL;
>> + }
>
> As the probe itself is failing I don't see a benefit in setting the
> pointers to NULL. Unless I'm missing something.
Unfortunately, I can not provide you easily with a nice visualization of a
corresponding error trace, but I will try to explain it in a text form. Our
environment model for device drivers infinitely invokes their probe and remove
callbacks. In particular, when probe fails, it does not invoke remove, but it
can call probe again.
Before the fix the global state (isif_cfg.base_addr and
isif_cfg.linear_tbl0_addr) was not set to NULL when first probe fails. Assuming
some failures during the second invocation of probe, e.g. ioremap_nocache() can
fail, the driver proceeds to iounmap() because corresponding pointers are not
NULL. Of course, one can hardly imagine that this is possible in practice but
static analysis treats all possible paths.
Perhaps, our environment model is not accurate enough in this aspect. But our
tool does not report many similar warnings when we check thousands of drivers,
so, we can assume that everything is okay. If you have another opinion, I would
be glad to hear it.
--
Evgeny Novikov
Linux Verification Center, ISP RAS
http://linuxtesting.org
>
> Cheers,
> --Prabhakar
>
>> while (i >= 0) {
>> res = platform_get_resource(pdev, IORESOURCE_MEM, i);
>> @@ -1096,8 +1100,11 @@ static int isif_remove(struct platform_device *pdev)
>> int i = 0;
>>
>> iounmap(isif_cfg.base_addr);
>> + isif_cfg.base_addr = NULL;
>> iounmap(isif_cfg.linear_tbl0_addr);
>> + isif_cfg.linear_tbl0_addr = NULL;
>> iounmap(isif_cfg.linear_tbl1_addr);
>> + isif_cfg.linear_tbl1_addr = NULL;
>> while (i < 3) {
>> res = platform_get_resource(pdev, IORESOURCE_MEM, i);
>> if (res)
>> --
>> 2.16.4
hwmon: (xgene) missing iounmap() and memunmap()
xgene_hwmon_probe() invokes ioremap() and memremap() under certain assumptions, but the driver does not invoke iounmap() and memunmap() either on probe error handling paths or in xgene_hwmon_remove(). I assume a patch would be non-trivial while I have not a capability to test it well. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Evgeny Novikov
[PATCH] usb: gadget: net2272: skip BAR1 on error handling paths in probe
net2272_rdk1_probe() skips "i == 1" (BAR1) during allocation of
resources. The patch does this on error hanling paths as well.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov
---
drivers/usb/gadget/udc/net2272.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/gadget/udc/net2272.c b/drivers/usb/gadget/udc/net2272.c
index 928057b206f1..639631d44b00 100644
--- a/drivers/usb/gadget/udc/net2272.c
+++ b/drivers/usb/gadget/udc/net2272.c
@@ -2370,6 +2370,8 @@ net2272_rdk1_probe(struct pci_dev *pdev, struct net2272
*dev)
err:
while (--i >= 0) {
+ if (i == 1)
+ continue; /* BAR1 unused */
iounmap(mem_mapped_addr[i]);
release_mem_region(pci_resource_start(pdev, i),
pci_resource_len(pdev, i));
--
2.16.4
[PATCH] media: isif: reset global state
isif_probe() invokes iounmap() on error handling paths, but it does not
reset the global state. So, later it can invoke iounmap() even when
ioremap() fails. This is the case also for isif_remove(). The patch
resets the global state after invoking iounmap() to avoid this.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov
---
drivers/media/platform/davinci/isif.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/davinci/isif.c
b/drivers/media/platform/davinci/isif.c
index c98edb67cfb2..c53cecd072b1 100644
--- a/drivers/media/platform/davinci/isif.c
+++ b/drivers/media/platform/davinci/isif.c
@@ -1075,10 +1075,14 @@ static int isif_probe(struct platform_device *pdev)
release_mem_region(res->start, resource_size(res));
i--;
fail_nobase_res:
- if (isif_cfg.base_addr)
+ if (isif_cfg.base_addr) {
iounmap(isif_cfg.base_addr);
- if (isif_cfg.linear_tbl0_addr)
+ isif_cfg.base_addr = NULL;
+ }
+ if (isif_cfg.linear_tbl0_addr) {
iounmap(isif_cfg.linear_tbl0_addr);
+ isif_cfg.linear_tbl0_addr = NULL;
+ }
while (i >= 0) {
res = platform_get_resource(pdev, IORESOURCE_MEM, i);
@@ -1096,8 +1100,11 @@ static int isif_remove(struct platform_device *pdev)
int i = 0;
iounmap(isif_cfg.base_addr);
+ isif_cfg.base_addr = NULL;
iounmap(isif_cfg.linear_tbl0_addr);
+ isif_cfg.linear_tbl0_addr = NULL;
iounmap(isif_cfg.linear_tbl1_addr);
+ isif_cfg.linear_tbl1_addr = NULL;
while (i < 3) {
res = platform_get_resource(pdev, IORESOURCE_MEM, i);
if (res)
--
2.16.4
[PATCH] fbdev: sm712fb: handle ioremap() errors in probe
smtcfb_pci_probe() does not handle ioremap() errors for case 0x720. The
patch fixes that exactly like for case 0x710/2.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov
---
drivers/video/fbdev/sm712fb.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/video/fbdev/sm712fb.c b/drivers/video/fbdev/sm712fb.c
index 6a1b4a853d9e..0171b23fa211 100644
--- a/drivers/video/fbdev/sm712fb.c
+++ b/drivers/video/fbdev/sm712fb.c
@@ -1602,6 +1602,14 @@ static int smtcfb_pci_probe(struct pci_dev *pdev,
sfb->fb->fix.mmio_start = mmio_base;
sfb->fb->fix.mmio_len = 0x0020;
sfb->dp_regs = ioremap(mmio_base, 0x0020 + smem_size);
+ if (!sfb->dp_regs) {
+ dev_err(>dev,
+ "%s: unable to map memory mapped IO!\n",
+ sfb->fb->fix.id);
+ err = -ENOMEM;
+ goto failed_fb;
+ }
+
sfb->lfb = sfb->dp_regs + 0x0020;
sfb->mmio = (smtc_regbaseaddress =
sfb->dp_regs + 0x000c);
--
2.16.4
[PATCH] media: vpss: clean up resources in init
If platform_driver_register() fails within vpss_init() resources are not
cleaned up. The patch fixes this issue by introducing the corresponding
error handling.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov
---
drivers/media/platform/davinci/vpss.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/davinci/vpss.c
b/drivers/media/platform/davinci/vpss.c
index d38d2bbb6f0f..7000f0bf0b35 100644
--- a/drivers/media/platform/davinci/vpss.c
+++ b/drivers/media/platform/davinci/vpss.c
@@ -505,19 +505,31 @@ static void vpss_exit(void)
static int __init vpss_init(void)
{
+ int ret;
+
if (!request_mem_region(VPSS_CLK_CTRL, 4, "vpss_clock_control"))
return -EBUSY;
oper_cfg.vpss_regs_base2 = ioremap(VPSS_CLK_CTRL, 4);
if (unlikely(!oper_cfg.vpss_regs_base2)) {
- release_mem_region(VPSS_CLK_CTRL, 4);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto err_ioremap;
}
writel(VPSS_CLK_CTRL_VENCCLKEN |
-VPSS_CLK_CTRL_DACCLKEN, oper_cfg.vpss_regs_base2);
+ VPSS_CLK_CTRL_DACCLKEN, oper_cfg.vpss_regs_base2);
+
+ ret = platform_driver_register(_driver);
+ if (ret)
+ goto err_pd_register;
+
+ return 0;
- return platform_driver_register(_driver);
+err_pd_register:
+ iounmap(oper_cfg.vpss_regs_base2);
+err_ioremap:
+ release_mem_region(VPSS_CLK_CTRL, 4);
+ return ret;
}
subsys_initcall(vpss_init);
module_exit(vpss_exit);
--
2.16.4
[PATCH] fbdev: sm712fb: set error code in probe
If smtcfb_pci_probe() does not detect a valid chip it cleans up everything and returns 0. This can result in various bad things later. The patch sets the error code on the corresponding path. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Evgeny Novikov --- drivers/video/fbdev/sm712fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/sm712fb.c b/drivers/video/fbdev/sm712fb.c index 6a1b4a853d9e..fbe97340b8e0 100644 --- a/drivers/video/fbdev/sm712fb.c +++ b/drivers/video/fbdev/sm712fb.c @@ -1614,7 +1614,7 @@ static int smtcfb_pci_probe(struct pci_dev *pdev, default: dev_err(>dev, "No valid Silicon Motion display chip was detected!\n"); - + err = -ENODEV; goto failed_fb; } -- 2.16.4
[PATCH] hwmon: (aspeed-pwm-tacho) Avoid possible buffer overflow
aspeed_create_fan() reads a pwm_port value using of_property_read_u32(). If pwm_port will be more than ARRAY_SIZE(pwm_port_params), there will be a buffer overflow in aspeed_create_pwm_port()->aspeed_set_pwm_port_enable(). The patch fixes the potential buffer overflow. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Evgeny Novikov --- drivers/hwmon/aspeed-pwm-tacho.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/hwmon/aspeed-pwm-tacho.c b/drivers/hwmon/aspeed-pwm-tacho.c index 33fb54845bf6..3d8239fd66ed 100644 --- a/drivers/hwmon/aspeed-pwm-tacho.c +++ b/drivers/hwmon/aspeed-pwm-tacho.c @@ -851,6 +851,8 @@ static int aspeed_create_fan(struct device *dev, ret = of_property_read_u32(child, "reg", _port); if (ret) return ret; + if (pwm_port >= ARRAY_SIZE(pwm_port_params)) + return -EINVAL; aspeed_create_pwm_port(priv, (u8)pwm_port); ret = of_property_count_u8_elems(child, "cooling-levels"); -- 2.16.4
[PATCH] fbdev: da8xx-fb: go to proper label on error handling paths in probe
fb_probe() can successfully allocate a new frame buffer, but then fail
to perform some operations with regulator. In these cases fb_probe()
goes to label err_pm_runtime_disable where the frame buffer is not
released. The patch makes fb_probe() to go to label err_release_fb on
corresponding error handling paths.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov
---
drivers/video/fbdev/da8xx-fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/da8xx-fb.c b/drivers/video/fbdev/da8xx-fb.c
index 73c3c4c8cc12..e38c0e3f9c61 100644
--- a/drivers/video/fbdev/da8xx-fb.c
+++ b/drivers/video/fbdev/da8xx-fb.c
@@ -1402,14 +1402,14 @@ static int fb_probe(struct platform_device *device)
if (IS_ERR(par->lcd_supply)) {
if (PTR_ERR(par->lcd_supply) == -EPROBE_DEFER) {
ret = -EPROBE_DEFER;
- goto err_pm_runtime_disable;
+ goto err_release_fb;
}
par->lcd_supply = NULL;
} else {
ret = regulator_enable(par->lcd_supply);
if (ret)
- goto err_pm_runtime_disable;
+ goto err_release_fb;
}
fb_videomode_to_var(_fb_var, lcdc_info);
--
2.16.4
[PATCH] video: fbdev: neofb: fix memory leak in neo_scan_monitor()
neofb_probe() calls neo_scan_monitor() that can successfully allocate a memory for info->monspecs.modedb and proceed to case 0x03. There it does not free the memory and returns -1. neofb_probe() goes to label err_scan_monitor, thus, it does not free this memory through calling fb_destroy_modedb() as well. We can not go to label err_init_hw since neo_scan_monitor() can fail during memory allocation. So, the patch frees the memory directly for case 0x03. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Evgeny Novikov --- drivers/video/fbdev/neofb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/fbdev/neofb.c b/drivers/video/fbdev/neofb.c index f5a676bfd67a..09a20d4ab35f 100644 --- a/drivers/video/fbdev/neofb.c +++ b/drivers/video/fbdev/neofb.c @@ -1819,6 +1819,7 @@ static int neo_scan_monitor(struct fb_info *info) #else printk(KERN_ERR "neofb: Only 640x480, 800x600/480 and 1024x768 panels are currently supported\n"); + kfree(info->monspecs.modedb); return -1; #endif default: -- 2.16.4
[PATCH] usb: gadget: udc: gr_udc: fix memleak on error handling path in gr_ep_init()
gr_ep_init() does not assign the allocated request anywhere if allocation
of memory for the buffer fails. This is a memory leak fixed by the given
patch.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov
---
drivers/usb/gadget/udc/gr_udc.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/udc/gr_udc.c b/drivers/usb/gadget/udc/gr_udc.c
index 7164ad9800f1..7419889ebe9a 100644
--- a/drivers/usb/gadget/udc/gr_udc.c
+++ b/drivers/usb/gadget/udc/gr_udc.c
@@ -1980,9 +1980,12 @@ static int gr_ep_init(struct gr_udc *dev, int num, int
is_in, u32 maxplimit)
if (num == 0) {
_req = gr_alloc_request(>ep, GFP_ATOMIC);
+ if (!_req)
+ return -ENOMEM;
+
buf = devm_kzalloc(dev->dev, PAGE_SIZE, GFP_DMA | GFP_ATOMIC);
- if (!_req || !buf) {
- /* possible _req freed by gr_probe via gr_remove */
+ if (!buf) {
+ gr_free_request(>ep, _req);
return -ENOMEM;
}
--
2.16.4
[PATCH] staging: rts5208: fix memleaks on error handling paths in probe
rtsx_probe() allocates host, but does not free it on error handling paths. The patch adds missed scsi_host_put(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Evgeny Novikov --- drivers/staging/rts5208/rtsx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/rts5208/rtsx.c b/drivers/staging/rts5208/rtsx.c index be0053c795b7..937f4e732a75 100644 --- a/drivers/staging/rts5208/rtsx.c +++ b/drivers/staging/rts5208/rtsx.c @@ -972,6 +972,7 @@ static int rtsx_probe(struct pci_dev *pci, kfree(dev->chip); chip_alloc_fail: dev_err(>dev, "%s failed\n", __func__); + scsi_host_put(host); scsi_host_alloc_fail: pci_release_regions(pci); return err; -- 2.16.4
[PATCH] staging: kpc2000: kpc_dma: set error code in probe
If device_create() fails during probing the device, kpc_dma_probe() does
not set the error code and returns 0. This can result in various bad
issues later. The patch sets the error code on the corresponding error
handling path.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov
---
drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c
b/drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c
index c3b30551e0ca..624d47bae4d1 100644
--- a/drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c
+++ b/drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c
@@ -140,6 +140,7 @@ int kpc_dma_probe(struct platform_device *pldev)
dev = MKDEV(assigned_major_num, pldev->id);
ldev->kpc_dma_dev = device_create(kpc_dma_class, >dev, dev,
ldev, "kpc_dma%d", pldev->id);
if (IS_ERR(ldev->kpc_dma_dev)) {
+ rv = PTR_ERR(ldev->kpc_dma_dev);
dev_err(>pldev->dev, "%s: device_create failed: %d\n",
__func__, rv);
goto err_kfree;
}
--
2.16.4
[PATCH] video: fbdev: savage: fix memory leak on error handling path in probe
savagefb_probe() calls savage_init_fb_info() that can successfully allocate memory for info->pixmap.addr but then fail when fb_alloc_cmap() fails. savagefb_probe() goes to label failed_init and does not free allocated memory. It is not valid to go to label failed_mmio since savage_init_fb_info() can fail during memory allocation as well. So, the patch free allocated memory on the error handling path in savage_init_fb_info() itself. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Evgeny Novikov --- drivers/video/fbdev/savage/savagefb_driver.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/fbdev/savage/savagefb_driver.c b/drivers/video/fbdev/savage/savagefb_driver.c index 3c8ae87f0ea7..3fd87aeb6c79 100644 --- a/drivers/video/fbdev/savage/savagefb_driver.c +++ b/drivers/video/fbdev/savage/savagefb_driver.c @@ -2157,6 +2157,8 @@ static int savage_init_fb_info(struct fb_info *info, struct pci_dev *dev, info->flags |= FBINFO_HWACCEL_COPYAREA | FBINFO_HWACCEL_FILLRECT | FBINFO_HWACCEL_IMAGEBLIT; + else + kfree(info->pixmap.addr); } #endif return err; -- 2.16.4
[PATCH] media: rc: return proper error code on error handling path in init
If lirc_dev_init() fails during module initialization, rc_core_init()
returns 0 denoting success. This can cause different issues during
further operation of the module. The patch fixes the return value of
rc_core_init() on the corresponding error handling path.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov
---
drivers/media/rc/rc-main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index d7064d664d52..7b53066d9d07 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -2052,7 +2052,7 @@ static int __init rc_core_init(void)
if (rc) {
pr_err("rc_core: unable to init lirc\n");
class_unregister(_class);
- return 0;
+ return rc;
}
led_trigger_register_simple("rc-feedback", _feedback);
--
2.16.4
