Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1157000 > unrolled thread

Re: [PATCH][V3] usb: isp1760: check for null return from kzalloc

Started byLaurent Pinchart <laurent.pinchart@ideasonboard.com>
First post2015-06-03 02:50 +0200
Last post2015-06-03 17:50 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH][V3] usb: isp1760: check for null return from kzalloc Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2015-06-03 02:50 +0200
    Re: [PATCH][V3] usb: isp1760: check for null return from kzalloc Felipe Balbi <balbi@ti.com> - 2015-06-03 17:50 +0200

#1157000 — Re: [PATCH][V3] usb: isp1760: check for null return from kzalloc

FromLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Date2015-06-03 02:50 +0200
SubjectRe: [PATCH][V3] usb: isp1760: check for null return from kzalloc
Message-ID<px52y-1bs-9@gated-at.bofh.it>
Hi Colin,

Thank you for the patch.

On Tuesday 02 June 2015 19:05:13 Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
> 
> isp1760_ep_alloc_request allocates a structure with kzalloc without checking
> for NULL and then returns a pointer to one of the structure fields. As the
> field happens to be the first in the structure the caller can properly
> check for NULL, but this is risky if the structure layout is changed later.
> Add an explicit NULL check for the kzalloc return value
> 
> Detected with smatch static analysis:
> 
> drivers/usb/isp1760/isp1760-udc.c:816 isp1760_ep_alloc_request()
>   error: potential null dereference 'req'.  (kzalloc returns null)
> 
> [ thanks to Laurent Pinchart for improved commit message ]
> 
> Signed-off-by: Colin Ian King <colin.king@canonical.com>

Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Felipe, I expect you to pick this up, please let me know if there's any issue.

> ---
>  drivers/usb/isp1760/isp1760-udc.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/isp1760/isp1760-udc.c
> b/drivers/usb/isp1760/isp1760-udc.c index 3fc4fe7..18ebf5b 100644
> --- a/drivers/usb/isp1760/isp1760-udc.c
> +++ b/drivers/usb/isp1760/isp1760-udc.c
> @@ -812,6 +812,8 @@ static struct usb_request
> *isp1760_ep_alloc_request(struct usb_ep *ep, struct isp1760_request *req;
> 
>  	req = kzalloc(sizeof(*req), gfp_flags);
> +	if (!req)
> +		return NULL;
> 
>  	return &req->req;
>  }

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1157791

FromFelipe Balbi <balbi@ti.com>
Date2015-06-03 17:50 +0200
Message-ID<pxj5w-5s8-21@gated-at.bofh.it>
In reply to#1157000

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Wed, Jun 03, 2015 at 03:43:23AM +0300, Laurent Pinchart wrote:
> > From: Colin Ian King <colin.king@canonical.com>
> > 
> > isp1760_ep_alloc_request allocates a structure with kzalloc without checking
> > for NULL and then returns a pointer to one of the structure fields. As the
> > field happens to be the first in the structure the caller can properly
> > check for NULL, but this is risky if the structure layout is changed later.
> > Add an explicit NULL check for the kzalloc return value
> > 
> > Detected with smatch static analysis:
> > 
> > drivers/usb/isp1760/isp1760-udc.c:816 isp1760_ep_alloc_request()
> >   error: potential null dereference 'req'.  (kzalloc returns null)
> > 
> > [ thanks to Laurent Pinchart for improved commit message ]
> > 
> > Signed-off-by: Colin Ian King <colin.king@canonical.com>
> 
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> 
> Felipe, I expect you to pick this up, please let me know if there's any issue.

once -rc1 is tagged, yes. My tree is already closed for v4.2.

-- 
balbi

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web