netdev - Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten

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:	Tue, 05 Jul 2011 22:02:27 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Neil Horman <nhorman@...driver.com>
Cc:	Alexey Zaytsev <alexey.zaytsev@...il.com>,
	Michael Büsch <m@...s.ch>,
	Andrew Morton <akpm@...ux-foundation.org>,
	netdev@...r.kernel.org, Gary Zambrano <zambrano@...adcom.com>,
	bugme-daemon@...zilla.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	Pekka Pietikainen <pp@...oulu.fi>,
	Florian Schirmer <jolt@...box.org>,
	Felix Fietkau <nbd@...nwrt.org>, Michael Buesch <mb@...sch.de>
Subject: Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison
 overwritten

Le mardi 05 juillet 2011 à 15:53 -0400, Neil Horman a écrit :
> I think this is a goo idea, at least for testing.  It seems odd to me that we
> have the B44_DMARX_PTR value which indicates (ostensibly) the pointer to the
> descriptor to be processed next (the documentation isnt' very verbose on the
> subject), along with the EOT bit on a descriptor.  It seems like both the
> register and the bit are capable of conveying the same (or at least overlapping)
> information.
> 
> I think what I'm having the most trouble with is understanding when the hw looks
> at the EOT bit in the descriptor.  If it completes a DMA and sees the EOT bit
> set, does the next DMA occur to the descriptor pointed to by the DMARX_ADDR
> register?  Of does it stall until such time as the DMARX_PTR register is rotated
> around?  What if it doesn't see the EOT bit set?  Does it just keep going with
> the next descriptor?  
> 
> Also, there seems to be some inconsistency in the settnig of the B44_DMARX_PTR
> register.  In bnx2_init_hw its set to the value of bp->rx_pending, which is
> defined as being 200.  But in b44_rx its advanced by sizeof(struct dma_desc) for
> every iteration.  So in b44_init_hw we write the value 200 to it, ostensibly
> indicating a limit of 200 descriptors, but in b44_rx we iteratively write the
> values 0, 8, 16, 24...4*n to the register to indicate which descriptor we're
> indexing?  Something really doesn't sit right with me there.  In the former case
> we treat the register as holding  number of entries, and in the latter we treat
> it as holding a byte offset into an array.  Or am I missing something?
> 

Yes, definitely this needs some clarification.

More over, when we hit the last entry (currently at slot 511), the EOT
instructs hardware to go back to slot 0, while our real window is
511-200 -> 511 . Slot 0 contains garbage (well, an old value)

Its late here so I dont plan to send a patch before 8/10 hours.



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