1. 01 Oct, 2008 1 commit
    • Vitaliy Gusev's avatar
      tcp: Fix NULL dereference in tcp_4_send_ack() · 4dd7972d
      Vitaliy Gusev authored
      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: default avatarVitaliy Gusev <vgusev@openvz.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4dd7972d
  2. 30 Sep, 2008 3 commits
    • Wei Yongjun's avatar
      sctp: Fix kernel panic while process protocol violation parameter · ba016670
      Wei Yongjun authored
      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: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ba016670
    • Heiko Carstens's avatar
      iucv: Fix mismerge again. · 8b122efd
      Heiko Carstens authored
      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: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8b122efd
    • Herbert Xu's avatar
      ipsec: Fix pskb_expand_head corruption in xfrm_state_check_space · d01dbeb6
      Herbert Xu authored
      We're never supposed to shrink the headroom or tailroom.  In fact,
      shrinking the headroom is a fatal action.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d01dbeb6
  3. 29 Sep, 2008 18 commits
  4. 28 Sep, 2008 1 commit
  5. 27 Sep, 2008 13 commits
  6. 26 Sep, 2008 4 commits