linux-kernel - Re: [PATCH 1/2] zram: fix crashes due to use of cpu hotplug multistate

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]

Date:   Wed, 10 Mar 2021 21:21:28 +0000
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     Minchan Kim <minchan@...nel.org>
Cc:     ngupta@...are.org, sergey.senozhatsky.work@...il.com,
        axboe@...nel.dk, mbenes@...e.com, linux-block@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] zram: fix crashes due to use of cpu hotplug
 multistate

On Mon, Mar 08, 2021 at 06:55:30PM -0800, Minchan Kim wrote:
> If I understand correctly, bugs you found were related to module
> unloading race while the zram are still working.

No, that is a simplifcation of the issue. The issue consists of
two separate issues:

 a) race against module unloading in light of incorrect racty use of
    cpu hotplug multistate support
 b) module unload race with sysfs attribute race on *any* driver which
    has sysfs attributes which also shares the same lock as used during
    module unload

It is important to realize that issue b) is actually a generic kernel
issue, it would be present on *any* driver which shares a lock used on
a sysfs attribute and module unload. I looked to implement a generic
solution on kernfs, however we don't yet have semantics to enable this
generically, and so for now each driver needs to deal with those races
on their own. That sysfs race is dealt with in the second patch.

The first patch only deals with the cpu hotplug races exposed at module
unloading.

  Luis