linux.git/net/ipv6/netfilter, branch v2.6.26-rc7

netfilter: nf_conntrack_ipv6: fix inconsistent lock state in nf_ct_frag6_gather()

2008-06-04T16:58:27+00:00

[   63.531438] =================================
[   63.531520] [ INFO: inconsistent lock state ]
[   63.531520] 2.6.26-rc4 #7
[   63.531520] ---------------------------------
[   63.531520] inconsistent {softirq-on-W} -> {in-softirq-W} usage.
[   63.531520] tcpsic6/3864 [HC0[0]:SC1[1]:HE1:SE0] takes:
[   63.531520]  (&q->lock#2){-+..}, at: [] ipv6_frag_rcv+0xd0/0xbd0
[   63.531520] {softirq-on-W} state was registered at:
[   63.531520]   [] __lock_acquire+0x3aa/0x1080
[   63.531520]   [] lock_acquire+0x76/0xa0
[   63.531520]   [] _spin_lock+0x2b/0x40
[   63.531520]   [] nf_ct_frag6_gather+0x3f6/0x910
 ...

According to this and another similar lockdep report inet_fragment
locks are taken from nf_ct_frag6_gather() with softirqs enabled, but
these locks are mainly used in softirq context, so disabling BHs is
necessary.

Reported-and-tested-by: Eric Sesterhenn 
Signed-off-by: Jarek Poplawski 
Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller

netfilter: {nfnetlink,ip,ip6}_queue: fix skb_over_panic when enlarging packets

2008-04-29T10:16:34+00:00

While reinjecting *bigger* modified versions of IPv6 packets using
libnetfilter_queue, things work fine on a 2.6.24 kernel (2.6.22 too)
but I get the following on recents kernels (2.6.25, trace below is
against today's net-2.6 git tree):

skb_over_panic: text:c04fddb0 len:696 put:632 head:f7592c00 data:f7592c00 tail:0xf7592eb8 end:0xf7592e80 dev:eth0
------------[ cut here ]------------
invalid opcode: 0000 [#1] PREEMPT 
Process sendd (pid: 3657, ti=f6014000 task=f77c31d0 task.ti=f6014000)
Stack: c071e638 c04fddb0 000002b8 00000278 f7592c00 f7592c00 f7592eb8 f7592e80 
       f763c000 f6bc5200 f7592c40 f6015c34 c04cdbfc f6bc5200 00000278 f6015c60 
       c04fddb0 00000020 f72a10c0 f751b420 00000001 0000000a 000002b8 c065582c 
Call Trace:
 [] ? nfqnl_recv_verdict+0x1c0/0x2e0
 [] ? skb_put+0x3c/0x40
 [] ? nfqnl_recv_verdict+0x1c0/0x2e0
 [] ? nfnetlink_rcv_msg+0xf5/0x160
 [] ? nfnetlink_rcv_msg+0x1e/0x160
 [] ? nfnetlink_rcv_msg+0x0/0x160
 [] ? netlink_rcv_skb+0x77/0xa0
 [] ? nfnetlink_rcv+0x1c/0x30
 [] ? netlink_unicast+0x243/0x2b0
 [] ? memcpy_fromiovec+0x4a/0x70
 [] ? netlink_sendmsg+0x1c6/0x270
 [] ? sock_sendmsg+0xc4/0xf0
 [] ? set_next_entity+0x1d/0x50
 [] ? autoremove_wake_function+0x0/0x40
 [] ? __wake_up_common+0x3e/0x70
 [] ? n_tty_receive_buf+0x34f/0x1280
 [] ? __wake_up+0x68/0x70
 [] ? copy_from_user+0x37/0x70
 [] ? verify_iovec+0x2c/0x90
 [] ? sys_sendmsg+0x10a/0x230
 [] ? __dequeue_entity+0x2a/0xa0
 [] ? set_next_entity+0x1d/0x50
 [] ? pty_write+0x47/0x60
 [] ? tty_default_put_char+0x1b/0x20
 [] ? __wake_up+0x49/0x70
 [] ? tty_ldisc_deref+0x39/0x90
 [] ? tty_write+0x1a0/0x1b0
 [] ? sys_socketcall+0x7f/0x260
 [] ? sysenter_past_esp+0x6a/0x91
 [] ? snd_intel8x0m_probe+0x270/0x6e0
 =======================
Code: 00 00 89 5c 24 14 8b 98 9c 00 00 00 89 54 24 0c 89 5c 24 10 8b 40 50 89 4c 24 04 c7 04 24 38 e6 71 c0 89 44 24 08 e8 c4 46 c5 ff <0f> 0b eb fe 55 89 e5 56 89 d6 53 89 c3 83 ec 0c 8b 40 50 39 d0 
EIP: [] skb_over_panic+0x5c/0x60 SS:ESP 0068:f6015bf8


Looking at the code, I ended up in nfq_mangle() function (called by
nfqnl_recv_verdict()) which performs a call to skb_copy_expand() due to
the increased size of data passed to the function. AFAICT, it should ask
for 'diff' instead of 'diff - skb_tailroom(e->skb)'. Because the
resulting sk_buff has not enough space to support the skb_put(skb, diff)
call a few lines later, this results in the call to skb_over_panic().

The patch below asks for allocation of a copy with enough space for
mangled packet and the same amount of headroom as old sk_buff. While
looking at how the regression appeared (e2b58a67), I noticed the same
pattern in ipq_mangle_ipv6() and ipq_mangle_ipv4(). The patch corrects
those locations too.

Tested with bigger reinjected IPv6 packets (nfqnl_mangle() path), things
are ok (2.6.25 and today's net-2.6 git tree).

Signed-off-by: Arnaud Ebalard 
Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller

[NETFILTER]: nf_conntrack: replace NF_CT_DUMP_TUPLE macro indrection by function call

2008-04-14T09:15:54+00:00

Directly call IPv4 and IPv6 variants where the address family is
easily known.

Signed-off-by: Jan Engelhardt 
Signed-off-by: Patrick McHardy

[NETFILTER]: nf_conntrack: use bool type in struct nf_conntrack_l4proto

2008-04-14T09:15:53+00:00

Signed-off-by: Jan Engelhardt 
Signed-off-by: Patrick McHardy

[NETFILTER]: nf_conntrack: use bool type in struct nf_conntrack_l3proto

2008-04-14T09:15:52+00:00

Signed-off-by: Jan Engelhardt 
Signed-off-by: Patrick McHardy

[NETFILTER]: {ip,ip6,arp}_tables: return EAGAIN for invalid SO_GET_ENTRIES size

2008-04-14T09:15:45+00:00

Rule dumping is performed in two steps: first userspace gets the
ruleset size using getsockopt(SO_GET_INFO) and allocates memory,
then it calls getsockopt(SO_GET_ENTRIES) to actually dump the
ruleset. When another process changes the ruleset in between the
sizes from the first getsockopt call doesn't match anymore and
the kernel aborts. Unfortunately it returns EAGAIN, as for multiple
other possible errors, so userspace can't distinguish this case
from real errors.

Return EAGAIN so userspace can retry the operation.

Fixes (with current iptables SVN version) netfilter bugzilla #104.

Signed-off-by: Patrick McHardy

[NETFILTER]: annotate rest of nf_conntrack_* with const

2008-04-14T09:15:42+00:00

Signed-off-by: Jan Engelhardt 
Signed-off-by: Patrick McHardy

[NETFILTER]: annotate {arp,ip,ip6,x}tables with const

2008-04-14T09:15:35+00:00

Signed-off-by: Jan Engelhardt 
Signed-off-by: Patrick McHardy

[NETFILTER]: annotate xtables targets with const and remove casts

2008-04-14T07:56:05+00:00

Signed-off-by: Jan Engelhardt 
Signed-off-by: Patrick McHardy

[NETFILTER]: Use non-deprecated __RW_LOCK_UNLOCKED macro

2008-04-14T07:56:03+00:00

Signed-off-by: Robert P. J. Day 
Signed-off-by: Patrick McHardy