1. 08 10月, 2008 1 次提交
    • P
      net: only invoke dev->change_rx_flags when device is UP · b6c40d68
      Patrick McHardy 提交于
      Jesper Dangaard Brouer <hawk@comx.dk> reported a bug when setting a VLAN
      device down that is in promiscous mode:
      
      When the VLAN device is set down, the promiscous count on the real
      device is decremented by one by vlan_dev_stop(). When removing the
      promiscous flag from the VLAN device afterwards, the promiscous
      count on the real device is decremented a second time by the
      vlan_change_rx_flags() callback.
      
      The root cause for this is that the ->change_rx_flags() callback is
      invoked while the device is down. The synchronization is meant to mirror
      the behaviour of the ->set_rx_mode callbacks, meaning the ->open function
      is responsible for doing a full sync on open, the ->close() function is
      responsible for doing full cleanup on ->stop() and ->change_rx_flags()
      is meant to do incremental changes while the device is UP.
      
      Only invoke ->change_rx_flags() while the device is UP to provide the
      intended behaviour.
      Tested-by: NJesper Dangaard Brouer <jdb@comx.dk>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b6c40d68
  2. 07 10月, 2008 3 次提交
  3. 01 10月, 2008 4 次提交
    • T
      af_key: Free dumping state on socket close · 05238204
      Timo Teras 提交于
      Fix a xfrm_{state,policy}_walk leak if pfkey socket is closed while
      dumping is on-going.
      Signed-off-by: NTimo Teras <timo.teras@iki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      05238204
    • A
      XFRM,IPv6: initialize ip6_dst_blackhole_ops.kmem_cachep · 5dc121e9
      Arnaud Ebalard 提交于
      ip6_dst_blackhole_ops.kmem_cachep is not expected to be NULL (i.e. to
      be initialized) when dst_alloc() is called from ip6_dst_blackhole().
      Otherwise, it results in the following (xfrm_larval_drop is now set to
      1 by default):
      
      [   78.697642] Unable to handle kernel paging request for data at address 0x0000004c
      [   78.703449] Faulting instruction address: 0xc0097f54
      [   78.786896] Oops: Kernel access of bad area, sig: 11 [#1]
      [   78.792791] PowerMac
      [   78.798383] Modules linked in: btusb usbhid bluetooth b43 mac80211 cfg80211 ehci_hcd ohci_hcd sungem sungem_phy usbcore ssb
      [   78.804263] NIP: c0097f54 LR: c0334a28 CTR: c002d430
      [   78.809997] REGS: eef19ad0 TRAP: 0300   Not tainted  (2.6.27-rc5)
      [   78.815743] MSR: 00001032 <ME,IR,DR>  CR: 22242482  XER: 20000000
      [   78.821550] DAR: 0000004c, DSISR: 40000000
      [   78.827278] TASK = eef0df40[3035] 'mip6d' THREAD: eef18000
      [   78.827408] GPR00: 00001032 eef19b80 eef0df40 00000000 00008020 eef19c30 00000001 00000000
      [   78.833249] GPR08: eee5101c c05a5c10 ef9ad500 00000000 24242422 1005787c 00000000 1004f960
      [   78.839151] GPR16: 00000000 10024e90 10050040 48030018 0fe44150 00000000 00000000 eef19c30
      [   78.845046] GPR24: eef19e44 00000000 eef19bf8 efb37c14 eef19bf8 00008020 00009032 c0596064
      [   78.856671] NIP [c0097f54] kmem_cache_alloc+0x20/0x94
      [   78.862581] LR [c0334a28] dst_alloc+0x40/0xc4
      [   78.868451] Call Trace:
      [   78.874252] [eef19b80] [c03c1810] ip6_dst_lookup_tail+0x1c8/0x1dc (unreliable)
      [   78.880222] [eef19ba0] [c0334a28] dst_alloc+0x40/0xc4
      [   78.886164] [eef19bb0] [c03cd698] ip6_dst_blackhole+0x28/0x1cc
      [   78.892090] [eef19be0] [c03d9be8] rawv6_sendmsg+0x75c/0xc88
      [   78.897999] [eef19cb0] [c038bca4] inet_sendmsg+0x4c/0x78
      [   78.903907] [eef19cd0] [c03207c8] sock_sendmsg+0xac/0xe4
      [   78.909734] [eef19db0] [c03209e4] sys_sendmsg+0x1e4/0x2a0
      [   78.915540] [eef19f00] [c03220a8] sys_socketcall+0xfc/0x210
      [   78.921406] [eef19f40] [c0014b3c] ret_from_syscall+0x0/0x38
      [   78.927295] --- Exception: c01 at 0xfe2d730
      [   78.927297]     LR = 0xfe2d71c
      [   78.939019] Instruction dump:
      [   78.944835] 91640018 9144001c 900a0000 4bffff44 9421ffe0 7c0802a6 bf810010 7c9d2378
      [   78.950694] 90010024 7fc000a6 57c0045e 7c000124 <83e3004c> 8383005c 2f9f0000 419e0050
      [   78.956464] ---[ end trace 05fa1ed7972487a1 ]---
      
      As commented by Benjamin Thery, the bug was introduced by
      f2fc6a54, while adding network
      namespaces support to ipv6 routes.
      Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
      Acked-by: NBenjamin Thery <benjamin.thery@bull.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5dc121e9
    • D
      ipv6: NULL pointer dereferrence in tcp_v6_send_ack · 2a5b8275
      Denis V. Lunev 提交于
      The following actions are possible:
      tcp_v6_rcv
        skb->dev = NULL;
        tcp_v6_do_rcv
          tcp_v6_hnd_req
            tcp_check_req
              req->rsk_ops->send_ack == tcp_v6_send_ack
      
      So, skb->dev can be NULL in tcp_v6_send_ack. We must obtain namespace
      from dst entry.
      
      Thanks to Vitaliy Gusev <vgusev@openvz.org> for initial problem finding
      in IPv4 code.
      Signed-off-by: NDenis V. Lunev <den@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2a5b8275
    • V
      tcp: Fix NULL dereference in tcp_4_send_ack() · 4dd7972d
      Vitaliy Gusev 提交于
      Fix NULL dereference in tcp_4_send_ack().
      
      As skb->dev is reset to NULL in tcp_v4_rcv() thus OOPS occurs:
      
      BUG: unable to handle kernel NULL pointer dereference at 00000000000004d0
      IP: [<ffffffff80498503>] tcp_v4_send_ack+0x203/0x250
      
      Stack:  ffff810005dbb000 ffff810015c8acc0 e77b2c6e5f861600 a01610802e90cb6d
       0a08010100000000 88afffff88afffff 0000000080762be8 0000000115c872e8
       0004122000000000 0000000000000001 ffffffff80762b88 0000000000000020
      Call Trace:
       <IRQ>  [<ffffffff80499c33>] tcp_v4_reqsk_send_ack+0x20/0x22
       [<ffffffff8049bce5>] tcp_check_req+0x108/0x14c
       [<ffffffff8047aaf7>] ? rt_intern_hash+0x322/0x33c
       [<ffffffff80499846>] tcp_v4_do_rcv+0x399/0x4ec
       [<ffffffff8045ce4b>] ? skb_checksum+0x4f/0x272
       [<ffffffff80485b74>] ? __inet_lookup_listener+0x14a/0x15c
       [<ffffffff8049babc>] tcp_v4_rcv+0x6a1/0x701
       [<ffffffff8047e739>] ip_local_deliver_finish+0x157/0x24a
       [<ffffffff8047ec9a>] ip_local_deliver+0x72/0x7c
       [<ffffffff8047e5bd>] ip_rcv_finish+0x38d/0x3b2
       [<ffffffff803d3548>] ? scsi_io_completion+0x19d/0x39e
       [<ffffffff8047ebe5>] ip_rcv+0x2a2/0x2e5
       [<ffffffff80462faa>] netif_receive_skb+0x293/0x303
       [<ffffffff80465a9b>] process_backlog+0x80/0xd0
       [<ffffffff802630b4>] ? __rcu_process_callbacks+0x125/0x1b4
       [<ffffffff8046560e>] net_rx_action+0xb9/0x17f
       [<ffffffff80234cc5>] __do_softirq+0xa3/0x164
       [<ffffffff8020c52c>] call_softirq+0x1c/0x28
       <EOI>  [<ffffffff8020de1c>] do_softirq+0x34/0x72
       [<ffffffff80234b8e>] local_bh_enable_ip+0x3f/0x50
       [<ffffffff804d43ca>] _spin_unlock_bh+0x12/0x14
       [<ffffffff804599cd>] release_sock+0xb8/0xc1
       [<ffffffff804a6f9a>] inet_stream_connect+0x146/0x25c
       [<ffffffff80243078>] ? autoremove_wake_function+0x0/0x38
       [<ffffffff8045751f>] sys_connect+0x68/0x8e
       [<ffffffff80291818>] ? fd_install+0x5f/0x68
       [<ffffffff80457784>] ? sock_map_fd+0x55/0x62
       [<ffffffff8020b39b>] system_call_after_swapgs+0x7b/0x80
      
      Code: 41 10 11 d0 83 d0 00 4d 85 ed 89 45 c0 c7 45 c4 08 00 00 00 74 07 41 8b 45 04 89 45 c8 48 8b 43 20 8b 4d b8 48 8d 55 b0 48 89 de <48> 8b 80 d0 04 00 00 48 8b b8 60 01 00 00 e8 20 ae fe ff 65 48
      RIP  [<ffffffff80498503>] tcp_v4_send_ack+0x203/0x250
       RSP <ffffffff80762b78>
      CR2: 00000000000004d0
      Signed-off-by: NVitaliy Gusev <vgusev@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4dd7972d
  4. 30 9月, 2008 4 次提交
    • W
      sctp: Fix kernel panic while process protocol violation parameter · ba016670
      Wei Yongjun 提交于
      Since call to function sctp_sf_abort_violation() need paramter 'arg' with
      'struct sctp_chunk' type, it will read the chunk type and chunk length from
      the chunk_hdr member of chunk. But call to sctp_sf_violation_paramlen()
      always with 'struct sctp_paramhdr' type's parameter, it will be passed to
      sctp_sf_abort_violation(). This may cause kernel panic.
      
         sctp_sf_violation_paramlen()
           |-- sctp_sf_abort_violation()
              |-- sctp_make_abort_violation()
      
      This patch fixed this problem. This patch also fix two place which called
      sctp_sf_violation_paramlen() with wrong paramter type.
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ba016670
    • H
      iucv: Fix mismerge again. · 8b122efd
      Heiko Carstens 提交于
      fb65a7c0 ("iucv: Fix bad merging.") fixed
      a merge error, but in a wrong way. We now end up with the bug below.
      This patch corrects the mismerge like it was intended.
      
      BUG: scheduling while atomic: swapper/1/0x00000000
      Modules linked in:
      CPU: 1 Not tainted 2.6.27-rc7-00094-gc0f4d6d4 #9
      Process swapper (pid: 1, task: 000000003fe7d988, ksp: 000000003fe838c0)
      0000000000000000 000000003fe839b8 0000000000000002 0000000000000000
             000000003fe83a58 000000003fe839d0 000000003fe839d0 0000000000390de6
             000000000058acd8 00000000000000d0 000000003fe7dcd8 0000000000000000
             000000000000000c 000000000000000d 0000000000000000 000000003fe83a28
             000000000039c5b8 0000000000015e5e 000000003fe839b8 000000003fe83a00
      Call Trace:
      ([<0000000000015d6a>] show_trace+0xe6/0x134)
       [<0000000000039656>] __schedule_bug+0xa2/0xa8
       [<0000000000391744>] schedule+0x49c/0x910
       [<0000000000391f64>] schedule_timeout+0xc4/0x114
       [<00000000003910d4>] wait_for_common+0xe8/0x1b4
       [<00000000000549ae>] call_usermodehelper_exec+0xa6/0xec
       [<00000000001af7b8>] kobject_uevent_env+0x418/0x438
       [<00000000001d08fc>] bus_add_driver+0x1e4/0x298
       [<00000000001d1ee4>] driver_register+0x90/0x18c
       [<0000000000566848>] netiucv_init+0x168/0x2c8
       [<00000000000120be>] do_one_initcall+0x3e/0x17c
       [<000000000054a31a>] kernel_init+0x1ce/0x248
       [<000000000001a97a>] kernel_thread_starter+0x6/0xc
       [<000000000001a974>] kernel_thread_starter+0x0/0xc
       iucv: NETIUCV driver initialized
      initcall netiucv_init+0x0/0x2c8 returned with preemption imbalance
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8b122efd
    • H
      ipsec: Fix pskb_expand_head corruption in xfrm_state_check_space · d01dbeb6
      Herbert Xu 提交于
      We're never supposed to shrink the headroom or tailroom.  In fact,
      shrinking the headroom is a fatal action.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d01dbeb6
    • L
      Linux 2.6.27-rc8 · 94aca1da
      Linus Torvalds 提交于
      94aca1da
  5. 29 9月, 2008 18 次提交
  6. 28 9月, 2008 4 次提交
  7. 27 9月, 2008 6 次提交