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: <20130815164227.GC15688@kroah.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ