1. 22 3月, 2011 8 次提交
    • E
      macvlan: Fix use after free of struct macvlan_port. · d5cd9244
      Eric W. Biederman 提交于
      When the macvlan driver was extended to call unregisgter_netdevice_queue
      in 23289a37, a use after free of struct
      macvlan_port was introduced.  The code in dellink relied on unregister_netdevice
      actually unregistering the net device so it would be safe to free macvlan_port.
      
      Since unregister_netdevice_queue can just queue up the unregister instead of
      performing the unregiser immediately we free the macvlan_port too soon and
      then the code in macvlan_stop removes the macaddress for the set of macaddress
      to listen for and uses memory that has already been freed.
      
      To fix this add a reference count to track when it is safe to free the macvlan_port
      and move the call of macvlan_port_destroy into macvlan_uninit which is guaranteed
      to be called after the final macvlan_port_close.
      Signed-off-by: NEric W. Biederman <ebiederm@aristanetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d5cd9244
    • N
      net: fix incorrect spelling in drop monitor protocol · ac0a121d
      Neil Horman 提交于
      It was pointed out to me recently that my spelling could be better :)
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ac0a121d
    • J
      can: c_can: Do basic c_can configuration _before_ enabling the interrupts · 4f2d56c4
      Jan Altenberg 提交于
      I ran into some trouble while testing the SocketCAN driver for the BOSCH
      C_CAN controller. The interface is not correctly initialized, if I put
      some CAN traffic on the line, _while_ the interface is being started
      (which means: the interface doesn't come up correcty, if there's some RX
      traffic while doing 'ifconfig can0 up').
      
      The current implementation enables the controller interrupts _before_
      doing the basic c_can configuration. I think, this should be done the
      other way round.
      
      The patch below fixes things for me.
      Signed-off-by: NJan Altenberg <jan@linutronix.de>
      Acked-by: NKurt Van Dijck <kurt.van.dijck@eia.be>
      Acked-by: NWolfgang Grandegger <wg@grandegger.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4f2d56c4
    • A
      net/appletalk: fix atalk_release use after free · b20e7bbf
      Arnd Bergmann 提交于
      The BKL removal in appletalk introduced a use-after-free problem,
      where atalk_destroy_socket frees a sock, but we still release
      the socket lock on it.
      
      An easy fix is to take an extra reference on the sock and sock_put
      it when returning from atalk_release.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b20e7bbf
    • E
      ipx: fix ipx_release() · 674f2115
      Eric Dumazet 提交于
      Commit b0d0d915 (remove the BKL) added a regression, because
      sock_put() can free memory while we are going to use it later.
      
      Fix is to delay sock_put() _after_ release_sock().
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Tested-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      674f2115
    • E
      snmp: SNMP_UPD_PO_STATS_BH() always called from softirq · 20246a80
      Eric Dumazet 提交于
      We dont need to test if we run from softirq context, we definitely are.
      
      This saves few instructions in ip_rcv() & ip_rcv_finish()
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      20246a80
    • J
      l2tp: fix possible oops on l2tp_eth module unload · 8aa525a9
      James Chapman 提交于
      A struct used in the l2tp_eth driver for registering network namespace
      ops was incorrectly marked as __net_initdata, leading to oops when
      module unloaded.
      
      BUG: unable to handle kernel paging request at ffffffffa00ec098
      IP: [<ffffffff8123dbd8>] ops_exit_list+0x7/0x4b
      PGD 142d067 PUD 1431063 PMD 195da8067 PTE 0
      Oops: 0000 [#1] SMP 
      last sysfs file: /sys/module/l2tp_eth/refcnt
      Call Trace:
       [<ffffffff8123dc94>] ? unregister_pernet_operations+0x32/0x93
       [<ffffffff8123dd20>] ? unregister_pernet_device+0x2b/0x38
       [<ffffffff81068b6e>] ? sys_delete_module+0x1b8/0x222
       [<ffffffff810c7300>] ? do_munmap+0x254/0x318
       [<ffffffff812c64e5>] ? page_fault+0x25/0x30
       [<ffffffff812c6952>] ? system_call_fastpath+0x16/0x1b
      Signed-off-by: NJames Chapman <jchapman@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8aa525a9
    • W
      xfrm: Fix initialize repl field of struct xfrm_state · a454f0cc
      Wei Yongjun 提交于
      Commit 'xfrm: Move IPsec replay detection functions to a separate file'
        (9fdc4883)
      introduce repl field to struct xfrm_state, and only initialize it
      under SA's netlink create path, the other path, such as pf_key,
      ipcomp/ipcomp6 etc, the repl field remaining uninitialize. So if
      the SA is created by pf_key, any input packet with SA's encryption
      algorithm will cause panic.
      
          int xfrm_input()
          {
              ...
              x->repl->advance(x, seq);
              ...
          }
      
      This patch fixed it by introduce new function __xfrm_init_state().
      
      Pid: 0, comm: swapper Not tainted 2.6.38-next+ #14 Bochs Bochs
      EIP: 0060:[<c078e5d5>] EFLAGS: 00010206 CPU: 0
      EIP is at xfrm_input+0x31c/0x4cc
      EAX: dd839c00 EBX: 00000084 ECX: 00000000 EDX: 01000000
      ESI: dd839c00 EDI: de3a0780 EBP: dec1de88 ESP: dec1de64
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      Process swapper (pid: 0, ti=dec1c000 task=c09c0f20 task.ti=c0992000)
      Stack:
       00000000 00000000 00000002 c0ba27c0 00100000 01000000 de3a0798 c0ba27c0
       00000033 dec1de98 c0786848 00000000 de3a0780 dec1dea4 c0786868 00000000
       dec1debc c074ee56 e1da6b8c de3a0780 c074ed44 de3a07a8 dec1decc c074ef32
      Call Trace:
       [<c0786848>] xfrm4_rcv_encap+0x22/0x27
       [<c0786868>] xfrm4_rcv+0x1b/0x1d
       [<c074ee56>] ip_local_deliver_finish+0x112/0x1b1
       [<c074ed44>] ? ip_local_deliver_finish+0x0/0x1b1
       [<c074ef32>] NF_HOOK.clone.1+0x3d/0x44
       [<c074ef77>] ip_local_deliver+0x3e/0x44
       [<c074ed44>] ? ip_local_deliver_finish+0x0/0x1b1
       [<c074ec03>] ip_rcv_finish+0x30a/0x332
       [<c074e8f9>] ? ip_rcv_finish+0x0/0x332
       [<c074ef32>] NF_HOOK.clone.1+0x3d/0x44
       [<c074f188>] ip_rcv+0x20b/0x247
       [<c074e8f9>] ? ip_rcv_finish+0x0/0x332
       [<c072797d>] __netif_receive_skb+0x373/0x399
       [<c0727bc1>] netif_receive_skb+0x4b/0x51
       [<e0817e2a>] cp_rx_poll+0x210/0x2c4 [8139cp]
       [<c072818f>] net_rx_action+0x9a/0x17d
       [<c0445b5c>] __do_softirq+0xa1/0x149
       [<c0445abb>] ? __do_softirq+0x0/0x149
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a454f0cc
  2. 21 3月, 2011 2 次提交
  3. 20 3月, 2011 7 次提交
  4. 19 3月, 2011 23 次提交