1. 08 Oct, 2007 4 commits
    • Brian Haley's avatar
      [IPv6]: Fix ICMPv6 redirect handling with target multicast address · bf0b48df
      Brian Haley authored
      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: default avatarBrian Haley <brian.haley@hp.com>
      Acked-by: default avatarDavid L Stevens <dlstevens@us.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bf0b48df
    • Stephen Hemminger's avatar
    • Alexey Dobriyan's avatar
      [ROSE]: Fix rose.ko oops on unload · 891e6a93
      Alexey Dobriyan authored
      Commit a3d38402 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: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      891e6a93
    • Ilpo Järvinen's avatar
      [TCP]: Fix fastpath_cnt_hint when GSO skb is partially ACKed · 48611c47
      Ilpo Järvinen authored
      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: default avatarIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      48611c47
  2. 07 Oct, 2007 12 commits
  3. 06 Oct, 2007 4 commits
  4. 05 Oct, 2007 7 commits
  5. 04 Oct, 2007 8 commits
  6. 03 Oct, 2007 5 commits