netdev - Re: tg3 NIC driver bug in 3.14.x under Xen [and 3 more messages]

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: <20150416.141402.496529110341582886.davem@davemloft.net>
Date:	Thu, 16 Apr 2015 14:14:02 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	mchan@...adcom.com
Cc:	cascardo@...ux.vnet.ibm.com, Ian.Jackson@...citrix.com,
	prashant@...adcom.com, konrad.wilk@...cle.com,
	boris.ostrovsky@...cle.com, david.vrabel@...rix.com,
	vyasevich@...il.com, xen-devel@...ts.xensource.com,
	netdev@...r.kernel.org, siva.kallam@...adcom.com,
	sanjeevb@...adcom.com
Subject: Re: tg3 NIC driver bug in 3.14.x under Xen [and 3 more messages]

From: Michael Chan <mchan@...adcom.com>
Date: Thu, 16 Apr 2015 09:39:13 -0700

> On Thu, 2015-04-16 at 09:24 -0300, cascardo@...ux.vnet.ibm.com wrote: 
>> Yes, this looks like the driver is not syncing the DMA buffers. Unmap is
>> supposed to synchronize as well.
>> 
> 
> For small rx packets (< 256 bytes), we sync the DMA buffer before we
> copy the data to another SKB.  For larger packets, we unmap the DMA
> buffer.  Do we see the corruption in both cases?

I wonder about that prefetch which is done before the DMA sync.

Also we should think about whether that DMA sync applies to the proper
region.  The 'len' is relative to "data+TG3_RX_OFFSET" yet if I read
the code correctly we are effectively sync'ing from 'data' to
'data+len'.

There is some bug hiding in here I think...
--
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