linux-kernel - Re: [Patch -mm 0/3] RFC: module unloading vs. release function

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: <Pine.LNX.4.44L0.0704161530160.2685-100000@iolanthe.rowland.org>
Date:	Mon, 16 Apr 2007 15:38:52 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
cc:	Cornelia Huck <cornelia.huck@...ibm.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Greg K-H <greg@...ah.com>, Tejun Heo <htejun@...il.com>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [Patch -mm 0/3] RFC: module unloading vs. release function

On Mon, 16 Apr 2007, Dmitry Torokhov wrote:

> On 4/16/07, Cornelia Huck <cornelia.huck@...ibm.com> wrote:
> > Hi,
> >
> > based on the discussion in "How should an exit routine wait for
> > release() callbacks?", I've cooked up some patches that make module
> > unload wait until the last reference for a kobject has been dropped.
> > This should plug the "release function in already deleted module" race;
> > however, if the last kobject_put() from the module containing the
> > release function is not in the module's exit function, there's still a
> > small window (not sure if and how to plug this).
> 
> Unfortunately all this "wait for refcount in module's exit" schemas
> lead to the following deadlock:
> 
>         rmmod my_module < /path/to/some/file/incrementing/my/refcount

(Note that this problem will be a lot harder to provoke once Tejun's
changes to sysfs are in place.  But it will still be possible, unless we 
make similar changes to all the other filesystems as well.)

There are three possible approaches to this problem:

     1. Ignore it, as we do now.  If someone actually tries running your
	example above, an oops will result when the kobject's release
	method is called after my_module has been unloaded from memory.

     2. Do what Cornelia suggested, and allow the example to deadlock.

     3. Change the module code so that rmmod can return _before_ the
	module is actually unloaded from memory (but after the module's
	exit routine has completed).  This will lead to more problems.
	For example, what if someone tries to modprobe my_module back
	again before it has finished unloading?

My feeling is that either a deadlock or more complications with modprobe 
would be preferable to an oops.  Your opinion may differ.

(Also, doing this might be a good way to expose a lot of hidden 
refcounting bugs.  They will become very obvious when rmmod hangs.)

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/