1. 02 Oct, 2018 7 commits
  2. 28 Sep, 2018 26 commits
  3. 24 Sep, 2018 4 commits
    • Stefan Bader's avatar
      UBUNTU: Ubuntu-4.4.0-137.163 · f299608c
      Stefan Bader authored
      Signed-off-by: default avatarStefan Bader <stefan.bader@canonical.com>
      f299608c
    • Vincent Pelletier's avatar
      iscsi target: Use hex2bin instead of a re-implementation · 5772cc87
      Vincent Pelletier authored
      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: default avatarVincent Pelletier <plr.vincent@gmail.com>
      
      CVE-2018-14633
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Signed-off-by: default avatarStefan Bader <stefan.bader@canonical.com>
      5772cc87
    • Linus Torvalds's avatar
      mm: get rid of vmacache_flush_all() entirely · 7ed926e6
      Linus Torvalds authored
      Jann Horn points out that the vmacache_flush_all() function is not only
      potentially expensive, it's buggy too.  It also happens to be entirely
      unnecessary, because the sequence number overflow case can be avoided by
      simply making the sequence number be 64-bit.  That doesn't even grow the
      data structures in question, because the other adjacent fields are
      already 64-bit.
      
      So simplify the whole thing by just making the sequence number overflow
      case go away entirely, which gets rid of all the complications and makes
      the code faster too.  Win-win.
      
      [ Oleg Nesterov points out that the VMACACHE_FULL_FLUSHES statistics
        also just goes away entirely with this ]
      Reported-by: default avatarJann Horn <jannh@google.com>
      Suggested-by: default avatarWill Deacon <will.deacon@arm.com>
      Acked-by: default avatarDavidlohr Bueso <dave@stgolabs.net>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      
      CVE-2018-17182
      
      (backported from commit 7a9cdebd)
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Signed-off-by: default avatarStefan Bader <stefan.bader@canonical.com>
      7ed926e6
    • Stefan Bader's avatar
      UBUNTU: Start new release · fff97d72
      Stefan Bader authored
      Ignore: yes
      Signed-off-by: default avatarStefan Bader <stefan.bader@canonical.com>
      fff97d72
  4. 11 Sep, 2018 3 commits