[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <011c00e7-c351-4331-8be4-1c184d5773e1@kili.mountain>
Date: Mon, 17 Apr 2023 13:42:21 +0300
From: Dan Carpenter <error27@...il.com>
To: Dongliang Mu <dzm91@...t.edu.cn>, Vicki Pfau <vi@...rift.com>,
kernel-janitors@...r.kernel.org
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>,
Pavel Rojtberg <rojtberg@...il.com>,
Nate Yocom <nate@...om.org>,
Mattijs Korpershoek <mkorpershoek@...libre.com>,
John Butler <radon86dev@...il.com>,
Matthias Benkmann <matthias.benkmann@...il.com>,
Christopher Crockett <chaorace@...il.com>,
Santosh De Massari <s.demassari@...il.com>,
hust-os-kernel-patches@...glegroups.com,
syzbot+a3f758b8d8cb7e49afec@...kaller.appspotmail.com,
"Pierre-Loup A. Griffais" <pgriffais@...vesoftware.com>,
linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Input: xpad - fix GPF in xpad_probe
Btw, we should be thinking about how to detect these sorts of issues
using static analysis. Unfortunately, it's not as simple as saying
"We know this variable is NULL so don't dereference it." The problem
with that is that many times Smatch sees where a pointer is set to NULL
but not when it is assigned to a different value.
What we could do instead is say:
1) If a pointer is dereferenced and we know it is NULL then:
set_state_expr(my_id, expr, &suspicious);
2) If we set a pointer to non-NULL and it is marked as suspicious then
print a warning.
This would generate a warning for cases where we dereference a pointer
before it has been initialized.
It is not hard to write a Smatch check like this. The first draft
approach is only three functions long.
regards,
dan carpenter
Powered by blists - more mailing lists