On Mon, Oct 23, 2023 at 01:45:28PM +0800, Dongliang Mu wrote:
> Hi Dan,
>
> I repeatedly read the mentionship program from you - Smatch: New ideas for
> Static Analysis[1]. There are some interesting ideas I would like to list as
> public projects in our club, e.g, Smatch on different C projects or Debian
> project, or any application of cross function database in Smatch.
Fantastic!
One thing that I do (with a former co-worker Harshit Mogalapalli) is
that we occasionally go through recent CVEs and look how these bugs
could be detected automatically.
Take commit b7c81f80246f ("firewire: fix potential uaf in
outbound_phy_packet_callback()") as an example. The queue_event() event
function has the following information in the database.
drivers/firewire/core-cdev.c | queue_event | 198 | |
MAYBE_FREED | 1 | $ | |
There are two reasons why Smatch did not detect this bug. First of
all it's a MAYBE_FREED instead of a freed. So that's simple to change:
--- a/check_free_strict.c
+++ b/check_free_strict.c
@@ -153,6 +153,8 @@ static int is_freed(struct expression *expr)
sm = get_sm_state_expr(my_id, expr);
if (sm && slist_has_state(sm->possible, &freed))
return 1;
+ if (sm && slist_has_state(sm->possible, &maybe_freed))
+ return 1;
return 0;
}
The second problem is that we are passing "&e->event" as the parameter
instead of "e". It's the same address, but it looks different.
queue_event(e->client, &e->event, &e->phy_packet, ...);
^^^^^^^^^
So I wrote a function to change "&e->event" into "e".
+static struct expression *remove_addr(struct expression *expr)
+{
+ struct expression *deref;
+ int offset;
+
+ if (expr->type != EXPR_PREOP ||
+ expr->op != '&')
+ return expr;
+
+ deref = strip_expr(expr->unop);
+ offset = get_member_offset_from_deref(deref);
+ if (offset != 0)
+ return expr;
+
+ deref = strip_expr(deref->deref);
+ if (deref->type != EXPR_PREOP ||
+ deref->op != '*')
+ return expr;
+
+ return strip_expr(deref->unop);
+}
+
Then it's easy to say: arg = remove_addr(strip_expr(arg));
After we make these two changes the bug is detected. It finds quite a
few bugs that way. The MAYBE_FREED changes generate quite a few false
positives so I haven't decided out how to deal with that yet...
But there is always something in the CVE list that gives an idea like
that.
>
> Since you are maintainers of Smatch, I think students can ask questions
> about Smatch in the smatch mailing list or our mailing to acquire help and
> mentionship.
Of course. Feel free.
>
> BTW, Smatch is written based on an old sparse version. Is it required to
> port sparse to newest version?
I'm not sure I understand this... The Sparse tree hasn't been updated
since June last year. I have tried to email them patches but no one
responded.
regards,
dan carpenter