All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: lustre-devel@lists.lustre.org
Subject: [lustre-devel] [bug report] staging: add Lustre file system client support
Date: Wed, 23 Nov 2016 15:29:59 +0300	[thread overview]
Message-ID: <20161123122959.GA17323@mwanda> (raw)

Hi Lustre Devs,

The patch d7e09d0397e8: "staging: add Lustre file system client
support" from May 2, 2013, leads to the following static checker
warning:

	drivers/staging/lustre/lnet/selftest/console.c:1336 lstcon_test_add()
	error: 'paramlen' from user is not capped properly

The story here, is that "paramlen" is capped but only if "param" is
non-NULL.  This causes a problem.

drivers/staging/lustre/lnet/selftest/console.c
  1311  
  1312          LIBCFS_ALLOC(test, offsetof(struct lstcon_test, tes_param[paramlen]));

We don't know that paramlen is non-NULL here.  Because of integer
overflows we could end up allocating less than intended.

  1313          if (!test) {
  1314                  CERROR("Can't allocate test descriptor\n");
  1315                  rc = -ENOMEM;
  1316  
  1317                  goto out;
  1318          }
  1319  
  1320          test->tes_hdr.tsb_id = batch->bat_hdr.tsb_id;

Which will lead to memory corruption when we use "test".

  1321          test->tes_batch = batch;
  1322          test->tes_type = type;
  1323          test->tes_oneside = 0; /* TODO */
  1324          test->tes_loop = loop;
  1325          test->tes_concur = concur;
  1326          test->tes_stop_onerr = 1; /* TODO */
  1327          test->tes_span = span;
  1328          test->tes_dist = dist;
  1329          test->tes_cliidx = 0; /* just used for creating RPC */
  1330          test->tes_src_grp = src_grp;
  1331          test->tes_dst_grp = dst_grp;
  1332          INIT_LIST_HEAD(&test->tes_trans_list);
  1333  
  1334          if (param) {

Smatch is not smart enough to trace the implication that "'param' is
non-NULL, means that 'paramlen' has been verified" across a function
boundary.  Storing that sort of information would really increase the
hardware requirements for running Smatch so it's not something I have
planned currently.

  1335                  test->tes_paramlen = paramlen;
  1336                  memcpy(&test->tes_param[0], param, paramlen);
  1337          }
  1338  

regards,
dan carpenter

             reply	other threads:[~2016-11-23 12:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-23 12:29 Dan Carpenter [this message]
2016-12-05 23:43 ` [lustre-devel] [bug report] staging: add Lustre file system client support Oleg Drokin
2016-12-06 11:02   ` Dan Carpenter
2016-12-06 15:44     ` Oleg Drokin
2016-12-06 18:37       ` Dan Carpenter
2016-12-06 19:10         ` Oleg Drokin
2016-12-06 19:19           ` Dan Carpenter
2016-12-06 20:14           ` Greg KH

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=20161123122959.GA17323@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=lustre-devel@lists.lustre.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.