linux-kernel - Re: hwmon: (sis5595) potential null pointer dereference in probe

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 for Android: free password hash cracker in your pocket

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

Message-ID: <23dceaac-526d-4ee3-40de-cf354b0aeabd@roeck-us.net>
Date:   Tue, 4 Aug 2020 07:33:15 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Evgeny Novikov <novikov@...ras.ru>,
        Jean Delvare <jdelvare@...e.com>
Cc:     linux-hwmon@...r.kernel.org,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: hwmon: (sis5595) potential null pointer dereference in probe

On 8/4/20 4:50 AM, Evgeny Novikov wrote:
> sis5595_pci_probe() registers platform driver callbacks and just then
> initializes global pointer variable s_bridge. sis5595_probe() may
> dereference it before this happens that can result in null pointer
> dereference.
> 
sis5595_probe() is only called after the device is registered,
which happens in sis5595_device_add() after s_bridge is set. This is
a southbridge, so there won't be any hot insertion/removal events.

> We can not swap registration of platform driver callbacks with
> initialization of s_bridge since sm_sis5595_exit() assumes the
> current order. Perhaps it has sense to implement a pci_driver.remove
> callback that will take care about deregistration of platform driver
> callbacks.
>

Agreed regarding the remove function. However, given the age of the chip,
I'd rather remove the driver than spending time on cleanup efforts.
This looks like a perfect candidate for depreciation.

Guenter