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: <YaoyuzPutBjLuVNt@kroah.com>
Date:   Fri, 3 Dec 2021 16:07:39 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Ming Lei <ming.lei@...hat.com>
Cc:     Petr Mladek <pmladek@...e.com>, linux-kernel@...r.kernel.org,
        Luis Chamberlain <mcgrof@...nel.org>
Subject: Re: [PATCH V2 2/2] kobject: wait until kobject is cleaned up before
 freeing module

On Mon, Nov 29, 2021 at 11:45:09AM +0800, Ming Lei wrote:
> kobject_put() may become asynchronously because of
> CONFIG_DEBUG_KOBJECT_RELEASE, so once kobject_put() returns, the caller may
> expect the kobject is released after the last refcnt is dropped, however
> CONFIG_DEBUG_KOBJECT_RELEASE just schedules one delayed work function
> for cleaning up the kobject.

The caller should NOT expect the kobject to be released.  That's the
whole point of dynamic reference counted objects, you never "know" when
the last object is released.  This option just makes it obvious so that
you know when to fix up code that has this assumption.

> Inside the cleanup handler, kobj->ktype and kobj->ktype->release are
> required.

Yes. Is that a problem?

> It is supposed that no activity is on kobject itself any more since
> module_exit() is started, so it is reasonable for the kobject user or
> driver to expect that kobject can be really released in the last run of
> kobject_put() in module_exit() code path. Otherwise, it can be thought as
> one driver's bug since the module is going away.

Why is module_exit() somehow special here?  What is so odd about that?

> When the ->ktype and ->ktype->release are allocated as module static
> variable, it can cause trouble because the delayed cleanup handler may
> be run after the module is unloaded.

Why is ktype and release part of module code?

What module kobject is causing this problem?

> Fixes the issue by flushing scheduled kobject cleanup work before
> freeing module.

Why are modules special here?

And if you enable this option, and then start unloading kernel modules,
yes, things can go wrong, but that's not what this kernel option is for
at all.

This feels like a hack for not a real problem.

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ