From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966508AbcA1PPH (ORCPT ); Thu, 28 Jan 2016 10:15:07 -0500 Received: from smtp37.cstnet.cn ([159.226.251.37]:42787 "EHLO cstnet.cn" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752165AbcA1PPE (ORCPT ); Thu, 28 Jan 2016 10:15:04 -0500 Date: Thu, 28 Jan 2016 23:13:34 +0800 (GMT+08:00) From: "Zhouyi Zhou" To: "Florian Westphal" , gnomes@lxorguk.ukuu.org.uk, sergei.shtylyov@cogentembedded.com Cc: "Zhouyi Zhou" , eric.dumazet@gmail.com, pablo@netfilter.org, kaber@trash.net, kadlec@blackhole.kfki.hu, davem@davemloft.net, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Message-ID: <5b6c32.5bd1.15288cbf662.Coremail.yizhouzhou@ict.ac.cn> In-Reply-To: <20160128142959.GB30994@breakpoint.cc> References: <1453971597-4811-1-git-send-email-zhouzhouyi@gmail.com> <20160128142959.GB30994@breakpoint.cc> Subject: Re: Re: [PATCH V2] netfilter: h323: avoid potential attack MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Originating-IP: [114.111.166.69] X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT2.1.11 dev build 20150107(58648.7033.6860) Copyright (c) 2002-2016 www.mailtech.cn cstnet X-SendMailWithSms: false X-CM-CTRLDATA: 2nYLHGZvb3Rlcl90eHQ9MTcyNDo2 X-CM-TRANSID: TwCowJDLbvMfMKpWDHAMAA--.28464W X-CM-SenderInfo: x1l2x05x2k03g6lf3hldfou0/1tbiCQAIAFZdtjIKYQAAsl X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3GIAIbVAYFVCjjxCrMI AIbVAFxVCF77xC64kEw24lV2xY67C26IkvcIIF6IxKo4kEV4DvcSsGvfC2KfnxnUU== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks for your advices. I will take your advice if I could have the opportunity to write the final code. As matter of factor, I trigger this bug when I tried to migrate H323 code to other operating systems. This could trigger a panic because get_h2x5_addr functions is the first time we ever try to ask for potentially out of range data because of H323 style decodings (the value taddr->ipAddress.ip is decoded in the midway between calling skb_header_pointer and calling get_h2x5_addr) > -----Original Messages----- > From: "Florian Westphal" > Sent Time: Thursday, January 28, 2016 > To: "Zhouyi Zhou" > Cc: eric.dumazet@gmail.com, pablo@netfilter.org, kaber@trash.net, kadlec@blackhole.kfki.hu, davem@davemloft.net, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.or, "Zhouyi Zhou" > Subject: Re: [PATCH V2] netfilter: h323: avoid potential attack > > Zhouyi Zhou wrote: > > Thanks Eric for your review and advice. > > > > I think hackers chould build a malicious h323 packet to overflow > > the pointer p which will panic during the memcpy(addr, p, len) > > > > For example, he may fabricate a very large taddr->ipAddress.ip; > > Can you be more specific? > > h323_buffer is backend storage for skb_header_pointer, i.e. > this will error out early when we ask for more data than is available in > packet. > > I don't understand how this could overflow anything. > Even assuming 64k packet we'd still have enough room in h323_buffer > for an ipv6 address, no? (we skip the l3/l4 header when extracting > packet payload). >