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:	Mon, 04 Jul 2011 16:00:49 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Alexey Zaytsev <alexey.zaytsev@...il.com>
Cc:	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 lundi 04 juillet 2011 à 15:48 +0400, Alexey Zaytsev a écrit :

> 
> This might fix a potential problem, but unfortunately did not help here.
> 
> There is an other place that looks suspicious to me:
> 
>  812                         struct sk_buff *copy_skb;
>  813
>  814                         b44_recycle_rx(bp, cons, bp->rx_prod);
>  815                         copy_skb = netdev_alloc_skb(bp->dev, len + 2);
>  816                         if (copy_skb == NULL)
>  817                                 goto drop_it_no_recycle;
>  818
>  819                         skb_reserve(copy_skb, 2);
>  820                         skb_put(copy_skb, len);
>  821                         /* DMA sync done above, copy just the
> actual packet */
>  822                         skb_copy_from_linear_data_offset(skb,
> RX_PKT_OFFSET,
>  823
> copy_skb->data, len);
>  824                         skb = copy_skb;
> 
> 
> The skb is reinserted into the ring before its data is copied, it
> seems. But this can't be the cause of my problem, as it would lead to
> data corruption at most, not a write-after-free.
> 
> And an other question. Why so we have the logic to work-around the 1Gb
> DMA limit instead of just setting the dma mask?

Your problem is in RX side : NIC actually writes to a buffer that is
supposedly not its property.

If DMA workaround is triggered, all frames are copied, so bug has no
chance to trigger, because we feed a totally new frame to upper stack,
and keep reuse 'DMA' frames for the device itself.




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