All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: "Narasimman, Sathish" <sathish.narasimman@intel.com>
Cc: Marcel Holtmann <marcel@holtmann.org>,
	"Tumkur Narayan, Chethan" <chethan.tumkur.narayan@intel.com>,
	lkp <lkp@intel.com>, "Bag, Amit K" <amit.k.bag@intel.com>,
	Hsin-Yu Chao <hychao@chromium.org>,
	"Hedberg, Johan" <johan.hedberg@intel.com>,
	"Gustavo A. R. Silva" <gustavo@embeddedor.com>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>
Subject: Re: Coverity: btusb_work(): Null pointer dereferences
Date: Tue, 7 Apr 2020 11:14:09 -0700	[thread overview]
Message-ID: <202004071113.0643A29@keescook> (raw)
In-Reply-To: <DM6PR11MB2715D200FA424448E05B64D494C30@DM6PR11MB2715.namprd11.prod.outlook.com>

On Tue, Apr 07, 2020 at 10:54:22AM +0000, Narasimman, Sathish wrote:
> Hi
> 
> I think this is False Positive.
> 
> In the function btusb_probe the memory allocation is happened and verified for NULL.
> I don't this so checking for NULL evey time is required.
> 
> Sample code snip
> 
> In function "btusb_probe"
> {
>         data = devm_kzalloc(&intf->dev, sizeof(*data), GFP_KERNEL);
>         if (!data)
>                 return -ENOMEM;
> ....
>        INIT_WORK(&data->work, btusb_work);
> 
> }

This warning is talking about data->isoc, which is checked for NULL in
other places before the call to btusb_find_altsetting(), which doesn't
check for NULL.

-Kees

> 
> 
> Regards
> Sathish N
> 
> -----Original Message-----
> From: coverity-bot <keescook@chromium.org> 
> Sent: Monday, April 6, 2020 9:20 PM
> To: Narasimman, Sathish <sathish.narasimman@intel.com>
> Cc: Marcel Holtmann <marcel@holtmann.org>; Tumkur Narayan, Chethan <chethan.tumkur.narayan@intel.com>; lkp <lkp@intel.com>; Bag, Amit K <amit.k.bag@intel.com>; Hsin-Yu Chao <hychao@chromium.org>; Hedberg, Johan <johan.hedberg@intel.com>; Gustavo A. R. Silva <gustavo@embeddedor.com>; linux-next@vger.kernel.org
> Subject: Coverity: btusb_work(): Null pointer dereferences
> 
> Hello!
> 
> This is an experimental automated report about issues detected by Coverity from a scan of next-20200406 as part of the linux-next weekly scan project:
> https://scan.coverity.com/projects/linux-next-weekly-scan
> 
> You're getting this email because you were associated with the identified lines of code (noted below) that were touched by recent commits:
> 
> baac6276c0a9 ("Bluetooth: btusb: handle mSBC audio over USB Endpoints")
> 
> Coverity reported the following:
> 
> *** CID 1492498:  Null pointer dereferences  (FORWARD_NULL)
> /drivers/bluetooth/btusb.c: 1665 in btusb_work()
> 1659     			}
> 1660     		} else if (data->air_mode == HCI_NOTIFY_ENABLE_SCO_TRANSP) {
> 1661
> 1662     			data->usb_alt6_packet_flow = true;
> 1663
> 1664     			/* Check if Alt 6 is supported for Transparent audio */
> vvv     CID 1492498:  Null pointer dereferences  (FORWARD_NULL)
> vvv     Passing "data" to "btusb_find_altsetting", which dereferences null "data->isoc".
> 1665     			if (btusb_find_altsetting(data, 6))
> 1666     				new_alts = 6;
> 1667     			else
> 1668     				bt_dev_err(hdev, "Device does not support ALT setting 6");
> 1669     		}
> 1670
> 
> If this is a false positive, please let us know so we can mark it as such, or teach the Coverity rules to be smarter. If not, please make sure fixes get into linux-next. :) For patches fixing this, please include these lines (but double-check the "Fixes" first):
> 
> Reported-by: coverity-bot <keescook+coverity-bot@chromium.org>
> Addresses-Coverity-ID: 1492498 ("Null pointer dereferences")
> Fixes: baac6276c0a9 ("Bluetooth: btusb: handle mSBC audio over USB Endpoints")
> 
> 
> Thanks for your attention!
> 
> --
> Coverity-bot

-- 
Kees Cook

  reply	other threads:[~2020-04-07 18:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-06 15:49 Coverity: btusb_work(): Null pointer dereferences coverity-bot
2020-04-07 10:54 ` Narasimman, Sathish
2020-04-07 18:14   ` Kees Cook [this message]
2020-04-08  7:38     ` Narasimman, Sathish

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202004071113.0643A29@keescook \
    --to=keescook@chromium.org \
    --cc=amit.k.bag@intel.com \
    --cc=chethan.tumkur.narayan@intel.com \
    --cc=gustavo@embeddedor.com \
    --cc=hychao@chromium.org \
    --cc=johan.hedberg@intel.com \
    --cc=linux-next@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=marcel@holtmann.org \
    --cc=sathish.narasimman@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.