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

[PATCH] IPV6: fix lockup via /proc/net/ip6_flowlabel [CVE-2006-5619]

2006-11-04T01:33:50+00:00

There's a bug in the seqfile handling for /proc/net/ip6_flowlabel, where,
after finding a flowlabel, the code will loop forever not finding any
further flowlabels, first traversing the rest of the hash bucket then just
looping.

This patch fixes the problem by breaking after the hash bucket has been
traversed.

Note that this bug can cause lockups and oopses, and is trivially invoked
by an unpriveleged user.

Signed-off-by: James Morris 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright

IPV6: Disable SG for GSO unless we have checksum

2006-10-13T20:23:27+00:00

Because the system won't turn off the SG flag for us we
need to do this manually on the IPv6 path.  Otherwise we
will throw IPv6 packets with bad checksums at the hardware.

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

IPV6: bh_lock_sock_nested on tcp_v6_rcv

2006-10-13T20:23:26+00:00

A while ago Ingo patched tcp_v4_rcv on net/ipv4/tcp_ipv4.c to use
bh_lock_sock_nested and silence a lock validator warning. This fixed
it for IPv4, but recently I saw a report of the same warning on IPv6.

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

[IPV6]: Accept -1 for IPV6_TCLASS

2006-09-18T06:21:08+00:00

This patch should add support for -1 as "default" IPv6 traffic class,
as specified in IETF RFC3542 §6.5. Within the kernel, it seems tclass
< 0 is already handled, but setsockopt, getsockopt and recvmsg calls
won't accept it from userland.

Signed-off-by: Remi Denis-Courmont 
Acked-by: YOSHIFUJI Hideaki 
Signed-off-by: David S. Miller

[IPV6]: Fix tclass setting for raw sockets.

2006-09-18T06:21:07+00:00

np->cork.tclass is used only in cork'ed context.
Otherwise, np->tclass should be used.

Bug#7096 reported by Remi Denis-Courmont .

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

[IPV6]: Fix kernel OOPs when setting sticky socket options.

2006-08-31T21:52:17+00:00

Bug noticed by Remi Denis-Courmont .

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

[IPV6]: ipv6_add_addr should install dstentry earlier

2006-08-30T04:22:18+00:00

ipv6_add_addr allocates a struct inet6_ifaddr and a dstentry, but it
doesn't install the dstentry in ifa->rt until after it releases the
addrconf_hash_lock. This means other CPUs will be able to see the new
address while it hasn't been initialized completely yet.

One possible fix would be to grab the ifp->lock spinlock when
creating the address struct; a simpler fix is to just move the
assignment.

Acked-by: jbeulich@novell.com
Acked-by: okir@suse.de
Acked-by: YOSHIFUJI Hideaki 
Signed-off-by: David S. Miller

[IPV6]: SNMPv2 "ipv6IfStatsInAddrErrors" counter error

2006-08-30T04:22:15+00:00

   When I tested Linux kernel 2.6.17.7 about statistics
"ipv6IfStatsInAddrErrors", found that this counter couldn't increase
correctly. The criteria is RFC2465:
 ipv6IfStatsInAddrErrors OBJECT-TYPE
      SYNTAX      Counter32
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
         "The number of input datagrams discarded because
         the IPv6 address in their IPv6 header's destination
         field was not a valid address to be received at
         this entity.  This count includes invalid
         addresses (e.g., ::0) and unsupported addresses
         (e.g., addresses with unallocated prefixes).  For
         entities which are not IPv6 routers and therefore
         do not forward datagrams, this counter includes
         datagrams discarded because the destination address
         was not a local address."
      ::= { ipv6IfStatsEntry 5 }

When I send packet to host with destination that is ether invalid
address(::0) or unsupported addresses(1::1), the Linux kernel just
discard the packet, and the counter doesn't increase(in the function
ip6_pkt_discard).

Signed-off-by: Lv Liangying 
Signed-off-by: David S. Miller

[IPV6]: Segmentation offload not set correctly on TCP children

2006-08-27T01:42:01+00:00

TCP over IPV6 would incorrectly inherit the GSO settings.
This would cause kernel to send Tcp Segmentation Offload packets for
IPV6 data to devices that can't handle it. It caused the sky2 driver
to lock http://bugzilla.kernel.org/show_bug.cgi?id=7050
and the e1000 would generate bogus packets. I can't blame the
hardware for gagging if the upper layers feed it garbage.

This was a new bug in 2.6.18 introduced with GSO support.

Signed-off-by: Stephen Hemminger 
Signed-off-by: David S. Miller

[MCAST]: Fix filter leak on device removal.

2006-08-17T23:29:57+00:00

This fixes source filter leakage when a device is removed and a
process leaves the group thereafter.

This also includes corresponding fixes for IPv6 multicast source
filters on device removal.

Signed-off-by: David L Stevens 
Signed-off-by: David S. Miller