linux-kernel - Re: [PATCH] cx231xx: correctly handling failed allocation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAGoCfizkR_1hiayvfM2UVQYGpVGfMBJp5tveghRpphejSH+4gg@mail.gmail.com>
Date:	Tue, 29 Dec 2015 14:05:40 -0500
From:	Devin Heitmueller <dheitmueller@...nellabs.com>
To:	Insu Yun <wuninsu@...il.com>
Cc:	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	Hans Verkuil <hans.verkuil@...co.com>,
	Prabhakar Lad <prabhakar.csengg@...il.com>,
	scott.jiang.linux@...il.com,
	Linux Media Mailing List <linux-media@...r.kernel.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>, taesoo@...ech.edu,
	yeongjin.jang@...ech.edu, insu@...ech.edu, changwoo@...ech.edu
Subject: Re: [PATCH] cx231xx: correctly handling failed allocation

On Tue, Dec 29, 2015 at 1:53 PM, Insu Yun <wuninsu@...il.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@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/