summaryrefslogtreecommitdiff
path: root/net
AgeCommit message (Collapse)AuthorFilesLines
2007-11-21Fix crypto_alloc_comp() error checking.Herbert Xu2-2/+4
[IPSEC]: Fix crypto_alloc_comp error checking [ Upstream commit: 4999f3621f4da622e77931b3d33ada6c7083c705 ] The function crypto_alloc_comp returns an errno instead of NULL to indicate error. So it needs to be tested with IS_ERR. This is based on a patch by Vicenç Beltran Querol. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-21Fix endianness bug in U32 classifier.Radu Rendec1-2/+2
changeset 543821c6f5dea5221426eaf1eac98b100249c7ac in mainline. [PKT_SCHED] CLS_U32: Fix endianness problem with u32 classifier hash masks. While trying to implement u32 hashes in my shaping machine I ran into a possible bug in the u32 hash/bucket computing algorithm (net/sched/cls_u32.c). The problem occurs only with hash masks that extend over the octet boundary, on little endian machines (where htonl() actually does something). Let's say that I would like to use 0x3fc0 as the hash mask. This means 8 contiguous "1" bits starting at b6. With such a mask, the expected (and logical) behavior is to hash any address in, for instance, 192.168.0.0/26 in bucket 0, then any address in 192.168.0.64/26 in bucket 1, then 192.168.0.128/26 in bucket 2 and so on. This is exactly what would happen on a big endian machine, but on little endian machines, what would actually happen with current implementation is 0x3fc0 being reversed (into 0xc03f0000) by htonl() in the userspace tool and then applied to 192.168.x.x in the u32 classifier. When shifting right by 16 bits (rank of first "1" bit in the reversed mask) and applying the divisor mask (0xff for divisor 256), what would actually remain is 0x3f applied on the "168" octet of the address. One could say is this can be easily worked around by taking endianness into account in userspace and supplying an appropriate mask (0xfc03) that would be turned into contiguous "1" bits when reversed (0x03fc0000). But the actual problem is the network address (inside the packet) not being converted to host order, but used as a host-order value when computing the bucket. Let's say the network address is written as n31 n30 ... n0, with n0 being the least significant bit. When used directly (without any conversion) on a little endian machine, it becomes n7 ... n0 n8 ..n15 etc in the machine's registers. Thus bits n7 and n8 would no longer be adjacent and 192.168.64.0/26 and 192.168.128.0/26 would no longer be consecutive. The fix is to apply ntohl() on the hmask before computing fshift, and in u32_hash_fold() convert the packet data to host order before shifting down by fshift. With helpful feedback from Jamal Hadi Salim and Jarek Poplawski. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-21Fix error returns in sys_socketpair()David Miller1-1/+4
patch bf3c23d171e35e6e168074a1514b0acd59cfd81a in mainline. [NET]: Fix error reporting in sys_socketpair(). If either of the two sock_alloc_fd() calls fail, we forget to update 'err' and thus we'll erroneously return zero in these cases. Based upon a report and patch from Rich Paul, and commentary from Chuck Ebbert. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-21Fix netlink timeouts.Patrick McHardy1-5/+5
[NETLINK]: Fix unicast timeouts [ Upstream commit: c3d8d1e30cace31fed6186a4b8c6b1401836d89c ] Commit ed6dcf4a in the history.git tree broke netlink_unicast timeouts by moving the schedule_timeout() call to a new function that doesn't propagate the remaining timeout back to the caller. This means on each retry we start with the full timeout again. ipc/mqueue.c seems to actually want to wait indefinitely so this behaviour is retained. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-21Fix TEQL oops.Evgeniy Polyakov1-0/+3
[PKT_SCHED]: Fix OOPS when removing devices from a teql queuing discipline [ Upstream commit: 4f9f8311a08c0d95c70261264a2b47f2ae99683a ] tecl_reset() is called from deactivate and qdisc is set to noop already, but subsequent teql_xmit does not know about it and dereference private data as teql qdisc and thus oopses. not catch it first :) Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-21NETFILTER: nf_conntrack_tcp: fix connection reopeningJozsef Kadlecsik1-21/+17
Upstream commits: 17311393 + bc34b841 merged together. Merge done by Patrick McHardy <kaber@trash.net> [NETFILTER]: nf_conntrack_tcp: fix connection reopening With your description I could reproduce the bug and actually you were completely right: the code above is incorrect. Somehow I was able to misread RFC1122 and mixed the roles :-(: When a connection is >>closed actively<<, it MUST linger in TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime). However, it MAY >>accept<< a new SYN from the remote TCP to reopen the connection directly from TIME-WAIT state, if it: [...] The fix is as follows: if the receiver initiated an active close, then the sender may reopen the connection - otherwise try to figure out if we hold a dead connection. Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> Tested-by: Krzysztof Piotr Oledzki <ole@ans.pl> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-16TCP: Make sure write_queue_from does not begin with NULL ptr (CVE-2007-5501)Ilpo Järvinen1-0/+5
patch 96a2d41a3e495734b63bff4e5dd0112741b93b38 in mainline. NULL ptr can be returned from tcp_write_queue_head to cached_skb and then assigned to skb if packets_out was zero. Without this, system is vulnerable to a carefully crafted ACKs which obviously is remotely triggerable. Besides, there's very little that needs to be done in sacktag if there weren't any packets outstanding, just skipping the rest doesn't hurt. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-02Add get_unaligned to ieee80211_get_radiotap_lenAndy Green1-1/+2
patch dfe6e81deaa79c85086c0cc8d85b229e444ab97f in mainline. ieee80211_get_radiotap_len() tries to dereference radiotap length without taking care that it is completely unaligned and get_unaligned() is required. Signed-off-by: Andy Green <andy@warmcat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-02mac80211: filter locally-originated multicast framesJohn W. Linville1-2/+3
patch b331615722779b078822988843ddffd4eaec9f83 in mainline. In STA mode, the AP will echo our traffic. This includes multicast traffic. Receiving these frames confuses some protocols and applications, notably IPv6 Duplicate Address Detection. Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Acked-by: Michael Wu <flamingice@sourmilk.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-02Fix TCP MD5 on big-endian.David Miller2-19/+18
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 <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-02Fix TCP's ->fastpath_cnt_hit handling.Ilpo Järvinen1-0/+3
changeset 48611c47d09023d9356e78550d1cadb8d61da9c8 in mainline. When only GSO skb was partially ACKed, no hints are reset, therefore fastpath_cnt_hint must be tweaked too or else it can corrupt fackets_out. The corruption to occur, one must have non-trivial ACK/SACK sequence, so this bug is not very often that harmful. There's a fackets_out state reset in TCP because fackets_out is known to be inaccurate and that fixes the issue eventually anyway. In case there was also at least one skb that got fully ACKed, the fastpath_skb_hint is set to NULL which causes a recount for fastpath_cnt_hint (the old value won't be accessed anymore), thus it can safely be decremented without additional checking. Reported by Cedric Le Goater <clg@fr.ibm.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-02Fix zero length socket write() semantics.David S. Miller1-3/+0
changeset e79ad711a0108475c1b3a03815527e7237020b08 from mainline. This fixes kernel bugzilla #5731 It should generate an empty packet for datagram protocols when the socket is connected, for one. The check is doubly-wrong because all that a write() can be is a sendmsg() call with a NULL msg_control and a single entry iovec. No special semantics should be assigned to it, therefore the zero length check should be removed entirely. This matches the behavior of BSD and several other systems. Alan Cox notes that SuSv3 says the behavior of a zero length write on non-files is "unspecified", but that's kind of useless since BSD has defined this behavior for a quarter century and BSD is essentially what application folks code to. Based upon a patch from Stephen Hemminger. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-02Fix ROSE module unload oops.Alexey Dobriyan2-7/+12
changeset 891e6a931255238dddd08a7b306871240961a27f from mainline. Commit a3d384029aa304f8f3f5355d35f0ae274454f7cd aka "[AX.25]: Fix unchecked rose_add_loopback_neigh uses" transformed rose_loopback_neigh var into statically allocated one. However, on unload it will be kfree's which can't work. Steps to reproduce: modprobe rose rmmod rose BUG: unable to handle kernel NULL pointer dereference at virtual address 00000008 printing eip: c014c664 *pde = 00000000 Oops: 0000 [#1] PREEMPT DEBUG_PAGEALLOC Modules linked in: rose ax25 fan ufs loop usbhid rtc snd_intel8x0 snd_ac97_codec ehci_hcd ac97_bus uhci_hcd thermal usbcore button processor evdev sr_mod cdrom CPU: 0 EIP: 0060:[<c014c664>] Not tainted VLI EFLAGS: 00210086 (2.6.23-rc9 #3) EIP is at kfree+0x48/0xa1 eax: 00000556 ebx: c1734aa0 ecx: f6a5e000 edx: f7082000 esi: 00000000 edi: f9a55d20 ebp: 00200287 esp: f6a5ef28 ds: 007b es: 007b fs: 0000 gs: 0033 ss: 0068 Process rmmod (pid: 1823, ti=f6a5e000 task=f7082000 task.ti=f6a5e000) Stack: f9a55d20 f9a5200c 00000000 00000000 00000000 f6a5e000 f9a5200c f9a55a00 00000000 bf818cf0 f9a51f3f f9a55a00 00000000 c0132c60 65736f72 00000000 f69f9630 f69f9528 c014244a f6a4e900 00200246 f7082000 c01025e6 00000000 Call Trace: [<f9a5200c>] rose_rt_free+0x1d/0x49 [rose] [<f9a5200c>] rose_rt_free+0x1d/0x49 [rose] [<f9a51f3f>] rose_exit+0x4c/0xd5 [rose] [<c0132c60>] sys_delete_module+0x15e/0x186 [<c014244a>] remove_vma+0x40/0x45 [<c01025e6>] sysenter_past_esp+0x8f/0x99 [<c012bacf>] trace_hardirqs_on+0x118/0x13b [<c01025b6>] sysenter_past_esp+0x5f/0x99 ======================= Code: 05 03 1d 80 db 5b c0 8b 03 25 00 40 02 00 3d 00 40 02 00 75 03 8b 5b 0c 8b 73 10 8b 44 24 18 89 44 24 04 9c 5d fa e8 77 df fd ff <8b> 56 08 89 f8 e8 84 f4 fd ff e8 bd 32 06 00 3b 5c 86 60 75 0f EIP: [<c014c664>] kfree+0x48/0xa1 SS:ESP 0068:f6a5ef28 Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-02Fix ipv6 redirect processing, leads to TAHI failures.Brian Haley1-4/+5
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 <brian.haley@hp.com> Acked-by: David L Stevens <dlstevens@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-02Fix some cases of missed IPV6 DADMitsuru Chinen1-3/+10
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 <mitch@linux.vnet.ibm.com> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-02Fix ieee80211 handling of bogus hdrlength fieldJohn W. Linville1-0/+6
changeset 04045f98e0457aba7d4e6736f37eed189c48a5f7 from mainline Reported by Chris Evans <scarybeasts@gmail.com>: > The summary is that an evil 80211 frame can crash out a victim's > machine. It only applies to drivers using the 80211 wireless code, and > only then to certain drivers (and even then depends on a card's > firmware not dropping a dubious packet). I must confess I'm not > keeping track of Linux wireless support, and the different protocol > stacks etc. > > Details are as follows: > > ieee80211_rx() does not explicitly check that "skb->len >= hdrlen". > There are other skb->len checks, but not enough to prevent a subtle > off-by-two error if the frame has the IEEE80211_STYPE_QOS_DATA flag > set. > > This leads to integer underflow and crash here: > > if (frag != 0) > flen -= hdrlen; > > (flen is subsequently used as a memcpy length parameter). How about this? Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-11-02Fix cls_u32 error return handling.Stephen Hemminger1-1/+1
changeset bf1b803b01b00c3801e0aa373ba0305f8278e260 from mainline. Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-09-26Fix pktgen src_mac handling.Adit Ranadive1-0/+10
commit ce5d0b47f13f83dfb9fbb8ac91adad7120747aaf in mainline Subject: [PATCH] [PKTGEN]: srcmac fix Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-26Fix datagram recvmsg NULL iov handling regression.Herbert Xu1-0/+3
commit ef8aef55ce61fd0e2af798695f7386ac756ae1e7 in mainline Subject: [PATCH] [NET]: Do not dereference iov if length is zero When msg_iovlen is zero we shouldn't try to dereference msg_iov. Right now the only thing that tries to do so is skb_copy_and_csum_datagram_iovec. Since the total length should also be zero if msg_iovlen is zero, it's sufficient to check the total length there and simply return if it's zero. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-09-26Fix TCP DSACK cwnd handlingIlpo Järvinen1-1/+4
commit 49ff4bb4cd4c04acf8f9e3d3ec2148305a1db445 in mainline. [TCP]: DSACK signals data receival, be conservative In case a DSACK is received, it's better to lower cwnd as it's a sign of data receival. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-09-26Handle snd_una in tcp_cwnd_down()Ilpo Järvinen1-7/+11
commit 6ee8009e38006da81d2a53da1aaa27365552553e in mainline Subject: [PATCH 1/1] [TCP]: Also handle snd_una changes in tcp_cwnd_down tcp_cwnd_down must check for it too as it should be conservative in case of collapse stuff and also when receiver is trying to lie (though it wouldn't be successful anyway). Note: - Separated also is_dupack and do_lost in fast_retransalert * Much cleaner look-and-feel now * This time it really fixes cumulative ACK + many new SACK blocks recovery entry (I claimed this fixes with last patch but it wasn't). TCP will now call tcp_update_scoreboard regardless of is_dupack when in recovery as long as there is enough fackets_out. - Introduce FLAG_SND_UNA_ADVANCED * Some prior_snd_una arguments are unnecessary after it - Added helper FLAG_ANY_PROGRESS to avoid long FLAG...|FLAG... constructs This is a reduced version of a mainline patch. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Cc: David Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-09-26Fix oops in vlan and bridging codeEvgeniy Polyakov2-6/+18
commit 8c7b43a2e58baa24002fa2b266d9a5007bc52a40 in mainline I tried to preserve bridging code as it was before, but logic is quite strange - I think we should free skb on error, since it is already unshared and thus will just leak. Herbert Xu states: > + if ((skb = skb_share_check(skb, GFP_ATOMIC)) == NULL) > + goto out; If this happens it'll be a double-free on skb since we'll return NF_DROP which makes the caller free it too. We could return NF_STOLEN to prevent that but I'm not sure whether that's correct netfilter semantics. Patrick, could you please make a call on this? Patrick McHardy states: NF_STOLEN should work fine here. Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-09-26Fix ipv6 source address handling.Jiri Kosina1-1/+1
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 <jkosina@suse.cz> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-09-26Fix IPV6 DAD handlingDenis V. Lunev1-1/+1
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 <den@openvz.org> Signed-off-by: Alexey Dobriyan <adobriyan@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-09-26Fix ipv6 double-sock-release with MSG_CONFIRMYOSHIFUJI Hideaki1-2/+1
commit 3ef9d943d26dea764f4fecf3767001c90b778b0c in mainline Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-09-26Fix IPSEC AH4 options handlingNick Bowler1-1/+1
commit 8ee4f391831cb96916a8e8a05f04b1c1d7dd30d8 in mainline. In testing our ESP/AH offload hardware, I discovered an issue with how AH handles mutable fields in IPv4. RFC 4302 (AH) states the following on the subject: For IPv4, the entire option is viewed as a unit; so even though the type and length fields within most options are immutable in transit, if an option is classified as mutable, the entire option is zeroed for ICV computation purposes. The current implementation does not zero the type and length fields, resulting in authentication failures when communicating with hosts that do (i.e. FreeBSD). I have tested record route and timestamp options (ping -R and ping -T) on a small network involving Windows XP, FreeBSD 6.2, and Linux hosts, with one router. In the presence of these options, the FreeBSD and Linux hosts (with the patch or with the hardware) can communicate. The Windows XP host simply fails to accept these packets with or without the patch. I have also been trying to test source routing options (using traceroute -g), but haven't had much luck getting this option to work *without* AH, let alone with. Signed-off-by: Nick Bowler <nbowler@ellipticsemi.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-09-26Fix IPV6 append OOPS.YOSHIFUJI Hideaki1-2/+3
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 <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-09-26Fix inet_diag OOPS.Patrick McHardy1-0/+4
commit 0a9c73014415d2a84dac346c1e12169142a6ad37 in mainline [INET_DIAG]: Fix oops in netlink_rcv_skb netlink_run_queue() doesn't handle multiple processes processing the queue concurrently. Serialize queue processing in inet_diag to fix a oops in netlink_rcv_skb caused by netlink_run_queue passing a NULL for the skb. BUG: unable to handle kernel NULL pointer dereference at virtual address 00000054 [349587.500454] printing eip: [349587.500457] c03318ae [349587.500459] *pde = 00000000 [349587.500464] Oops: 0000 [#1] [349587.500466] PREEMPT SMP [349587.500474] Modules linked in: w83627hf hwmon_vid i2c_isa [349587.500483] CPU: 0 [349587.500485] EIP: 0060:[<c03318ae>] Not tainted VLI [349587.500487] EFLAGS: 00010246 (2.6.22.3 #1) [349587.500499] EIP is at netlink_rcv_skb+0xa/0x7e [349587.500506] eax: 00000000 ebx: 00000000 ecx: c148d2a0 edx: c0398819 [349587.500510] esi: 00000000 edi: c0398819 ebp: c7a21c8c esp: c7a21c80 [349587.500517] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [349587.500521] Process oidentd (pid: 17943, ti=c7a20000 task=cee231c0 task.ti=c7a20000) [349587.500527] Stack: 00000000 c7a21cac f7c8ba78 c7a21ca4 c0331962 c0398819 f7c8ba00 0000004c [349587.500542] f736f000 c7a21cb4 c03988e3 00000001 f7c8ba00 c7a21cc4 c03312a5 0000004c [349587.500558] f7c8ba00 c7a21cd4 c0330681 f7c8ba00 e4695280 c7a21d00 c03307c6 7fffffff [349587.500578] Call Trace: [349587.500581] [<c010361a>] show_trace_log_lvl+0x1c/0x33 [349587.500591] [<c01036d4>] show_stack_log_lvl+0x8d/0xaa [349587.500595] [<c010390e>] show_registers+0x1cb/0x321 [349587.500604] [<c0103bff>] die+0x112/0x1e1 [349587.500607] [<c01132d2>] do_page_fault+0x229/0x565 [349587.500618] [<c03c8d3a>] error_code+0x72/0x78 [349587.500625] [<c0331962>] netlink_run_queue+0x40/0x76 [349587.500632] [<c03988e3>] inet_diag_rcv+0x1f/0x2c [349587.500639] [<c03312a5>] netlink_data_ready+0x57/0x59 [349587.500643] [<c0330681>] netlink_sendskb+0x24/0x45 [349587.500651] [<c03307c6>] netlink_unicast+0x100/0x116 [349587.500656] [<c0330f83>] netlink_sendmsg+0x1c2/0x280 [349587.500664] [<c02fcce9>] sock_sendmsg+0xba/0xd5 [349587.500671] [<c02fe4d1>] sys_sendmsg+0x17b/0x1e8 [349587.500676] [<c02fe92d>] sys_socketcall+0x230/0x24d [349587.500684] [<c01028d2>] syscall_call+0x7/0xb [349587.500691] ======================= [349587.500693] Code: f0 ff 4e 18 0f 94 c0 84 c0 0f 84 66 ff ff ff 89 f0 e8 86 e2 fc ff e9 5a ff ff ff f0 ff 40 10 eb be 55 89 e5 57 89 d7 56 89 c6 53 <8b> 50 54 83 fa 10 72 55 8b 9e 9c 00 00 00 31 c9 8b 03 83 f8 0f Reported by Athanasius <link@miggy.org> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-09-26Fix device address listing for ipv4.Stephen Hemminger1-1/+1
commit 596e41509550447b030f7b16adaeb0138ab585a8 in mainline Bug: http://bugzilla.kernel.org/show_bug.cgi?id=8876 Not all ips are shown by "ip addr show" command when IPs number assigned to an interface is more than 60-80 (in fact it depends on broadcast/label etc presence on each address). Steps to reproduce: It's terribly simple to reproduce: # for i in $(seq 1 100); do ip ad add 10.0.$i.1/24 dev eth10 ; done # ip addr show this will _not_ show all IPs. Looks like the problem is in netlink/ipv4 message processing. This is fix from bug submitter, it looks correct. Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-09-26Fix decnet device address listing.Patrick McHardy1-1/+1
commit a2221f308dabb95abb914ad858d36c2462705558 in mainline. Not all are listed, same as the IPV4 devinet bug. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-09-26Correctly close old nfsd/lockd sockets.Neil Brown1-1/+2
commit 7a1fa065a0264f6b3d3003ba5635289f6583c478 in mainline. Commit aaf68cfbf2241d24d46583423f6bff5c47e088b3 added a bias to sk_inuse, so this test for an unused socket now fails. So no sockets get closed because they are old (they might get closed if the client closed them). This bug has existed since 2.6.21-rc1. Thanks to Wolfgang Walter for finding and reporting the bug. Cc: Wolfgang Walter <wolfgang.walter@studentenwerk.mhn.de> Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-09-26rpc: fix garbage in printk in svc_tcp_accept()Wolfgang Walter1-1/+2
commit 9db619e66503494e41159de3c76fafabe80d016b in mainline. we upgraded the kernel of a nfs-server from 2.6.17.11 to 2.6.22.6. Since then we get the message lockd: too many open TCP sockets, consider increasing the number of nfsd threads lockd: last TCP connect from ^\\236^\É^D These random characters in the second line are caused by a bug in svc_tcp_accept. (Note: there are two previous __svc_print_addr(sin, buf, sizeof(buf)) calls in this function, either of which would initialize buf correctly; but both are inside "if"'s and are not necessarily executed. This is less obvious in the second case, which is inside a dprintk(), which is a macro which expands to an if statement.) Signed-off-by: Wolfgang Walter <wolfgang.walter@studentenwerk.mhn.de> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-08-31TCP: Fix TCP handling of SACK in bidirectional flows.Ilpo Järvinen1-1/+4
It's possible that new SACK blocks that should trigger new LOST markings arrive with new data (which previously made is_dupack false). In addition, I think this fixes a case where we get a cumulative ACK with enough SACK blocks to trigger the fast recovery (is_dupack would be false there too). I'm not completely pleased with this solution because readability of the code is somewhat questionable as 'is_dupack' in SACK case is no longer about dupacks only but would mean something like 'lost_marker_work_todo' too... But because of Eifel stuff done in CA_Recovery, the FLAG_DATA_SACKED check cannot be placed to the if statement which seems attractive solution. Nevertheless, I didn't like adding another variable just for that either... :-) Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-08-31TCP: Fix TCP rate-halving on bidirectional flows.Ilpo Järvinen1-9/+12
Actually, the ratehalving seems to work too well, as cwnd is reduced on every second ACK even though the packets in flight remains unchanged. Recoveries in a bidirectional flows suffer quite badly because of this, both NewReno and SACK are affected. After this patch, rate halving is performed for ACK only if packets in flight was supposedly changed too. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-08-31TCP: Do not autobind ports for TCP socketsDavid Miller5-5/+4
[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 <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-08-31NET: Fix missing rcu unlock in __sock_create()Herbert Xu1-1/+1
[NET]: Fix unbalanced rcu_read_unlock in __sock_create The recent RCU work created an unbalanced rcu_read_unlock in __sock_create. This patch fixes that. Reported by oleg 123. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-08-31SNAP: Fix SNAP protocol header accesses.Herbert Xu1-5/+12
The snap_rcv code reads 5 bytes so we should make sure that we have 5 bytes in the head before proceeding. Based on diagnosis and fix by Evgeniy Polyakov, reported by Alan J. Wylie. Patch also kills the skb->sk assignment before kfree_skb since it's redundant. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-08-31IPv6: Invalid semicolon after if statementIlpo Jarvinen1-1/+1
Author: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> 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 <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-08-31IPV6: Fix kernel panic while send SCTP data with IP fragmentsWei Yongjun1-1/+1
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:[<c05be62a>] 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: [<c0405e1d>] show_trace_log_lvl+0x1a/0x2f [<c0405ecd>] show_stack_log_lvl+0x9b/0xa3 [<c040608d>] show_registers+0x1b8/0x289 [<c0406271>] die+0x113/0x246 [<c0625dbc>] do_page_fault+0x4ad/0x57e [<c0624642>] error_code+0x72/0x78 [<d09bc521>] ip6_output+0x8e5/0xab2 [ipv6] [<d09bcec1>] ip6_xmit+0x2ea/0x3a3 [ipv6] [<d0a3f2ca>] sctp_v6_xmit+0x248/0x253 [sctp] [<d0a3c934>] sctp_packet_transmit+0x53f/0x5ae [sctp] [<d0a34bf8>] sctp_outq_flush+0x555/0x587 [sctp] [<d0a34d3c>] sctp_retransmit+0xf8/0x10f [sctp] [<d0a3d183>] sctp_icmp_frag_needed+0x57/0x5b [sctp] [<d0a3ece2>] sctp_v6_err+0xcd/0x148 [sctp] [<d09cf1ce>] icmpv6_notify+0xe6/0x167 [ipv6] [<d09d009a>] icmpv6_rcv+0x7d7/0x849 [ipv6] [<d09be240>] ip6_input+0x1dc/0x310 [ipv6] [<d09be965>] ipv6_rcv+0x294/0x2df [ipv6] [<c05c3789>] netif_receive_skb+0x2d2/0x335 [<c05c5733>] process_backlog+0x7f/0xd0 [<c05c58f6>] net_rx_action+0x96/0x17e [<c042e722>] __do_softirq+0x64/0xcd [<c0406f37>] 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 <f3> a5 89 c1 83 e1 03 74 02 f3 a4 29 45 08 0f 84 7b 01 00 00 01 EIP: [<c05be62a>] 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 <yjwei@cn.fujitsu.com> Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-08-31DCCP: Fix DCCP GFP_KERNEL allocation in atomic contextGerrit Renker1-1/+1
This fixes the following bug reported in syslog: [ 4039.051658] BUG: sleeping function called from invalid context at /usr/src/davem-2.6/mm/slab.c:3032 [ 4039.051668] in_atomic():1, irqs_disabled():0 [ 4039.051670] INFO: lockdep is turned off. [ 4039.051674] [<c0104c0f>] show_trace_log_lvl+0x1a/0x30 [ 4039.051687] [<c0104d4d>] show_trace+0x12/0x14 [ 4039.051691] [<c0104d65>] dump_stack+0x16/0x18 [ 4039.051695] [<c011371e>] __might_sleep+0xaf/0xbe [ 4039.051700] [<c0157b66>] __kmalloc+0xb1/0xd0 [ 4039.051706] [<f090416f>] ccid2_hc_tx_alloc_seq+0x35/0xc3 [dccp_ccid2] [ 4039.051717] [<f09048d6>] ccid2_hc_tx_packet_sent+0x27f/0x2d9 [dccp_ccid2] [ 4039.051723] [<f085486b>] dccp_write_xmit+0x1eb/0x338 [dccp] [ 4039.051741] [<f085603d>] dccp_sendmsg+0x113/0x18f [dccp] [ 4039.051750] [<c03907fc>] inet_sendmsg+0x2e/0x4c [ 4039.051758] [<c033a47d>] sock_aio_write+0xd5/0x107 [ 4039.051766] [<c015abc1>] do_sync_write+0xcd/0x11c [ 4039.051772] [<c015b296>] vfs_write+0x118/0x11f [ 4039.051840] [<c015b932>] sys_write+0x3d/0x64 [ 4039.051845] [<c0103e7c>] syscall_call+0x7/0xb [ 4039.051848] ======================= The problem was that GFP_KERNEL was used; fixed by using gfp_any(). Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk> Signed-off-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-08-31NET: Share correct feature code between bridging and bondingHerbert Xu3-25/+44
[NET]: Share correct feature code between bridging and bonding http://bugzilla.kernel.org/show_bug.cgi?id=8797 shows that the bonding driver may produce bogus combinations of the checksum flags and SG/TSO. For example, if you bond devices with NETIF_F_HW_CSUM and NETIF_F_IP_CSUM you'll end up with a bonding device that has neither flag set. If both have TSO then this produces an illegal combination. The bridge device on the other hand has the correct code to deal with this. In fact, the same code can be used for both. So this patch moves that logic into net/core/dev.c and uses it for both bonding and bridging. In the process I've made small adjustments such as only setting GSO_ROBUST if at least one constituent device supports it. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-08-15softmac: Fix deadlock of wx_set_essid with assoc workMichael Buesch1-3/+8
The essid wireless extension does deadlock against the assoc mutex, as we don't unlock the assoc mutex when flushing the workqueue, which also holds the lock. Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-08-10Netfilter: Fix logging regressionPatrick McHardy4-18/+8
[NETFILTER]: Fix logging regression Loading one of the LOG target fails if a different target has already registered itself as backend for the same family. This can affect the ipt_LOG and ipt_ULOG modules when both are loaded. Reported and tested by: <t.artem@mailcity.com> Upstream-commit: 7e2acc7e Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-08-10IPV6: /proc/net/anycast6 unbalanced inet6_dev refcntDavid Stevens1-0/+1
Reading /proc/net/anycast6 when there is no anycast address on an interface results in an ever-increasing inet6_dev reference count, as well as a reference to the netdevice you can't get rid of. Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Marcus Meissner <meissner@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-08-10nf_conntrack: don't track locally generated special ICMP errorYasuyuki Kozakai1-17/+5
[NETFILTER]: nf_conntrack: don't track locally generated special ICMP error The conntrack assigned to locally generated ICMP error is usually the one assigned to the original packet which has caused the error. But if the original packet is handled as invalid by nf_conntrack, no conntrack is assigned to the original packet. Then nf_ct_attach() cannot assign any conntrack to the ICMP error packet. In that case the current nf_conntrack_icmp assigns appropriate conntrack to it. But the current code mistakes the direction of the packet. As a result, NAT code mistakes the address to be mangled. To fix the bug, this changes nf_conntrack_icmp not to assign conntrack to such ICMP error. Actually no address is necessary to be mangled in this case. Spotted by Jordan Russell. Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Upstream commit ID: 130e7a83d7ec8c5c673225e0fa8ea37b1ed507a5 Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-08-10Keep rfcomm_dev on the list until it is freedVille Tervo1-8/+22
This patch changes the RFCOMM TTY release process so that the TTY is kept on the list until it is really freed. A new device flag is used to keep track of released TTYs. Signed-off-by: Ville Tervo <ville.tervo@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-08-10Hangup TTY before releasing rfcomm_devMikko Rapeli1-0/+4
The core problem is that RFCOMM socket layer ioctl can release rfcomm_dev struct while RFCOMM TTY layer is still actively using it. Calling tty_vhangup() is needed for a synchronous hangup before rfcomm_dev is freed. Addresses the oops at http://bugzilla.kernel.org/show_bug.cgi?id=7509 Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-08-10nfsd: fix possible oops on re-insertion of rpcsec_gss modulesJ. Bruce Fields1-4/+5
The handling of the re-registration case is wrong here; the "test" that was returned from auth_domain_lookup will not be used again, so that reference should be put. And auth_domain_lookup never did anything with "new" in this case, so we should just clean it up ourself. Thanks to Akinobu Mita for bug report, analysis, and testing. Cc: Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> Cc: Neil Brown <neilb@suse.de> Cc: Trond Myklebust <trond.myklebust@fys.uio.no> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-08-10softmac: Fix ESSID problemJean Tourrilhes1-1/+4
Victor Porton reported that the SoftMAC layer had random problem when setting the ESSID : http://bugzilla.kernel.org/show_bug.cgi?id=8686 After investigation, it turned out to be worse, the SoftMAC layer is left in an inconsistent state. The fix is pretty trivial. Signed-off-by: Jean Tourrilhes <jt@hpl.hp.com> Acked-by: Michael Buesch <mb@bu3sch.de> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Acked-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-08-10Fix TCP IPV6 MD5 bug.YOSHIFUJI Hideaki1-0/+1
[TCPv6] MD5SIG: Ensure to reset allocation count to avoid panic. After clearing all passwords for IPv6 peers, we need to set allocation count to zero as well as we free the storage. Otherwise, we panic when a user trys to (re)add a password. Discovered and fixed by MIYAJIMA Mitsuharu <miyajima.mitsuharu@anchor.jp>. Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
generated by cgit v1.2.3 (git 2.39.0) at 2024-12-18 07:44:01 +0300