lkml.org 
[lkml]   [2015]   [Dec]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] cx231xx: correctly handling failed allocation
From
On Tue, Dec 29, 2015 at 1:53 PM, Insu Yun <wuninsu@gmail.com> wrote:
> Since kmalloc can be failed in memory pressure,
> if not properly handled, NULL dereference can be happend
>
> Signed-off-by: Insu Yun <wuninsu@gmail.com>
> ---
> drivers/media/usb/cx231xx/cx231xx-417.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/usb/cx231xx/cx231xx-417.c b/drivers/media/usb/cx231xx/cx231xx-417.c
> index 47a98a2..9725e4f 100644
> --- a/drivers/media/usb/cx231xx/cx231xx-417.c
> +++ b/drivers/media/usb/cx231xx/cx231xx-417.c
> @@ -1382,6 +1382,8 @@ static int cx231xx_bulk_copy(struct cx231xx *dev, struct urb *urb)
> buffer_size = urb->actual_length;
>
> buffer = kmalloc(buffer_size, GFP_ATOMIC);
> + if (!buffer)
> + return -ENOMEM;

A kmalloc() call inside a bulk handler running in softirq context?
That doesn't look right.

That said, I don't have any specific objection to the patch (which I'm
assuming came from some automated tool), but I suspect the cx231xx-417
code is probably completely broken. The only device I've ever seen
that has the cx23102 and cx23417 is one of the Polaris EVKs, which
AFAIK nobody has ever shipped a production design based on.

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com


\
 
 \ /
  Last update: 2015-12-29 20:21    [W:0.028 / U:1.840 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site