linux-kernel - Re: [PATCH v2 2/3] pppoatm: fix race condition with destroying 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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1351589868.17077.34.camel@shinybook.infradead.org>
Date:	Tue, 30 Oct 2012 09:37:48 +0000
From:	David Woodhouse <dwmw2@...radead.org>
To:	Krzysztof Mazur <krzysiek@...lesie.net>
Cc:	davem@...emloft.net, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/3] pppoatm: fix race condition with destroying of
 vcc

On Mon, 2012-10-22 at 19:14 +0200, Krzysztof Mazur wrote:
> The pppoatm_send() calls vcc->send() and now also checks for
> some vcc flags that indicate destroyed vcc without proper locking.
> 
> The vcc_sendmsg() uses lock_sock(sk). This lock is used by
> vcc_release(), so vcc_destroy_socket() will not be called between
> check and during ->send(). The vcc_release_async() sets ATM_VF_CLOSE,
> but it should be safe to call ->send() after it, because
> vcc->dev->ops->close() is not called.
> 
> The pppoatm_send() is called with BH disabled, so bh_lock_sock()
> should be used instead of lock_sock().

Should we be locking it earlier, so that the atm_may_send() call is also
covered by the lock?

Either way, it's an obvious improvement on what we had before — and even
if the answer to my question above is 'yes', exceeding the configured
size by one packet is both harmless and almost never going to happen
since we now limit ourselves to two packets anyway. So:

Acked-By: David Woodhouse <David.Woodhouse@...el.com>

-- 
dwmw2


Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (6171 bytes)