public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Nicholas Mc Guire <hofrat@osadl.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	devel@driverdev.osuosl.org,
	Nathan Chancellor <natechancellor@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: r8822be: check kzalloc return or bail
Date: Fri, 15 Feb 2019 15:57:00 +0300	[thread overview]
Message-ID: <20190215125659.GI2326@kadam> (raw)
In-Reply-To: <1550222662-32124-1-git-send-email-hofrat@osadl.org>

On Fri, Feb 15, 2019 at 10:24:22AM +0100, Nicholas Mc Guire wrote:
> The kzalloc() in halmac_parse_psd_data_88xx() can fail and return NULL
> so check the psd_set->data after allocation and if allocation failed
> return HALMAC_CMD_PROCESS_ERROR.
> 
> Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
> Fixes: 938a0447f094 ("staging: r8822be: Add code for halmac sub-drive")
> ---
> 
> Problem was located with an experimental coccinelle script
> 
> Patch was compile tested with: x86_64_defconfig + STAGING=y,
> R8822BE=m
> (with a smatch error that looks like a false-positive
> 
>   CHECK   drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c
> drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c:624 halmac_func_write_logical_efuse_88xx() error: uninitialized symbol 'pg_efuse_header2'.
>   CC [M]  drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.o
> 
> as the initialization of pg_efuse_header2 is under the same if condition (line 592) as the
> use at line 624 it is initialized)
>

Hm...  That's tricky code for Smatch to parse.

drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c
   592                  if (offset > 0x7f) {
   593                          pg_efuse_header =
   594                                  (((pg_block & 0x07) << 5) & 0xE0) | 0x0F;
   595                          pg_efuse_header2 =
                                ^^^^^^^^^^^^^^^^^^
pg_efuse_header2 is only intialized on this path.

   596                                  (u8)(((pg_block & 0x78) << 1) +
   597                                       ((0x1 << pg_block_index) ^ 0x0F));
   598                  } else {
   599                          pg_efuse_header =
   600                                  (u8)((pg_block << 4) +
   601                                       ((0x01 << pg_block_index) ^ 0x0F));
   602                  }
   603  
   604                  if ((offset & 1) == 0) {
                            ^^^^^^^^^^^^^^^^^
But this condition confuses Smatch.  Smatch marks it as saying that
offset is non-zero on this size.

   605                          pg_efuse_byte1 = value;
   606                          pg_efuse_byte2 = *(eeprom_map + offset + 1);
   607                  } else {

And this side offset = 0-0x7e.

   608                          pg_efuse_byte1 = *(eeprom_map + offset - 1);
   609                          pg_efuse_byte2 = value;
   610                  }
   611  
   612                  if (offset > 0x7f) {
                            ^^^^^^^^^^^^^
So it doesn't parse this condition correctly.

   613                          pg_efuse_num = 4;
   614                          if (halmac_adapter->hw_config_info.efuse_size <=
   615                              (pg_efuse_num + HALMAC_PROTECTED_EFUSE_SIZE_88XX +
   616                               halmac_adapter->efuse_end)) {
   617                                  kfree(eeprom_map);
   618                                  return HALMAC_RET_EFUSE_NOT_ENOUGH;
   619                          }
   620                          halmac_func_write_efuse_88xx(halmac_adapter, efuse_end,
   621                                                       pg_efuse_header);
   622                          halmac_func_write_efuse_88xx(halmac_adapter,
   623                                                       efuse_end + 1,
   624                                                       pg_efuse_header2);
                                                             ^^^^^^^^^^^^^^^^
And it warns here.

   625                          halmac_func_write_efuse_88xx(
   626                                  halmac_adapter, efuse_end + 2, pg_efuse_byte1);
   627                          status = halmac_func_write_efuse_88xx(
   628                                  halmac_adapter, efuse_end + 3, pg_efuse_byte2);


It should be possible to fix this false positive...  It's just a matter
of doing the work.

regards,
dan carpenter

      reply	other threads:[~2019-02-15 12:57 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-15  9:24 [PATCH] staging: r8822be: check kzalloc return or bail Nicholas Mc Guire
2019-02-15 12:57 ` Dan Carpenter [this message]

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=20190215125659.GI2326@kadam \
    --to=dan.carpenter@oracle.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hofrat@osadl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=natechancellor@gmail.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