netdev - Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2

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]

Date:	Sun, 24 Mar 2013 18:23:04 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	"Huang, Xiong" <xiong@....qualcomm.com>
Cc:	Sven Hartge <sven@...nhartge.de>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2

On Sun, Mar 24, 2013 at 05:42:41AM +0000, Huang, Xiong wrote:
> > > >
> > > > The caputered packets show that a 16 byte segment overwrites later
> > > > data in the same packet, sometimes even multiple contiguous 16 byte
> > segments.
> > > >
> > > > The corrupted packets look like this:
> > > >
> > > > ...ABC....DBBEF..
> > > >
> > > > Each character represents a 16 byte region, the dots are dont-care
> > > > placeholders. The BB-region is overwritten by the data of the first B-
> > region.
> > > >
> > >
> > > It looks like a DMA issue. Not checksum related. :(
> > 
> > Yes, I think so, too. Until this is resolved I would propose to not set
> > CHECKSUM_UNNECESSARY because it could corrupt data (like for the original
> > poster).
> > 
> > Do you have any idea where how these errors could be resolved? I e.g. could
> > not reproduce it with FreeBSD and the driver seems to be related to the linux
> > driver.
> 
> 1.  pages cross 4GB bouandary ?  or overlap with each other ?

This should not be the case.

> 2. try to set hw->dmaw_block = atl1e_dma_req_128 

Sorry, we can still reproduce corrupted frames with this change.

> 3. can you print reg15C0 content when the NIC is in normal tx/rx status ?

Yes, dma register is reg15C0 == 0x247c24 all the time (vanilla kernel without
any of your proposed changes).

Couldn't this also be because of a timing issue? It does take much more time
on slower machines(eeepc) to reproduce this issue. On a normal desktop machine it
does nearly occur instantaneous.

Thanks,

  Hannes

--
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