This is a note to let you know that we have just queued up the patch titled
Subject: Netfilter: bridge: fix double POST_ROUTING invocation
to the 2.6.23-stable tree. Its filename is
netfilter-bridge-fix-double-post_routing-invocation.patch
A git repo of this tree can be found at
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
>From stable-bounces@xxxxxxxxxxxxxxxx Tue Jan 29 10:08:57 2008
From: Patrick McHardy <kaber@xxxxxxxxx>
Date: Tue, 29 Jan 2008 19:08:25 +0100
Subject: Netfilter: bridge: fix double POST_ROUTING invocation
To: stable@xxxxxxxxxx
Cc: Netfilter Development Mailinglist <netfilter-devel@xxxxxxxxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>
Message-ID: <479F6B99.60005@xxxxxxxxx>
From: Patrick McHardy <kaber@xxxxxxxxx>
[NETFILTER]: bridge: fix double POST_ROUTING invocation
Upstream commit 2948d2ebbb98747b912ac6d0c864b4d02be8a6f5
The bridge code incorrectly causes two POST_ROUTING hook invocations
for DNATed packets that end up on the same bridge device. This
happens because packets with a changed destination address are passed
to dst_output() to make them go through the neighbour output function
again to build a new destination MAC address, before they will continue
through the IP hooks simulated by bridge netfilter.
The resulting hook order is:
PREROUTING (bridge netfilter)
POSTROUTING (dst_output -> ip_output)
FORWARD (bridge netfilter)
POSTROUTING (bridge netfilter)
The deferred hooks used to abort the first POST_ROUTING invocation,
but since the only thing bridge netfilter actually really wants is
a new MAC address, we can avoid going through the IP stack completely
by simply calling the neighbour output function directly.
Tested, reported and lots of data provided by: Damien Thebault <damien.thebault@xxxxxxxxx>
Signed-off-by: Patrick McHardy <kaber@xxxxxxxxx>
Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxx>
---
net/bridge/br_netfilter.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -247,8 +247,9 @@ static void __br_dnat_complain(void)
* Let us first consider the case that ip_route_input() succeeds:
*
* If skb->dst->dev equals the logical bridge device the packet
- * came in on, we can consider this bridging. We then call
- * skb->dst->output() which will make the packet enter br_nf_local_out()
+ * came in on, we can consider this bridging. The packet is passed
+ * through the neighbour output function to build a new destination
+ * MAC address, which will make the packet enter br_nf_local_out()
* not much later. In that function it is assured that the iptables
* FORWARD chain is traversed for the packet.
*
@@ -285,12 +286,17 @@ static int br_nf_pre_routing_finish_brid
skb->nf_bridge->mask ^= BRNF_NF_BRIDGE_PREROUTING;
skb->dev = bridge_parent(skb->dev);
- if (!skb->dev)
- kfree_skb(skb);
- else {
+ if (skb->dev) {
+ struct dst_entry *dst = skb->dst;
+
nf_bridge_pull_encap_header(skb);
- skb->dst->output(skb);
+
+ if (dst->hh)
+ return neigh_hh_output(dst->hh, skb);
+ else if (dst->neighbour)
+ return dst->neighbour->output(skb);
}
+ kfree_skb(skb);
return 0;
}
Patches currently in stable-queue which might be from kaber@xxxxxxxxx are
queue-2.6.23/netfilter-bridge-fix-double-post_routing-invocation.patch
queue-2.6.23/netfilter-bridge-netfilter-fix-net_device-refcnt-leaks.patch
-
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
