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
next parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox