netdev - Re: [PATCH v2 3/3] pppoatm: protect against freeing of vcc

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]

Date:	Wed, 28 Nov 2012 10:18:47 -0500
From:	chas williams - CONTRACTOR <chas@....nrl.navy.mil>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	Krzysztof Mazur <krzysiek@...lesie.net>,
	David Laight <David.Laight@...LAB.COM>, davem@...emloft.net,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	nathan@...verse.com.au
Subject: Re: [PATCH v2 3/3] pppoatm: protect against freeing of vcc

On Wed, 28 Nov 2012 10:24:28 +0000
David Woodhouse <dwmw2@...radead.org> wrote:

> On Wed, 2012-11-28 at 11:04 +0100, Krzysztof Mazur wrote:
> > 
> > The ->close() routine can just abort any pending rx/tx and just wait
> > for completion of currently running rx/tx code. That shouldn't take
> > long.
> 
> If it's been submitted to the hardware for DMA, it can't do that very
> easily.
> 
> And if I can't be bothered to write code to go through the entire damn
> queue and inspect every packet to see if it's a data packet and check
> the VCI/VPI and try to steal it, it can't be done for the software queue
> either :)
> 
> The queue ought to be short; if it isn't, then we already screwed up.
> The close therefore should be quick, and it *doesn't* have to be
> instant.
> 
> If someone wants to return immediately, there's always
> vcc_release_async()...
> 

i dont think that would be quite the right way to do it.
vcc_release_async() just mark's the vcc for deletion--you still need to
go through and close it eventually.  however, nothing would prevent you
from writing a close routine that could just reschedule something
periodically to check to see if the hardware finally finished closing
the vcc and can be reused.  the part that needs fixed for this would be
marking the vcc for reuse.  you would need to keep the vpi.vci marked
as busy so that someone else doesnt try to reuse it while it is
closing.  right now, vcc_destroy_socket() always removes the vcc from
the vcc list -- regardless of whether or not close fully succeeded.
--
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