From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <smatch-owner@vger.kernel.org>
Received: from userp2130.oracle.com ([156.151.31.86]:51940 "EHLO
        userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1728508AbfFFOjo (ORCPT
        <rfc822;smatch@vger.kernel.org>); Thu, 6 Jun 2019 10:39:44 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc
 : subject : message-id : references : mime-version : content-type :
 in-reply-to; s=corp-2018-07-02;
 bh=mWFkrERf1M1UEmRBZsdHKVRLJSZtAP2MTkkT3ELsx2A=;
 b=tsTcJzjgCnT53BrHT4ECdzp8ajB29JHEExKedOzFjaJPrh/Gckj2EicGWOzNLq2Z90R9
 xm81/F46Epvl98Je6k5Q2A1DA6m8xGXlo612Bjn8Zjiy+mX+shCQ5p0hvCtWMe0447DA
 ja95Ln3L9dRHW5eAVumvBO12ZSNi6g00gXOj2Js58Mqyr7bCDy6QoVTiidVqLQtTOwvI
 xlWyg+wCiklIlbIGqHOy946W1zHNI3SzQqU34FBXd0SEmya5cSpj4x+xqa6baGpWOIeo
 ruIZlVuycL1RAoZ5m7XOmNn4IW9Vs9ZTLfHAfoJstpyMiOqRQNtN1modzR3IVLO0ADvU zQ== 
Date: Thu, 6 Jun 2019 17:39:31 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: Detecting user data on base types
Message-ID: <20190606143931.GB24680@kadam>
References: <20190529184722.GG709@e119886-lin.cambridge.arm.com>
 <20190529194933.GN24680@kadam>
 <20190530090329.GH709@e119886-lin.cambridge.arm.com>
 <20190530174642.GB31203@kadam>
 <20190605082926.GB23647@e119886-lin.cambridge.arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190605082926.GB23647@e119886-lin.cambridge.arm.com>
Sender: smatch-owner@vger.kernel.org
List-ID: <smatch.vger.kernel.org>
To: Andrew Murray <andrew.murray@arm.com>
Cc: smatch@vger.kernel.org

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