linux.git/net/netfilter, branch v4.4-rc1

netfilter: nft_meta: use skb_to_full_sk() helper

2015-11-09T01:56:39+00:00

SYNACK packets might be attached to request sockets.

Fixes: ca6fb0651883 ("tcp: attach SYNACK messages to request sockets instead of listener")
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

netfilter: xt_owner: use skb_to_full_sk() helper

2015-11-09T01:56:39+00:00

SYNACK packets might be attached to a request socket,
xt_owner wants to gte the listener in this case.

Fixes: ca6fb0651883 ("tcp: attach SYNACK messages to request sockets instead of listener")
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf

2015-11-05T01:47:50+00:00

Conflicts:
	net/netfilter/xt_TEE.c

Pablo Neira Ayuso says:

====================
Netfilter fixes for net

The following patchset contains Netfilter fixes for your net tree,
they are:

1) Fix crash when TEE target is used with no --oif, from Eric Dumazet.

2) Oneliner to fix a crash on the redirect traffic to localhost
   infrastructure when interface has not yet an address, from
   Munehisa Kamata.

3) Oneliner not to request module all the time from nfnetlink due to
   wrong type value, from Florian Westphal.

I'll make sure these patches 1 and 2 hit -stable.
====================

The conflict in net/netfilter/xt_TEE.c was minor, a change
to the 'oif' selection overlapping a function signature
change for the nf_dup_ipv{4,6}() routines.

Signed-off-by: David S. Miller

netfilter: nfnetlink: don't probe module if it exists

2015-10-28T02:40:50+00:00

nfnetlink_bind request_module()s all the time as nfnetlink_get_subsys()
shifts the argument by 8 to obtain the subsys id.

So using type instead of type << 8 always returns NULL.

Fixes: 03292745b02d11 ("netlink: add nlk->netlink_bind hook for module auto-loading")
Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso

netfilter: nf_nat_redirect: add missing NULL pointer check

2015-10-27T05:54:56+00:00

Commit 8b13eddfdf04cbfa561725cfc42d6868fe896f56 ("netfilter: refactor NAT
redirect IPv4 to use it from nf_tables") has introduced a trivial logic
change which can result in the following crash.

BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
IP: [] nf_nat_redirect_ipv4+0x2d/0xa0 [nf_nat_redirect]
PGD 3ba662067 PUD 3ba661067 PMD 0
Oops: 0000 [#1] SMP
Modules linked in: ipv6(E) xt_REDIRECT(E) nf_nat_redirect(E) xt_tcpudp(E) iptable_nat(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E) nf_nat_ipv4(E) nf_nat(E) nf_conntrack(E) ip_tables(E) x_tables(E) binfmt_misc(E) xfs(E) libcrc32c(E) evbug(E) evdev(E) psmouse(E) i2c_piix4(E) i2c_core(E) acpi_cpufreq(E) button(E) ext4(E) crc16(E) jbd2(E) mbcache(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E)
CPU: 0 PID: 2536 Comm: ip Tainted: G            E   4.1.7-15.23.amzn1.x86_64 #1
Hardware name: Xen HVM domU, BIOS 4.2.amazon 05/06/2015
task: ffff8800eb438000 ti: ffff8803ba664000 task.ti: ffff8803ba664000
[...]
Call Trace:
 
 [] redirect_tg4+0x15/0x20 [xt_REDIRECT]
 [] ipt_do_table+0x2b9/0x5e1 [ip_tables]
 [] iptable_nat_do_chain+0x25/0x30 [iptable_nat]
 [] nf_nat_ipv4_fn+0x13d/0x1f0 [nf_nat_ipv4]
 [] ? iptable_nat_ipv4_fn+0x20/0x20 [iptable_nat]
 [] nf_nat_ipv4_in+0x2e/0x90 [nf_nat_ipv4]
 [] iptable_nat_ipv4_in+0x15/0x20 [iptable_nat]
 [] nf_iterate+0x57/0x80
 [] nf_hook_slow+0x97/0x100
 [] ip_rcv+0x314/0x400

unsigned int
nf_nat_redirect_ipv4(struct sk_buff *skb,
...
{
...
		rcu_read_lock();
		indev = __in_dev_get_rcu(skb->dev);
		if (indev != NULL) {
			ifa = indev->ifa_list;
			newdst = ifa->ifa_local; <---
		}
		rcu_read_unlock();
...
}

Before the commit, 'ifa' had been always checked before access. After the
commit, however, it could be accessed even if it's NULL. Interestingly,
this was once fixed in 2003.

http://marc.info/?l=netfilter-devel&m=106668497403047&w=2

In addition to the original one, we have seen the crash when packets that
need to be redirected somehow arrive on an interface which hasn't been
yet fully configured.

This change just reverts the logic to the old behavior to avoid the crash.

Fixes: 8b13eddfdf04 ("netfilter: refactor NAT redirect IPv4 to use it from nf_tables")
Signed-off-by: Munehisa Kamata 
Signed-off-by: Pablo Neira Ayuso

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2015-10-24T13:54:12+00:00

Conflicts:
	net/ipv6/xfrm6_output.c
	net/openvswitch/flow_netlink.c
	net/openvswitch/vport-gre.c
	net/openvswitch/vport-vxlan.c
	net/openvswitch/vport.c
	net/openvswitch/vport.h

The openvswitch conflicts were overlapping changes.  One was
the egress tunnel info fix in 'net' and the other was the
vport ->send() op simplification in 'net-next'.

The xfrm6_output.c conflicts was also a simplification
overlapping a bug fix.

Signed-off-by: David S. Miller

netfilter: xt_TEE: fix NULL dereference

2015-10-22T10:55:25+00:00

iptables -I INPUT ... -j TEE --gateway 10.1.2.3

 because --oif was not specified

tee_tg_check() sets ->priv pointer to NULL in this case.

Fixes: bbde9fc1824a ("netfilter: factor out packet duplication for IPv4/IPv6")
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-next

2015-10-17T12:28:03+00:00

This merge resolves conflicts with 75aec9df3a78 ("bridge: Remove
br_nf_push_frag_xmit_sk") as part of Eric Biederman's effort to improve
netns support in the network stack that reached upstream via David's
net-next tree.

Signed-off-by: Pablo Neira Ayuso 

Conflicts:
	net/bridge/br_netfilter_hooks.c

netfilter: ipset: Fix sleeping memory allocation in atomic context

2015-10-17T11:01:24+00:00

Commit 00590fdd5be0 introduced RCU locking in list type and in
doing so introduced a memory allocation in list_set_add, which
is done in an atomic context, due to the fact that ipset rcu
list modifications are serialised with a spin lock. The reason
why we can't use a mutex is that in addition to modifying the
list with ipset commands, it's also being modified when a
particular ipset rule timeout expires aka garbage collection.
This gc is triggered from set_cleanup_entries, which in turn
is invoked from a timer thus requiring the lock to be bh-safe.

Concretely the following call chain can lead to "sleeping function
called in atomic context" splat:
call_ad -> list_set_uadt -> list_set_uadd -> kzalloc(, GFP_KERNEL).
And since GFP_KERNEL allows initiating direct reclaim thus
potentially sleeping in the allocation path.

To fix the issue change the allocation type to GFP_ATOMIC, to
correctly reflect that it is occuring in an atomic context.

Fixes: 00590fdd5be0 ("netfilter: ipset: Introduce RCU locking in list type")
Signed-off-by: Nikolay Borisov 
Acked-by: Jozsef Kadlecsik 
Signed-off-by: Pablo Neira Ayuso

netfilter: nf_queue: remove rcu_read_lock calls

2015-10-16T16:22:41+00:00

All verdict handlers make use of the nfnetlink .call_rcu callback
so rcu readlock is already held.

Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso