netdev - [PATCH] net: Fix a memmove bug in dev_gro

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: <20100811120210.GA24019@ff.dom.local>
Date:	Wed, 11 Aug 2010 12:02:10 +0000
From:	Jarek Poplawski <jarkao2@...il.com>
To:	"Xin, Xiaohui" <xiaohui.xin@...el.com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
	"davem@...emloft.net" <davem@...emloft.net>
Subject: [PATCH] net: Fix a memmove bug in dev_gro_receive()

[was: Re: Is it a possible bug in dev_gro_receive()?]
On Tue, Aug 10, 2010 at 08:34:26AM +0000, Jarek Poplawski wrote:
> On Tue, Aug 10, 2010 at 04:11:54PM +0800, Xin, Xiaohui wrote:
> > Jarek,
> > Seems community agree with your patch more.
> > So may you send out your patch then? Thanks!
> > Some of my related patches still need this fix.
> 
> Hmm... But there was no my patch. Only a tiny, cosmetical suggestion
> to your patch. I'd be glad if you add some credit or my "Acked-by",
> of course. But if you really have a big problem, e.g. you don't like
> my suggestion, please confirm.

Hmm#2... OK, it's probably something with my English, but since it
seems to take too long, here it is. Xiaohui, I hope you'll send your
"Signed-off-by" at least.

Thanks,
Jarek P.

PS: I know, there is a bit too long line...
--------------------------->

>Xin Xiaohui wrote:
> I looked into the code dev_gro_receive(), found the code here:
> if the frags[0] is pulled to 0, then the page will be released,
> and memmove() frags left.
> Is that right? I'm not sure if memmove do right or not, but
> frags[0].size is never set after memove at least. what I think
> a simple way is not to do anything if we found frags[0].size == 0.
> The patch is as followed.
...

This version of the patch fixes the bug directly in memmove.

Reported-by: "Xin, Xiaohui" <xiaohui.xin@...el.com>
Signed-off-by: Jarek Poplawski <jarkao2@...il.com>

---

diff --git a/net/core/dev.c b/net/core/dev.c
index 1ae6543..3721fbb 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3143,7 +3143,7 @@ pull:
 			put_page(skb_shinfo(skb)->frags[0].page);
 			memmove(skb_shinfo(skb)->frags,
 				skb_shinfo(skb)->frags + 1,
-				--skb_shinfo(skb)->nr_frags);
+				--skb_shinfo(skb)->nr_frags * sizeof(skb_frag_t));
 		}
 	}
 
--
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