Re: Detecting user data on base types

On Thu, Jun 06, 2019 at 05:39:31PM +0300, Dan Carpenter wrote:
> 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.

Ah yes I understand this. Though really what I was referring to is:

funca(int __untagged x, int dontcare){
}

funcb(int __user y){
	funca(y, 0);
}

funcc(int z, int __user g){
	funca(z, g);
}

funcd(){
	funca(22, 0);
}

Without relying on parameter tracing, a calltree that has been filtered of
calls without USER_DATA will look this:

funca
 - funcb
 - funcc

We don't want the false positive of funcc being in this tree - it's here
because funcc calls funca with user data - its a parameter we don't care about.

However so long as we trace parameters (even if they are modified) through
the call tree, then it's possible to update the scripts to show a call stack
that is filtered for userdata for only parameters of interest.

Thanks,

Andrew Murray 

> 
> regards,
> dan carpenter