linux-kernel - Re: [Patch -mm 3/3] RFC: Introduce kobject->owner for refcounting.

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:	Mon, 16 Apr 2007 15:53:31 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Greg KH <greg@...ah.com>
cc:	Cornelia Huck <cornelia.huck@...ibm.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Tejun Heo <htejun@...il.com>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [Patch -mm 3/3] RFC: Introduce kobject->owner for refcounting.

On Mon, 16 Apr 2007, Greg KH wrote:

> On Mon, Apr 16, 2007 at 07:36:27PM +0200, Cornelia Huck wrote:
> > Grab and release the module kobject refcount if kobj->owner is set.
> > This prevents calls to the release function after the module has
> > been unloaded.
> 
> But doesn't this cause reference counts to be grabbed on modules that
> don't want them?  (like network drivers)?

The refcounts we are talking about will not prevent modules from being 
unloaded.  That is, they won't cause rmmod to fail -- they will simply 
cause it to wait until the refcount drops to 0.  This should happen 
naturally as a result of the unregistration calls made by the module's 
exit routine.

(That was the intention, anyway.  I haven't yet seen all the parts of 
Cornelia's patch set, but that's how we discussed it.)

> I don't understand what exactly you are trying to protect from here.
> Especially as Tejun just ripped the lifetime rules between sysfs and
> kobjects apart.

There are other ways for userspace to acquire references to kernel 
objects.  Think of procfs or debugfs, for example.  Or opening a device 
file.

Consider this example:  A user has a pcmcia card containing a USB host 
controller.  He plugs a USB flash drive into the card and mounts a 
filesystem stored on the flash drive.  The mount call increments the 
module refcount for usb-storage (the owner of the block device containing 
the filesystem), but it doesn't do anything to the module refcount for the 
pcmcia driver (I forget its name -- yenta or something like that).

So what happens if the pcmcia driver is unloaded while the filesystem is
mounted?  What happens when the filesystem is finally unmounted and a
release method belonging to the pcmcia driver is called?

The fundamental rule is that whenever you hand out a pointer to a routine
living in a module, the receiver has to increment the module's refcount.  
But the driver core violates this rule all over the place.  The most
pervasive offender is struct device -- it contains a release() method
pointer which often points into a module, but the driver core doesn't
do anything like try_module_get() in device_initialize() or module_put()
after calling dev->release().

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/