linux-kernel - Re: [PATCH] Input: xpad

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3ccc85bd-0541-4ffb-a207-dfc533a2c0aa@kili.mountain>
Date:   Thu, 20 Apr 2023 14:07:12 +0300
From:   Dan Carpenter <dan.carpenter@...aro.org>
To:     Dan Carpenter <error27@...il.com>
Cc:     Dongliang Mu <dzm91@...t.edu.cn>, Vicki Pfau <vi@...rift.com>,
        kernel-janitors@...r.kernel.org,
        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

On Mon, Apr 17, 2023 at 01:42:21PM +0300, Dan Carpenter wrote:
> 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.

I was thinking about this and it's not so simple.  Normally after a
warning we return so the state never transitions from &suspicious to
non-NULL.

So what we could do is set the state to &suspicious.  Then at the end of
the function we look at all the states at the return paths.  If the
state is non-NULL on any return path then print a warning.  This is easy
enough to do, but requires quite a bit of Smatch knowledge so I have
done it.  Attached.

Unfortunately, it doesn't print a warning in this case because Smatch
doesn't track that _dev_warn() dereferences the "dev" pointer.  The
__dev_printk() function only dereferences "dev" if it is non-NULL.
Smatch only counts it if it *always* dereferences it.

This could be fixed in two steps:
Step 1: track dereferences based on the return insead just yes/no.
Step 2: split _dev_warn() returns into two returns based on if dev is
        NULL or non-NULL.

Step 1 is probably a good idea.  Step 2 is a bad idea, because it makes
no sense to pass a NULL to dev_warn().

A better approach for this bug is to print a warning if people pass
the address of the offset from a NULL pointer.  Combine that with the
same return states filter as earlier to eliminate false positives where
Smatch thinks a pointer is always NULL.

drivers/input/joystick/xpad.c:2053 xpad_probe() warn: address of NULL pointer 'xpad->dev'
drivers/media/i2c/ccs/ccs-data.c:524 ccs_data_parse_rules() warn: address of NULL pointer 'rules'
drivers/scsi/lpfc/lpfc_attr.c:1482 lpfc_reset_pci_bus() warn: address of NULL pointer 'phba->pcidev'

That check is attached too.

regards,
dan carpenter

View attachment "check_deref_before_set.c" of type "text/x-csrc" (1714 bytes)

View attachment "check_bogus_address_param.c" of type "text/x-csrc" (2659 bytes)