DPDK patches and discussions
 help / color / mirror / Atom feed
From: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
To: John Mcnamara <john.mcnamara@intel.com>, dev@dpdk.org
Cc: Kumar Sanghvi <kumaras@chelsio.com>,
	Nirranjan Kirubaharan <nirranjan@chelsio.com>,
	Arjun V <arjun@chelsio.com>
Subject: Re: [dpdk-dev] DPDK Coverity issue 127559
Date: Tue, 19 Jul 2016 13:46:03 +0530	[thread overview]
Message-ID: <20160719081601.GA12140@chelsio.com> (raw)
In-Reply-To: <201607041529.u64FTntT009098@sivswdev02.ir.intel.com>

Hi all,

On Monday, July 07/04/16, 2016 at 08:29:49 -0700, john.mcnamara@intel.com wrote:
> Hi Rahul,
> 
> This is an automated email in relation to a new Coverity static code analysis
> issue in DPDK. Details of the issue are below.
> 
[...]

> Git commit data and Coverity defect information below.
> 
> Commit data
> ===========
> 
> Commit: net/cxgbe: support EEPROM access
> Id:     fe0bd9ee5da3fd52766458a5d0fa9a8728182be1
> Author: Rahul Lakkireddy
> Email:  rahul.lakkireddy@chelsio.com
> Date:   Fri May  6 08:43:18 2016 +0530
> 
> Defect information
> ==================
> 
> /drivers/net/cxgbe/cxgbe_ethdev.c: 919 in cxgbe_set_eeprom()
> *** CID 127559:    (TAINTED_SCALAR)
> 913     	}
> 914
> 915     	if (!err)
> 916     		err = t4_seeprom_wp(adapter, true);
> 917     out:
> 918     	if (buf != eeprom->data)
> >>>     CID 127559:    (TAINTED_SCALAR)
> >>>     Passing tainted variable "buf" to a tainted sink.
> 919     		rte_free(buf);
> 920     	return err;
> 921     }
> 922
> 923     static int cxgbe_get_regs_len(struct rte_eth_dev *eth_dev)
> 924     {
> /drivers/net/cxgbe/cxgbe_ethdev.c: 910 in cxgbe_set_eeprom()
> 904     	}
> 905
> 906     	err = t4_seeprom_wp(adapter, false);
> 907     	if (err)
> 908     		goto out;
> 909
> >>>     CID 127559:    (TAINTED_SCALAR)
> >>>     Assigning: "p" = "(u32 *)buf". Both are now tainted.
> 910     	for (p = (u32 *)buf; !err && aligned_len; aligned_len -= 4, p++) {
> 911     		err = eeprom_wr_phys(adapter, aligned_offset, *p);
> 912     		aligned_offset += 4;
> 913     	}
> 914
> 915     	if (!err)
> 

I'm not an expert in Coverity and am having trouble understanding what
the defect is and need some clarification.  Is it telling me that "buf"
is being used without doing lower and upper bounds check?

Thanks,
Rahul

       reply	other threads:[~2016-07-19  8:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <201607041529.u64FTntT009098@sivswdev02.ir.intel.com>
2016-07-19  8:16 ` Rahul Lakkireddy [this message]
2016-07-19  8:42   ` Mcnamara, John

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=20160719081601.GA12140@chelsio.com \
    --to=rahul.lakkireddy@chelsio.com \
    --cc=arjun@chelsio.com \
    --cc=dev@dpdk.org \
    --cc=john.mcnamara@intel.com \
    --cc=kumaras@chelsio.com \
    --cc=nirranjan@chelsio.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).