linux-toradex.git/net/ipv6, branch v2.6.25.10

ipsec: Use the correct ip_local_out function

2008-06-16T20:19:55+00:00

[ upstream commit: 1ac06e0306d0192a7a4d9ea1c9e06d355ce7e7d3 ]

Because the IPsec output function xfrm_output_resume does its
own dst_output call it should always call __ip_local_output
instead of ip_local_output as the latter may invoke dst_output
directly.  Otherwise the return values from nf_hook and dst_output
may clash as they both use the value 1 but for different purposes.

When that clash occurs this can cause a packet to be used after
it has been freed which usually leads to a crash.  Because the
offending value is only returned from dst_output with qdiscs
such as HTB, this bug is normally not visible.

Thanks to Marco Berizzi for his perseverance in tracking this
down.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright

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

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

upstream commit: b9c698964614f71b9c8afeca163a945b4c2e2d20

[   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: 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

sit: Add missing kfree_skb() on pskb_may_pull() failure.

2008-05-10T04:40:53+00:00

[ Upstream commit: 36ca34cc3b8335eb1fe8bd9a1d0a2592980c3f02 ]

Noticed by Paul Marks .

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

[IPV6] ADDRCONF: Don't generate temporary address for ip6-ip6 interface.

2008-04-14T06:47:11+00:00

As far as I can remember, I was going to disable privacy extensions
on all "tunnel" interfaces.  Disable it on ip6-ip6 interface as well.

Also, just remove ifdefs for SIT for simplicity.

Signed-off-by: YOSHIFUJI Hideaki 
Signed-off-by: David S. Miller

[IPV6] ADDRCONF: Ensure disabling multicast RS even if privacy extensions are disabled.

2008-04-14T06:42:18+00:00

Signed-off-by: YOSHIFUJI Hideaki 
Signed-off-by: David S. Miller

[IPV6]: Fix ipv6 address fetching in raw6_icmp_error().

2008-04-14T06:14:15+00:00

Fixes kernel bugzilla 10437

Based almost entirely upon a patch by Dmitry Butskoy.

When deciding what raw sockets to deliver the ICMPv6
to, we should use the addresses in the ICMPv6 quoted
IPV6 header, not the top-level one.

Signed-off-by: David S. Miller

[IPV6]: Fix refcounting for anycast dst entries.

2008-04-03T20:33:00+00:00

Anycast DST entries allocated inside ipv6_dev_ac_inc are leaked when
network device is stopped without removing IPv6 addresses from it. The
bug has been observed in the reality on 2.6.18-rhel5 kernel.

In the above case addrconf_ifdown marks all entries as obsolete and
ip6_del_rt called from __ipv6_dev_ac_dec returns ENOENT. The
referrence is not dropped.

The fix is simple. DST entry should not keep referrence when stored in
the FIB6 tree.

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

[IPV6]: inet6_dev on loopback should be kept until namespace stop.

2008-04-03T20:31:53+00:00

In the other case it will be destroyed when last address will be removed
from lo inside a namespace. This will break IPv6 in several places. The
most obvious one is ip6_dst_ifdown.

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

[IPV6]: Event type in addrconf_ifdown is mis-used.

2008-04-03T20:30:17+00:00

addrconf_ifdown is broken in respect to the usage of how
parameter. This function is called with (event != NETDEV_DOWN) and (2)
on the IPv6 stop.  It the latter case inet6_dev from loopback device
should be destroyed.

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