From patchwork Wed May 21 20:18:41 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Miller X-Patchwork-Id: 351290 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id DD228140083 for ; Thu, 22 May 2014 06:18:51 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752036AbaEUUSt (ORCPT ); Wed, 21 May 2014 16:18:49 -0400 Received: from shards.monkeyblade.net ([149.20.54.216]:55614 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751616AbaEUUSt (ORCPT ); Wed, 21 May 2014 16:18:49 -0400 Received: from localhost (unknown [75.103.36.255]) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 1161C580412; Wed, 21 May 2014 13:18:42 -0700 (PDT) Date: Wed, 21 May 2014 16:18:41 -0400 (EDT) Message-Id: <20140521.161841.1806439174351824310.davem@davemloft.net> To: bdschuym@pandora.be Cc: davidn@davidnewall.com, fw@strlen.de, stephen@networkplumber.org, netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, bridge@lists.linux-foundation.org Subject: Re: Revert 462fb2af9788a82a534f8184abfde31574e1cfa0 (bridge : Sanitize skb before it enters the IP stack) From: David Miller In-Reply-To: <537CF5A2.3080401@pandora.be> References: <537A6E5C.6090602@pandora.be> <537C5A6C.3030809@davidnewall.com> <537CF5A2.3080401@pandora.be> X-Mailer: Mew version 6.5 on Emacs 24.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7 (shards.monkeyblade.net [149.20.54.216]); Wed, 21 May 2014 13:18:43 -0700 (PDT) Sender: netfilter-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netfilter-devel@vger.kernel.org From: Bart De Schuymer Date: Wed, 21 May 2014 20:51:14 +0200 > David Newall schreef op 21/05/2014 9:49: >>> An alternative would be to make sure that the data pointed to by IPCB >>> and BR_INPUT_SKB_CB don't overlap. If this were the case, we could >>> indeed just revert the commit that was referred to. >> >> They are identical spaces, but you imply a good point: the cb area is >> possibly being used, simultaneously, for two, incompatible >> purposes. Yet >> another argument for divorcing bridge of ip logic. > > There's no reason why they should overlap in the cb: it's 48 bytes > big, so big enough to hold both struct br_input_skb_cb and struct > inet_skb_parm. The original problem was introduced when > BR_INPUT_SKB_CB was introduced (around Feb 27, 2010), so fixing > BR_INPUT_SKB_CB seems most appropriate to me. So you are suggesting the patch below will fix everything? > As for your other remark: as I've said before, if you don't like > bridge-netfilter then don't compile it into your kernel. That's never a good argument, please stop making it. %99.999999999 of users get their kernels from distributions and they are all going to enable basically every feature available. We never should have added bridging netfilter to the tree in the first place, I wish I had better judgment back then. --- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h index 06811d7..2300def 100644 --- a/net/bridge/br_private.h +++ b/net/bridge/br_private.h @@ -18,6 +18,7 @@ #include #include #include +#include #include #define BR_HASH_BITS 8 @@ -297,6 +298,7 @@ struct net_bridge }; struct br_input_skb_cb { + struct inet_skb_parm ip; struct net_device *brdev; #ifdef CONFIG_BRIDGE_IGMP_SNOOPING int igmp;