netdev - Re: [PATCH] net: fix race in the receive/select

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]

Date:	Wed, 1 Jul 2009 21:07:58 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Jiri Olsa <jolsa@...hat.com>
Cc:	Andi Kleen <andi@...stfloor.org>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, fbl@...hat.com, nhorman@...hat.com,
	davem@...hat.com, oleg@...hat.com, eric.dumazet@...il.com
Subject: Re: [PATCH] net: fix race in the receive/select

On Wed, Jul 01, 2009 at 06:58:52PM +0800, Herbert Xu wrote:
> 
> It would be good to know whether this bug occurs on the upstream
> kernel because as it stands, the patch is a no-op for the upstream
> kernel on x86-64.

I take that back.  Andi, please look at section 8.2.3.4 of the
IA-32 Architectures Software Developer's Manual Volume 3A, "Loads
May Be Reordered with Earlier Stores to Different Locations.
This seems to be exactly the scenario that we have here, and shows
why mfence is required.

In our case, we're doing

CPU1					CPU2
Write data ready			Add ourselves to wait queue
Read wait queue to notify		Check data ready

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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