netdev - Re: [PATCH 1/7] uio: add module owner to prevent inappropriate module unloading

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:	Thu, 15 Aug 2013 09:42:27 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:	Benedikt Spranger <b.spranger@...utronix.de>,
	netdev@...r.kernel.org,
	Alexander Frank <Alexander.Frank@...rspaecher.com>,
	"Hans J. Koch" <hjk@...sjkoch.de>,
	Holger Dengler <dengler@...utronix.de>
Subject: Re: [PATCH 1/7] uio: add module owner to prevent inappropriate
 module unloading

On Thu, Aug 15, 2013 at 06:03:44PM +0200, Sebastian Andrzej Siewior wrote:
> On 08/15/2013 05:55 PM, Greg Kroah-Hartman wrote:
> > But that's a "platform" device, for a resource that is described as not
> > going away.
> > 
> > If this is really a mfd device, then make your uio driver a mfd driver,
> > not a platform driver for a resource that isn't under your control.
> 
> As you described it later yourself: You have the same problem if you
> manually unbind the platform_device from the driver while the device
> node is open.

No, at that point in time the remove function of the uio driver should
be called, and you can invalidate everything then.  Or the driver should
be doing that, odds are, it needs to be fixed because no one checks for
that :)

> >> If you look now at uio_write() then you will notice that it will
> >> deference idev->info->irqcontrol but once the device is gone the memory
> >> starting at info is gone, not to mention the code behind irqcontrol.
> > 
> > It sounds like the wrong uio driver is binding to this device, fix the
> > uio driver and you should be fine, right?
> 
> For this to happen you would need a refcount in uio-core which learns
> that the device is gone and does not invoke any callbacks because the
> device is gone. Something like you have in USB where you return 0 on
> reads from ttyUSB after someone pulled the cable.

That happens because we invalidate the filehandle in the tty layer by
tearing everything down in the usb serial driver.  And yes, uio also
needs to do the same thing, if it doesn't already.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html