All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Andrew Murray <andrew.murray@arm.com>
Cc: smatch@vger.kernel.org
Subject: Re: Detecting user data on base types
Date: Thu, 6 Jun 2019 17:39:31 +0300	[thread overview]
Message-ID: <20190606143931.GB24680@kadam> (raw)
In-Reply-To: <20190605082926.GB23647@e119886-lin.cambridge.arm.com>

On Wed, Jun 05, 2019 at 09:29:26AM +0100, Andrew Murray wrote:
> Through this discussion I'm able to detect when annotated function parameters contain
> user provided values. The challenge for me is to detect where that data originated
> from (i.e. following the parameter up the call tree) to ease debugging.
> 
> My first attempt didn't trace the parameters and just looked at the call tree for any
> functions which provided user data, however this resulted in false positives (e.g.
> just because a function higher up in the call stack passed user data, it doesn't mean
> it was this data that made it to the target function).

One of the main causes of this is function pointers that take a void
pointer argument.  For example, iblock_execute_sync_cache() takes a
user controlled "cmd" struct and says "bio->bi_private = cmd;"
Then in floppy_rb0_cb() we do:

	struct rb0_cbdata *cbdata = (struct rb0_cbdata *)bio->bi_private;

And smatch says that *cbdata is entirely user controlled...  The nice
fix for this would be if the mtag code were implimented and we could
tie function pointers to their data pointers very accurately.
Unfortunately, that's a pretty huge project and it's going to take a
while to complete.

A quicker fix is to add a line to smatch_data/db/fixup_kernel.sh

delete from caller_info where function = '(struct bio)->bi_end_io' and type = 8017;

which just deletes the user data from caller_info.

regards,
dan carpenter

  parent reply	other threads:[~2019-06-06 14:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-29 18:47 Detecting user data on base types Andrew Murray
2019-05-29 19:49 ` Dan Carpenter
2019-05-30  9:03   ` Andrew Murray
2019-05-30 17:46     ` Dan Carpenter
2019-06-05  8:29       ` Andrew Murray
2019-06-05 11:47         ` Andrew Murray
2019-06-05 12:28           ` Andrew Murray
2019-06-06 10:15             ` Dan Carpenter
2019-06-13 10:41               ` Andrew Murray
2019-06-06  9:40         ` Dan Carpenter
2019-06-13  9:15           ` Andrew Murray
2019-06-06 14:39         ` Dan Carpenter [this message]
2019-06-13 10:40           ` Andrew Murray

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=20190606143931.GB24680@kadam \
    --to=dan.carpenter@oracle.com \
    --cc=andrew.murray@arm.com \
    --cc=smatch@vger.kernel.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.