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] [day] [month] [year] [list]
Message-ID: <20120918131542.GR13767@mwanda>
Date:	Tue, 18 Sep 2012 16:15:43 +0300
From:	Dan Carpenter <dan.carpenter@...cle.com>
To:	navin patidar <navinp@...c.in>
Cc:	gregkh@...uxfoundation.org, mfm@...eddisk.com,
	devel@...verdev.osuosl.org, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: usbip: stub_dev: Fixed oops during removal of
 usbip_host

On Tue, Sep 18, 2012 at 05:14:41PM +0530, navin patidar wrote:
> for usbip_host  event_handler()   handles following events.  defined
> in "usbip_common.h"
> 
>  1. SDEV_EVENT_REMOVED   (USBIP_EH_SHUTDOWN | USBIP_EH_RESET | USBIP_EH_BYE)
>  2. SDEV_EVENT_DOWN		(USBIP_EH_SHUTDOWN | USBIP_EH_RESET)
>  3. SDEV_EVENT_ERROR_TCP	(USBIP_EH_SHUTDOWN | USBIP_EH_RESET)
>  4. SDEV_EVENT_ERROR_SUBMIT	(USBIP_EH_SHUTDOWN | USBIP_EH_RESET)
>  5. VDEV_EVENT_ERROR_MALLOC (USBIP_EH_SHUTDOWN | USBIP_EH_UNUSABLE)
> 
> In case of events(1,2,3,4),  stub_shoutdown_connection() gets executed
> first and than stub_device_reset() .
> 
> In case of event 5, stub_shoutdown_connection()  kills kernel threads
> and stub_device_unusable()   changes devices status to
> "SDEV_ST_ERROR"(fatal error).
> 

It's case #5 which I would be worried about.  Where did the original
Oops happen?  I feel like it really would be helpful to see it.  I
don't see which check for ->status != SDEV_ST_AVAILABLE you're
talking about here which prevents the pointers from being reused...

>  thus stub_device_reset() can't  be called without
> stub_shutdown_connection(), so there is no problem of resource leak .

Except in the case of #5 obviously.

> you are also right, i could have set pointers to  NULL in
> stub_shutdown_connection() but i used  stub_device_reset() which is
> intended to reset usbip_device stuct member variables.
> 
> i'll resend patches, if maintainer ask for that.
> thanks
> 

Generally, that's normal.  If you want to ensure that a pointer
isn't used again then you clear it immediately.

I'm honestly just trying to figure this out.  When I saw that the
patch, I immediately thought *resource leak*.  I'm sorry that to
take your time up, but it shouldn't be that complicated that I have
to go tracking through the whole driver to understand this.

regards,
dan carpenter
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ