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

Fix TCP MD5 on big-endian.

2007-11-02T15:44:11+00:00

changeset f8ab18d2d987a59ccbf0495032b2aef05b730037 in mainline.

Based upon a report and initial patch by Peter Lieven.

tcp4_md5sig_key and tcp6_md5sig_key need to start with
the exact same members as tcp_md5sig_key.  Because they
are both cast to that type by tcp_v{4,6}_md5_do_lookup().

Unfortunately tcp{4,6}_md5sig_key use a u16 for the key
length instead of a u8, which is what tcp_md5sig_key
uses.  This just so happens to work by accident on
little-endian, but on big-endian it doesn't.

Instead of casting, just place tcp_md5sig_key as the first member of
the address-family specific structures, adjust the access sites, and
kill off the ugly casts.

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

Fix ipv6 redirect processing, leads to TAHI failures.

2007-11-02T15:44:10+00:00

changeset bf0b48dfc368c07c42b5a3a5658c8ee81b4283ac from mainline.

When the ICMPv6 Target address is multicast, Linux processes the
redirect instead of dropping it.  The problem is in this code in
ndisc_redirect_rcv():

         if (ipv6_addr_equal(dest, target)) {
                 on_link = 1;
         } else if (!(ipv6_addr_type(target) & IPV6_ADDR_LINKLOCAL)) {
                 ND_PRINTK2(KERN_WARNING
                            "ICMPv6 Redirect: target address is not
link-local.\n");
                 return;
         }

This second check will succeed if the Target address is, for example,
FF02::1 because it has link-local scope.  Instead, it should be checking
if it's a unicast link-local address, as stated in RFC 2461/4861 Section
8.1:

       - The ICMP Target Address is either a link-local address (when
         redirected to a router) or the same as the ICMP Destination
         Address (when redirected to the on-link destination).

I know this doesn't explicitly say unicast link-local address, but it's
implied.

This bug is preventing Linux kernels from achieving IPv6 Logo Phase II
certification because of a recent error that was found in the TAHI test
suite - Neighbor Disovery suite test 206 (v6LC.2.3.6_G) had the
multicast address in the Destination field instead of Target field, so
we were passing the test.  This won't be the case anymore.

The patch below fixes this problem, and also fixes ndisc_send_redirect()
to not send an invalid redirect with a multicast address in the Target
field.  I re-ran the TAHI Neighbor Discovery section to make sure Linux
passes all 245 tests now.

Signed-off-by: Brian Haley 
Acked-by: David L Stevens 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Fix some cases of missed IPV6 DAD

2007-11-02T15:44:09+00:00

changeset 0fcace22d38ce9216f5ba52f929a99d284aa7e49 from mainline

To judge the timing for DAD, netif_carrier_ok() is used. However,
there is a possibility that dev->qdisc stays noop_qdisc even if
netif_carrier_ok() returns true. In that case, DAD NS is not sent out.
We need to defer the IPv6 device initialization until a valid qdisc
is specified.

Signed-off-by: Mitsuru Chinen 
Signed-off-by: YOSHIFUJI Hideaki 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Fix ipv6 source address handling.

2007-09-26T17:54:43+00:00

commit 6ae5f983cf8de769214d2d9e8a783c881eccd4cd in mainline

The commit 95c385 broke proper source address selection for cases in which
there is a address which is makred 'deprecated'. The commit mistakenly
changed ifa->flags to ifa_result->flags (probably copy/paste error from a
few lines above) in the 'Rule 3' address selection code.

The patch restores the previous RFC-compliant behavior.

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

Fix IPV6 DAD handling

2007-09-26T17:54:42+00:00

commit 9e3be4b34364a670bd6e57d2e8c3caabdd8d89f8 in mainline

addrconf_dad_failure calls addrconf_dad_stop which takes referenced address
and drops the count. So, in6_ifa_put perrformed at out: is extra. This
results in message: "Freeing alive inet6 address" and not released dst entries.

Signed-off-by: Denis V. Lunev 
Signed-off-by: Alexey Dobriyan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Fix ipv6 double-sock-release with MSG_CONFIRM

2007-09-26T17:54:42+00:00

commit 3ef9d943d26dea764f4fecf3767001c90b778b0c in mainline

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

Fix IPV6 append OOPS.

2007-09-26T17:54:42+00:00

commit e1f52208bb968291f7d9142eff60b62984b4a511 in mainline.

[IPv6]: Fix NULL pointer dereference in ip6_flush_pending_frames

Some of skbs in sk->write_queue do not have skb->dst because
we do not fill skb->dst when we allocate new skb in append_data().

BTW, I think we may not need to (or we should not) increment some stats
when using corking; if 100 sendmsg() (with MSG_MORE) result in 2 packets,
how many should we increment?

If 100, we should set skb->dst for every queued skbs.

If 1 (or 2 (*)), we increment the stats for the first queued skb and
we should just skip incrementing OutDiscards for the rest of queued skbs,
adn we should also impelement this semantics in other places;
e.g., we should increment other stats just once, not 100 times.

*: depends on the place we are discarding the datagram.

I guess should just increment by 1 (or 2).

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

TCP: Do not autobind ports for TCP sockets

2007-08-31T06:01:51+00:00

[TCP]: Invoke tcp_sendmsg() directly, do not use inet_sendmsg().

As discovered by Evegniy Polyakov, if we try to sendmsg after
a connection reset, we can do incredibly stupid things.

The core issue is that inet_sendmsg() tries to autobind the
socket, but we should never do that for TCP.  Instead we should
just go straight into TCP's sendmsg() code which will do all
of the necessary state and pending socket error checks.

TCP's sendpage already directly vectors to tcp_sendpage(), so this
merely brings sendmsg() in line with that.

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

IPv6: Invalid semicolon after if statement

2007-08-31T06:01:33+00:00

Author: Ilpo Järvinen 

A similar fix to netfilter from Eric Dumazet inspired me to
look around a bit by using some grep/sed stuff as looking for
this kind of bugs seemed easy to automate. This is one of them
I found where it looks like this semicolon is not valid.

Signed-off-by: Ilpo Järvinen 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

IPV6: Fix kernel panic while send SCTP data with IP fragments

2007-08-31T06:01:01+00:00

If ICMP6 message with "Packet Too Big" is received after send SCTP DATA,
kernel panic will occur when SCTP DATA is send again.

This is because of a bad dest address when call to skb_copy_bits().

The messages sequence is like this:

Endpoint A                             Endpoint B
                               <-------  SCTP DATA (size=1432)
ICMP6 message ------->
(Packet Too Big pmtu=1280)
                               <-------  Resend SCTP DATA (size=1432)
------------kernel panic---------------

 printing eip:
c05be62a
*pde = 00000000
Oops: 0002 [#1]
SMP
Modules linked in: scomm l2cap bluetooth ipv6 dm_mirror dm_mod video output sbs battery lp floppy sg i2c_piix4 i2c_core pcnet32 mii button ac parport_pc parport ide_cd cdrom serio_raw mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
CPU:    0
EIP:    0060:[]    Not tainted VLI
EFLAGS: 00010282   (2.6.23-rc2 #1)
EIP is at skb_copy_bits+0x4f/0x1ef
eax: 000004d0   ebx: ce12a980   ecx: 00000134   edx: cfd5a880
esi: c8246858   edi: 00000000   ebp: c0759b14   esp: c0759adc
ds: 007b   es: 007b   fs: 00d8  gs: 0000  ss: 0068
Process swapper (pid: 0, ti=c0759000 task=c06d0340 task.ti=c0713000)
Stack: c0759b88 c0405867 ce12a980 c8bff838 c789c084 00000000 00000028 cfd5a880
       d09f1890 000005dc 0000007b ce12a980 cfd5a880 c8bff838 c0759b88 d09bc521
       000004d0 fffff96c 00000200 00000100 c0759b50 cfd5a880 00000246 c0759bd4
Call Trace:
 [] show_trace_log_lvl+0x1a/0x2f
 [] show_stack_log_lvl+0x9b/0xa3
 [] show_registers+0x1b8/0x289
 [] die+0x113/0x246
 [] do_page_fault+0x4ad/0x57e
 [] error_code+0x72/0x78
 [] ip6_output+0x8e5/0xab2 [ipv6]
 [] ip6_xmit+0x2ea/0x3a3 [ipv6]
 [] sctp_v6_xmit+0x248/0x253 [sctp]
 [] sctp_packet_transmit+0x53f/0x5ae [sctp]
 [] sctp_outq_flush+0x555/0x587 [sctp]
 [] sctp_retransmit+0xf8/0x10f [sctp]
 [] sctp_icmp_frag_needed+0x57/0x5b [sctp]
 [] sctp_v6_err+0xcd/0x148 [sctp]
 [] icmpv6_notify+0xe6/0x167 [ipv6]
 [] icmpv6_rcv+0x7d7/0x849 [ipv6]
 [] ip6_input+0x1dc/0x310 [ipv6]
 [] ipv6_rcv+0x294/0x2df [ipv6]
 [] netif_receive_skb+0x2d2/0x335
 [] process_backlog+0x7f/0xd0
 [] net_rx_action+0x96/0x17e
 [] __do_softirq+0x64/0xcd
 [] do_softirq+0x5c/0xac
 =======================
Code: 00 00 29 ca 89 d0 2b 45 e0 89 55 ec 85 c0 7e 35 39 45 08 8b 55 e4 0f 4e 45 08 8b 75 e0 8b 7d dc 89 c1 c1 e9 02 03 b2 a0 00 00 00  a5 89 c1 83 e1 03 74 02 f3 a4 29 45 08 0f 84 7b 01 00 00 01
EIP: [] skb_copy_bits+0x4f/0x1ef SS:ESP 0068:c0759adc
Kernel panic - not syncing: Fatal exception in interrupt

Arnaldo says:
====================
Thanks! I'm to blame for this one, problem was introduced in:

b0e380b1d8a8e0aca215df97702f99815f05c094

                /*
                 *      Copy a block of the IP datagram.
                 */
-               if (skb_copy_bits(skb, ptr, frag->h.raw, len))
+               if (skb_copy_bits(skb, ptr, skb_transport_header(skb),
len))
                        BUG();
                left -= len;
====================

Signed-off-by: Wei Yongjun 
Acked-by: YOSHIFUJI Hideaki 
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman