All of lore.kernel.org
 help / color / mirror / Atom feed
From: fengguang.wu@intel.com (Fengguang Wu)
To: linux-arm-kernel@lists.infradead.org
Subject: drivers/staging/ced1401/ced_ioc.c:918 GetTransfer() error: potential null dereference 'tx'.  (kzalloc returns null)
Date: Wed, 7 Nov 2012 18:05:25 +0800	[thread overview]
Message-ID: <20121107100525.GA31190@localhost> (raw)
In-Reply-To: <509a31bd.DqNZ+8tDIvryTj7L%yuanhan.liu@linux.intel.com>

Hi Arnd,

FYI, there are new smatch warnings show up in

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git testing/defconfig-warnings
head:   ee68ab14f293996cc746aeb016fd2c124e2914f0
commit: 47b83e2bd41f9cc656b7b933cefec484f4d12026 Fix potential stack overflow locations
date:   2 hours ago

  drivers/staging/ced1401/ced_ioc.c:875 WaitEvent() warn: inconsistent returns mutex:&pdx->io_mutex: locked (853) unlocked (841,875)
+ drivers/staging/ced1401/ced_ioc.c:918 GetTransfer() error: potential null dereference 'tx'.  (kzalloc returns null)
  drivers/staging/ced1401/ced_ioc.c:1079 CheckSelfTest() warn: check that 'gst.code' doesn't leak information
  drivers/staging/ced1401/ced_ioc.c:1515 FreeCircBlock() warn: inconsistent returns mutex:&pdx->io_mutex: locked (1512) unlocked (1424,1515)
--
  drivers/staging/wlan-ng/hfa384x_usb.c:3517 hfa384x_usbin_rx() error: potential NULL dereference 'rxmeta'.
  drivers/staging/wlan-ng/prism2fw.c:594 mkpdrlist() error: buffer overflow 'pda16' 512 <= 512
  drivers/staging/wlan-ng/prism2fw.c:635 mkpdrlist() error: buffer overflow 'pda16' 512 <= 512
+ drivers/staging/wlan-ng/prism2fw.c:773 read_cardpda() error: potential null dereference 'msg'.  (kmalloc returns null)
--
  drivers/misc/lkdtm.c:268 recursive_loop() warn: 'buf' puts 512 bytes on stack
+ drivers/misc/lkdtm.c:270 recursive_loop() error: __builtin_memset() 'buf' too small (512 vs 1024)
  drivers/misc/lkdtm.c:301 lkdtm_do_action() error: buffer overflow 'p' 8 <= 12
  drivers/misc/lkdtm.c:320 lkdtm_do_action() error: potential null dereference 'data'.  (kmalloc returns null)
  drivers/misc/lkdtm.c:320 lkdtm_do_action() error: buffer overflow 'data' 255 <= 256

vim +918 +/tx drivers/staging/ced1401/ced_ioc.c

2eae6bdc Alois Schl?gl      2012-09-17  902  ** GetTransferInfo
2eae6bdc Alois Schl?gl      2012-09-17  903  ** Puts the current state of the 1401 in a TGET_TX_BLOCK.
2eae6bdc Alois Schl?gl      2012-09-17  904  *****************************************************************************/
cd915200 Greg Kroah-Hartman 2012-09-17  905  int GetTransfer(DEVICE_EXTENSION * pdx, TGET_TX_BLOCK __user * pTX)
2eae6bdc Alois Schl?gl      2012-09-17  906  {
cd915200 Greg Kroah-Hartman 2012-09-17  907  	int iReturn = U14ERR_NOERROR;
cd915200 Greg Kroah-Hartman 2012-09-17  908  	unsigned int dwIdent;
cd915200 Greg Kroah-Hartman 2012-09-17  909  
cd915200 Greg Kroah-Hartman 2012-09-17  910  	mutex_lock(&pdx->io_mutex);
cd915200 Greg Kroah-Hartman 2012-09-17  911  	dwIdent = pdx->StagedId;	// area ident for last xfer
cd915200 Greg Kroah-Hartman 2012-09-17  912  	if (dwIdent >= MAX_TRANSAREAS)
cd915200 Greg Kroah-Hartman 2012-09-17  913  		iReturn = U14ERR_BADAREA;
cd915200 Greg Kroah-Hartman 2012-09-17  914  	else {
cd915200 Greg Kroah-Hartman 2012-09-17  915  		// Return the best information we have - we don't have physical addresses
47b83e2b Arnd Bergmann      2012-10-16  916  		TGET_TX_BLOCK *tx;
47b83e2b Arnd Bergmann      2012-10-16  917  		tx = kzalloc(sizeof *tx, GFP_KERNEL);
47b83e2b Arnd Bergmann      2012-10-16 @918  		tx->size = pdx->rTransDef[dwIdent].dwLength;
47b83e2b Arnd Bergmann      2012-10-16  919  		tx->linear = (long long)((long)pdx->rTransDef[dwIdent].lpvBuff);
47b83e2b Arnd Bergmann      2012-10-16  920  		tx->avail = GET_TX_MAXENTRIES;	// how many blocks we could return
47b83e2b Arnd Bergmann      2012-10-16  921  		tx->used = 1;	// number we actually return
47b83e2b Arnd Bergmann      2012-10-16  922  		tx->entries[0].physical =
47b83e2b Arnd Bergmann      2012-10-16  923  		   (long long)(tx->linear + pdx->StagedOffset);
47b83e2b Arnd Bergmann      2012-10-16  924  		tx->entries[0].size = tx->size;
47b83e2b Arnd Bergmann      2012-10-16  925  
47b83e2b Arnd Bergmann      2012-10-16  926  		if (copy_to_user(pTX, tx, sizeof(*tx)))

---
0-DAY kernel build testing backend         Open Source Technology Center
Fengguang Wu, Yuanhan Liu                              Intel Corporation

       reply	other threads:[~2012-11-07 10:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <509a31bd.DqNZ+8tDIvryTj7L%yuanhan.liu@linux.intel.com>
2012-11-07 10:05 ` Fengguang Wu [this message]
2012-11-07 14:05   ` drivers/staging/ced1401/ced_ioc.c:918 GetTransfer() error: potential null dereference 'tx'. (kzalloc returns null) Arnd Bergmann

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=20121107100525.GA31190@localhost \
    --to=fengguang.wu@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.