1. 08 12月, 2018 1 次提交
  2. 29 11月, 2018 3 次提交
  3. 22 11月, 2018 1 次提交
  4. 24 10月, 2018 3 次提交
  5. 16 10月, 2018 12 次提交
  6. 04 10月, 2018 1 次提交
  7. 26 9月, 2018 1 次提交
  8. 22 9月, 2018 2 次提交
    • V
    • V
      scsi: target: iscsi: Use hex2bin instead of a re-implementation · 18164943
      Vincent Pelletier 提交于
      This change has the following effects, in order of descreasing importance:
      
      1) Prevent a stack buffer overflow
      
      2) Do not append an unnecessary NULL to an anyway binary buffer, which
         is writing one byte past client_digest when caller is:
         chap_string_to_hex(client_digest, chap_r, strlen(chap_r));
      
      The latter was found by KASAN (see below) when input value hes expected size
      (32 hex chars), and further analysis revealed a stack buffer overflow can
      happen when network-received value is longer, allowing an unauthenticated
      remote attacker to smash up to 17 bytes after destination buffer (16 bytes
      attacker-controlled and one null).  As switching to hex2bin requires
      specifying destination buffer length, and does not internally append any null,
      it solves both issues.
      
      This addresses CVE-2018-14633.
      
      Beyond this:
      
      - Validate received value length and check hex2bin accepted the input, to log
        this rejection reason instead of just failing authentication.
      
      - Only log received CHAP_R and CHAP_C values once they passed sanity checks.
      
      ==================================================================
      BUG: KASAN: stack-out-of-bounds in chap_string_to_hex+0x32/0x60 [iscsi_target_mod]
      Write of size 1 at addr ffff8801090ef7c8 by task kworker/0:0/1021
      
      CPU: 0 PID: 1021 Comm: kworker/0:0 Tainted: G           O      4.17.8kasan.sess.connops+ #2
      Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 05/19/2014
      Workqueue: events iscsi_target_do_login_rx [iscsi_target_mod]
      Call Trace:
       dump_stack+0x71/0xac
       print_address_description+0x65/0x22e
       ? chap_string_to_hex+0x32/0x60 [iscsi_target_mod]
       kasan_report.cold.6+0x241/0x2fd
       chap_string_to_hex+0x32/0x60 [iscsi_target_mod]
       chap_server_compute_md5.isra.2+0x2cb/0x860 [iscsi_target_mod]
       ? chap_binaryhex_to_asciihex.constprop.5+0x50/0x50 [iscsi_target_mod]
       ? ftrace_caller_op_ptr+0xe/0xe
       ? __orc_find+0x6f/0xc0
       ? unwind_next_frame+0x231/0x850
       ? kthread+0x1a0/0x1c0
       ? ret_from_fork+0x35/0x40
       ? ret_from_fork+0x35/0x40
       ? iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod]
       ? deref_stack_reg+0xd0/0xd0
       ? iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod]
       ? is_module_text_address+0xa/0x11
       ? kernel_text_address+0x4c/0x110
       ? __save_stack_trace+0x82/0x100
       ? ret_from_fork+0x35/0x40
       ? save_stack+0x8c/0xb0
       ? 0xffffffffc1660000
       ? iscsi_target_do_login+0x155/0x8d0 [iscsi_target_mod]
       ? iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod]
       ? process_one_work+0x35c/0x640
       ? worker_thread+0x66/0x5d0
       ? kthread+0x1a0/0x1c0
       ? ret_from_fork+0x35/0x40
       ? iscsi_update_param_value+0x80/0x80 [iscsi_target_mod]
       ? iscsit_release_cmd+0x170/0x170 [iscsi_target_mod]
       chap_main_loop+0x172/0x570 [iscsi_target_mod]
       ? chap_server_compute_md5.isra.2+0x860/0x860 [iscsi_target_mod]
       ? rx_data+0xd6/0x120 [iscsi_target_mod]
       ? iscsit_print_session_params+0xd0/0xd0 [iscsi_target_mod]
       ? cyc2ns_read_begin.part.2+0x90/0x90
       ? _raw_spin_lock_irqsave+0x25/0x50
       ? memcmp+0x45/0x70
       iscsi_target_do_login+0x875/0x8d0 [iscsi_target_mod]
       ? iscsi_target_check_first_request.isra.5+0x1a0/0x1a0 [iscsi_target_mod]
       ? del_timer+0xe0/0xe0
       ? memset+0x1f/0x40
       ? flush_sigqueue+0x29/0xd0
       iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod]
       ? iscsi_target_nego_release+0x80/0x80 [iscsi_target_mod]
       ? iscsi_target_restore_sock_callbacks+0x130/0x130 [iscsi_target_mod]
       process_one_work+0x35c/0x640
       worker_thread+0x66/0x5d0
       ? flush_rcu_work+0x40/0x40
       kthread+0x1a0/0x1c0
       ? kthread_bind+0x30/0x30
       ret_from_fork+0x35/0x40
      
      The buggy address belongs to the page:
      page:ffffea0004243bc0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
      flags: 0x17fffc000000000()
      raw: 017fffc000000000 0000000000000000 0000000000000000 00000000ffffffff
      raw: ffffea0004243c20 ffffea0004243ba0 0000000000000000 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8801090ef680: f2 f2 f2 f2 f2 f2 f2 01 f2 f2 f2 f2 f2 f2 f2 00
       ffff8801090ef700: f2 f2 f2 f2 f2 f2 f2 00 02 f2 f2 f2 f2 f2 f2 00
      >ffff8801090ef780: 00 f2 f2 f2 f2 f2 f2 00 00 f2 f2 f2 f2 f2 f2 00
                                                    ^
       ffff8801090ef800: 00 f2 f2 f2 f2 f2 f2 00 00 00 00 02 f2 f2 f2 f2
       ffff8801090ef880: f2 f2 f2 00 00 00 00 00 00 00 00 f2 f2 f2 f2 00
      ==================================================================
      Signed-off-by: NVincent Pelletier <plr.vincent@gmail.com>
      Reviewed-by: NMike Christie <mchristi@redhat.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      18164943
  9. 21 9月, 2018 1 次提交
    • G
      scsi: target: iblock: split T10 PI SGL across command bios · fed564f6
      Greg Edwards 提交于
      When T10 PI is enabled on a backing device for the iblock backstore, the PI
      SGL for the entire command is attached to the first bio only.  This works fine
      if the command is covered by a single bio, but can result in ref tag errors in
      the client for the other bios in a multi-bio command, e.g.
      
      [   47.631236] sda: ref tag error at location 2048 (rcvd 0)
      [   47.637658] sda: ref tag error at location 4096 (rcvd 0)
      [   47.644228] sda: ref tag error at location 6144 (rcvd 0)
      
      The command will be split into multiple bios if the number of data SG elements
      exceeds BIO_MAX_PAGES (see iblock_get_bio()).
      
      The bios may later be split again in the block layer on the host after
      iblock_submit_bios(), depending on the queue limits of the backing device.
      The block and SCSI layers will pass through the whole PI SGL down to the LLDD
      however that first bio is split up, but the LLDD may only use the portion that
      corresponds to the data length (depends on the LLDD, tested with scsi_debug).
      
      Split the PI SGL across the bios in the command, so each bio's
      bio_integrity_payload contains the protection information for the data in the
      bio.  Use an sg_mapping_iter to keep track of where we are in PI SGL, so we
      know where to start with the next bio.
      Signed-off-by: NGreg Edwards <gedwards@ddn.com>
      Reviewed-by: NMike Christie <mchristi@redhat.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      fed564f6
  10. 17 9月, 2018 1 次提交
  11. 12 9月, 2018 1 次提交
    • L
      scsi: iscsi: target: Don't use stack buffer for scatterlist · 679fcae4
      Laura Abbott 提交于
      Fedora got a bug report of a crash with iSCSI:
      
      kernel BUG at include/linux/scatterlist.h:143!
      ...
      RIP: 0010:iscsit_do_crypto_hash_buf+0x154/0x180 [iscsi_target_mod]
      ...
       Call Trace:
        ? iscsi_target_tx_thread+0x200/0x200 [iscsi_target_mod]
        iscsit_get_rx_pdu+0x4cd/0xa90 [iscsi_target_mod]
        ? native_sched_clock+0x3e/0xa0
        ? iscsi_target_tx_thread+0x200/0x200 [iscsi_target_mod]
        iscsi_target_rx_thread+0x81/0xf0 [iscsi_target_mod]
        kthread+0x120/0x140
        ? kthread_create_worker_on_cpu+0x70/0x70
        ret_from_fork+0x3a/0x50
      
      This is a BUG_ON for using a stack buffer with a scatterlist.  There
      are two cases that trigger this bug. Switch to using a dynamically
      allocated buffer for one case and do not assign a NULL buffer in
      another case.
      Signed-off-by: NLaura Abbott <labbott@redhat.com>
      Reviewed-by: NMike Christie <mchristi@redhat.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      679fcae4
  12. 30 8月, 2018 2 次提交
    • M
      scsi: iscsi: target: Fix conn_ops double free · 05a86e78
      Mike Christie 提交于
      If iscsi_login_init_conn fails it can free conn_ops.
      __iscsi_target_login_thread will then call iscsi_target_login_sess_out
      which will also free it.
      
      This fixes the problem by organizing conn allocation/setup into parts that
      are needed through the life of the conn and parts that are only needed for
      the login. The free functions then release what was allocated in the alloc
      functions.
      
      With this patch we have:
      
      iscsit_alloc_conn/iscsit_free_conn - allocs/frees the conn we need for the
      entire life of the conn.
      
      iscsi_login_init_conn/iscsi_target_nego_release - allocs/frees the parts
      of the conn that are only needed during login.
      Signed-off-by: NMike Christie <mchristi@redhat.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      05a86e78
    • V
      scsi: iscsi: target: Set conn->sess to NULL when iscsi_login_set_conn_values fails · 7915919b
      Vincent Pelletier 提交于
      Fixes a use-after-free reported by KASAN when later
      iscsi_target_login_sess_out gets called and it tries to access
      conn->sess->se_sess:
      
      Disabling lock debugging due to kernel taint
      iSCSI Login timeout on Network Portal [::]:3260
      iSCSI Login negotiation failed.
      ==================================================================
      BUG: KASAN: use-after-free in
      iscsi_target_login_sess_out.cold.12+0x58/0xff [iscsi_target_mod]
      Read of size 8 at addr ffff880109d070c8 by task iscsi_np/980
      
      CPU: 1 PID: 980 Comm: iscsi_np Tainted: G           O
      4.17.8kasan.sess.connops+ #4
      Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB,
      BIOS 5.6.5 05/19/2014
      Call Trace:
       dump_stack+0x71/0xac
       print_address_description+0x65/0x22e
       ? iscsi_target_login_sess_out.cold.12+0x58/0xff [iscsi_target_mod]
       kasan_report.cold.6+0x241/0x2fd
       iscsi_target_login_sess_out.cold.12+0x58/0xff [iscsi_target_mod]
       iscsi_target_login_thread+0x1086/0x1710 [iscsi_target_mod]
       ? __sched_text_start+0x8/0x8
       ? iscsi_target_login_sess_out+0x250/0x250 [iscsi_target_mod]
       ? __kthread_parkme+0xcc/0x100
       ? parse_args.cold.14+0xd3/0xd3
       ? iscsi_target_login_sess_out+0x250/0x250 [iscsi_target_mod]
       kthread+0x1a0/0x1c0
       ? kthread_bind+0x30/0x30
       ret_from_fork+0x35/0x40
      
      Allocated by task 980:
       kasan_kmalloc+0xbf/0xe0
       kmem_cache_alloc_trace+0x112/0x210
       iscsi_target_login_thread+0x816/0x1710 [iscsi_target_mod]
       kthread+0x1a0/0x1c0
       ret_from_fork+0x35/0x40
      
      Freed by task 980:
       __kasan_slab_free+0x125/0x170
       kfree+0x90/0x1d0
       iscsi_target_login_thread+0x1577/0x1710 [iscsi_target_mod]
       kthread+0x1a0/0x1c0
       ret_from_fork+0x35/0x40
      
      The buggy address belongs to the object at ffff880109d06f00
       which belongs to the cache kmalloc-512 of size 512
      The buggy address is located 456 bytes inside of
       512-byte region [ffff880109d06f00, ffff880109d07100)
      The buggy address belongs to the page:
      page:ffffea0004274180 count:1 mapcount:0 mapping:0000000000000000
      index:0x0 compound_mapcount: 0
      flags: 0x17fffc000008100(slab|head)
      raw: 017fffc000008100 0000000000000000 0000000000000000 00000001000c000c
      raw: dead000000000100 dead000000000200 ffff88011b002e00 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff880109d06f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff880109d07000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff880109d07080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                    ^
       ffff880109d07100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff880109d07180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      ==================================================================
      Signed-off-by: NVincent Pelletier <plr.vincent@gmail.com>
      [rebased against idr/ida changes and to handle ret review comments from Matthew]
      Signed-off-by: NMike Christie <mchristi@redhat.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Reviewed-by: NMatthew Wilcox <willy@infradead.org>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      7915919b
  13. 28 8月, 2018 1 次提交
  14. 22 8月, 2018 2 次提交
  15. 07 8月, 2018 1 次提交
  16. 03 8月, 2018 7 次提交