linux-stable.git/net/ipv4/netfilter, branch linux-2.6.26.y

netfilter: restore lost ifdef guarding defrag exception

2008-11-10T19:18:02+00:00

netfilter: restore lost #ifdef guarding defrag exception

Upstream commit 38f7ac3eb:

Nir Tzachar  reported a warning when sending
fragments over loopback with NAT:

[ 6658.338121] WARNING: at net/ipv4/netfilter/nf_nat_standalone.c:89 nf_nat_fn+0x33/0x155()

The reason is that defragmentation is skipped for already tracked connections.
This is wrong in combination with NAT and ip_conntrack actually had some ifdefs
to avoid this behaviour when NAT is compiled in.

The entire "optimization" may seem a bit silly, for now simply restoring the
lost #ifdef is the easiest solution until we can come up with something better.

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

netfilter: snmp nat leaks memory in case of failure

2008-11-10T19:18:02+00:00

netfilter: snmp nat leaks memory in case of failure

Upstream commit 311670f3e:

Signed-off-by: Ilpo Jarvinen 
Signed-off-by: Patrick McHardy

netfilter: nf_nat_sip: c= is optional for session

2008-08-06T16:03:10+00:00

netfilter: nf_nat_sip: c= is optional for session

Upstream commit c71529e4:

According to RFC2327, the connection information is optional
in the session description since it can be specified in the
media description instead.

My provider does exactly that and does not provide any connection
information in the session description.  As a result the new
kernel drops all invite responses.

This patch makes it optional as documented.

Signed-off-by: Herbert Xu 
Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

netfilter: nf_nat_snmp_basic: fix a range check in NAT for SNMP

2008-07-09T22:06:45+00:00

Fix a range check in netfilter IP NAT for SNMP to always use a big enough size
variable that the compiler won't moan about comparing it to ULONG_MAX/8 on a
64-bit platform.

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

netfilter: nf_nat: fix RCU races

2008-06-17T22:51:47+00:00

Fix three ct_extend/NAT extension related races:

- When cleaning up the extension area and removing it from the bysource hash,
  the nat->ct pointer must not be set to NULL since it may still be used in
  a RCU read side

- When replacing a NAT extension area in the bysource hash, the nat->ct
  pointer must be assigned before performing the replacement

- When reallocating extension storage in ct_extend, the old memory must
  not be freed immediately since it may still be used by a RCU read side

Possibly fixes https://bugzilla.redhat.com/show_bug.cgi?id=449315
and/or http://bugzilla.kernel.org/show_bug.cgi?id=10875

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

asn1: additional sanity checking during BER decoding

2008-06-05T21:24:54+00:00

- Don't trust a length which is greater than the working buffer.
  An invalid length could cause overflow when calculating buffer size
  for decoding oid.

- An oid length of zero is invalid and allows for an off-by-one error when
  decoding oid because the first subid actually encodes first 2 subids.

- A primitive encoding may not have an indefinite length.

Thanks to Wei Wang from McAfee for report.

Cc: Steven French 
Cc: stable@kernel.org
Acked-by: Patrick McHardy 
Signed-off-by: Chris Wright 
Signed-off-by: Linus Torvalds

netfilter: assign PDE->data before gluing PDE into /proc tree

2008-05-02T09:45:42+00:00

Simply replace proc_create and further data assigned with proc_create_data.

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

netfilter: nf_conntrack: padding breaks conntrack hash on ARM

2008-04-29T10:35:10+00:00

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: 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: Fix SCTP nat build.

2008-04-20T00:52:51+00:00

We need to select LIBCRC32C.

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