linux-toradex.git/net/netfilter, branch v2.6.25.7

netfilter: xt_connlimit: fix accouning when receive RST packet in ESTABLISHED state

2008-06-09T18:27:04+00:00

upstream commit: d2ee3f2c4b1db1320c1efb4dcaceeaf6c7e6c2d3

In xt_connlimit match module, the counter of an IP is decreased when
the TCP packet is go through the chain with ip_conntrack state TW.
Well, it's very natural that the server and client close the socket
with FIN packet. But when the client/server close the socket with RST
packet(using so_linger), the counter for this connection still exsit.
The following patch can fix it which is based on linux-2.6.25.4

Signed-off-by: Dong Wei 
Acked-by: Jan Engelhardt 
Signed-off-by: Patrick McHardy 
Signed-off-by: Chris Wright

netfilter: nf_conntrack_expect: fix error path unwind in nf_conntrack_expect_init()

2008-06-09T18:27:04+00:00

upstream commit: 12293bf91126ad253a25e2840b307fdc7c2754c3

Signed-off-by: Alexey Dobriyan 
Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright

netfilter: xt_iprange: module aliases for xt_iprange

2008-06-09T18:27:03+00:00

upstream commit: 01b7a314291b2ef56ad718ee1374a1bac4768b29 

Using iptables 1.3.8 with kernel 2.6.25, rules which include '-m
iprange' don't automatically pull in xt_iprange module.  Below patch
adds module aliases to fix that.  Patch against latest -git, but seems
like a good candidate for -stable also.

Signed-off-by: Phil Oester 
Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright

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

2008-05-15T14:50:04+00:00

[NETFILTER]: {nfnetlink,ip,ip6}_queue: fix skb_over_panic when enlarging packets

From: Arnaud Ebalard 

Upstream commit 9a732ed6d:

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 
Signed-off-by: Greg Kroah-Hartman

nf_conntrack: padding breaks conntrack hash on ARM

2008-05-15T14:50:03+00:00

[NETFILTER]: nf_conntrack: padding breaks conntrack hash on ARM

Upstream commit 443a70d50:

commit 0794935e "[NETFILTER]: nf_conntrack: optimize hash_conntrack()"
results in ARM platforms hashing uninitialised padding.  This padding
doesn't exist on other architectures.

Fix this by replacing NF_CT_TUPLE_U_BLANK() with memset() to ensure
everything is initialised.  There were only 4 bytes that
NF_CT_TUPLE_U_BLANK() wasn't clearing anyway (or 12 bytes on ARM).

Signed-off-by: Philip Craig 
Signed-off-by: Patrick McHardy 
Signed-off-by: Greg Kroah-Hartman

[NETFILTER]: xt_hashlimit: fix mask calculation

2008-04-09T22:14:18+00:00

Shifts larger than the data type are undefined, don't try to shift
an u32 by 32. Also remove some special-casing of bitmasks divisible
by 32.

Based on patch by Jan Engelhardt .

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

[NETFILTER]: Replate direct proc_fops assignment with proc_create call.

2008-03-27T23:55:53+00:00

This elliminates infamous race during module loading when one could lookup
proc entry without proc_fops assigned.

Signed-off-by: Denis V. Lunev 
Signed-off-by: David S. Miller

[NETFILTER]: nf_conntrack_h323: logical-bitwise & confusion in process_setup()

2008-03-20T22:06:23+00:00

logical-bitwise & confusion

Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller

[NETFILTER]: nf_queue: don't return error when unregistering a non-existant handler

2008-03-10T23:45:05+00:00

Commit ce7663d84:

[NETFILTER]: nfnetlink_queue: don't unregister handler of other subsystem

changed nf_unregister_queue_handler to return an error when attempting to
unregister a queue handler that is not identical to the one passed in.
This is correct in case we really do have a different queue handler already
registered, but some existing userspace code always does an unbind before
bind and aborts if that fails, so try to be nice and return success in
that case.

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

[NETFILTER]: nfnetlink_queue: fix EPERM when binding/unbinding and instance 0 exists

2008-03-10T23:44:36+00:00

Similar to the nfnetlink_log problem, nfnetlink_queue incorrectly
returns -EPERM when binding or unbinding to an address family and
queueing instance 0 exists and is owned by a different process. Unlike
nfnetlink_log it previously completes the operation, but it is still
incorrect.

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