linux/net/netfilter, branch v3.7

netfilter: ipset: fix netiface set name overflow

2012-11-24T22:48:23Z

attribute is copied to IFNAMSIZ-size stack variable, but IFNAMSIZ is smaller than IPSET_MAXNAMELEN. Fortunately nfnetlink needs CAP_NET_ADMIN. Signed-off-by: Florian Westphal Acked-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso

netfilter: cttimeout: fix buffer overflow

2012-11-21T22:50:14Z

Chen Gang reports: the length of nla_data(cda[CTA_TIMEOUT_NAME]) is not limited in server side. And indeed, its used to strcpy to a fixed-sized buffer. Fortunately, nfnetlink users need CAP_NET_ADMIN. Reported-by: Chen Gang Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso

netfilter: ipset: Fix range bug in hash:ip,port,net

2012-11-21T22:49:02Z

Due to the missing ininitalization at adding/deleting entries, when a plain_ip,port,net element was the object, multiple elements were added/deleted instead. The bug came from the missing dangling default initialization. The error-prone default initialization is corrected in all hash:* types. Signed-off-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso

netfilter: nf_conntrack: fix rt_gateway checks for H.323 helper

2012-10-22T10:21:55Z

After the change "Adjust semantics of rt->rt_gateway" (commit f8126f1d51) we should properly match the nexthop when destinations are directly connected because rt_gateway can be 0. The rt_gateway checks in H.323 helper try to avoid the creation of an unnecessary expectation in this call-forwarding case: http://people.netfilter.org/zhaojingmin/h323_conntrack_nat_helper/#_Toc133598073 However, the existing code fails to avoid that in many cases, see this thread: http://marc.info/?l=linux-netdev&m=135043175028620&w=2 It seems it is not trivial to know from the kernel if two hosts have to go through the firewall to communicate each other, which is the main point of the call-forwarding filter code to avoid creating unnecessary expectations. So this patch just gets things the way they were as before commit f8126f1d51. Signed-off-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso

netfilter: xt_TEE: don't use destination address found in header

2012-10-17T09:00:31Z

Torsten Luettgert bisected TEE regression starting with commit f8126f1d5136be1 (ipv4: Adjust semantics of rt->rt_gateway.) The problem is that it tries to ARP-lookup the original destination address of the forwarded packet, not the address of the gateway. Fix this using FLOWI_FLAG_KNOWN_NH Julian added in commit c92b96553a80c1 (ipv4: Add FLOWI_FLAG_KNOWN_NH), so that known nexthop (info->gw.ip) has preference on resolving. Reported-by: Torsten Luettgert Bisected-by: Torsten Luettgert Tested-by: Torsten Luettgert Cc: Julian Anastasov Signed-off-by: Eric Dumazet Signed-off-by: Pablo Neira Ayuso

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2012-10-17T08:59:20Z

To obtain new flag FLOWI_FLAG_KNOWN_NH to fix netfilter's xt_TEE target.

netfilter: xt_nat: fix incorrect hooks for SNAT and DNAT targets

2012-10-15T11:39:12Z

In (c7232c9 netfilter: add protocol independent NAT core), the hooks were accidentally modified: SNAT hooks are POST_ROUTING and LOCAL_IN (before it was LOCAL_OUT). DNAT hooks are PRE_ROUTING and LOCAL_OUT (before it was LOCAL_IN). Signed-off-by: Elison Niven Signed-off-by: Sanket Shah Signed-off-by: Pablo Neira Ayuso

netfilter: xt_CT: fix timeout setting with IPv6

2012-10-15T11:38:58Z

This patch fixes ip6tables and the CT target if it is used to set some custom conntrack timeout policy for IPv6. Use xt_ct_find_proto which already handles the ip6tables case for us. Signed-off-by: Pablo Neira Ayuso

ipvs: initialize returned data in do_ip_vs_get_ctl

2012-10-09T04:04:34Z

As reported by a gcc warning, the do_ip_vs_get_ctl does not initalize all the members of the ip_vs_timeout_user structure it returns if at least one of the TCP or UDP protocols is disabled for ipvs. This makes sure that the data is always initialized, before it is returned as a response to IPVS_CMD_GET_CONFIG or printed as a debug message in IPVS_CMD_SET_CONFIG. Without this patch, building ARM ixp4xx_defconfig results in: net/netfilter/ipvs/ip_vs_ctl.c: In function 'ip_vs_genl_set_cmd': net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.udp_timeout' may be used uninitialized in this function [-Wuninitialized] net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.udp_timeout' was declared here net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_fin_timeout' may be used uninitialized in this function [-Wuninitialized] net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_fin_timeout' was declared here net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_timeout' may be used uninitialized in this function [-Wuninitialized] net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_timeout' was declared here Signed-off-by: Arnd Bergmann Acked-by: Julian Anastasov Signed-off-by: Simon Horman

ipvs: fix ARP resolving for direct routing mode

2012-10-08T21:42:36Z

After the change "Make neigh lookups directly in output packet path" (commit a263b30936) IPVS can not reach the real server for DR mode because we resolve the destination address from IP header, not from route neighbour. Use the new FLOWI_FLAG_KNOWN_NH flag to request output routes with known nexthop, so that it has preference on resolving. Signed-off-by: Julian Anastasov Signed-off-by: David S. Miller