1. 03 Dec, 2015 32 commits
  2. 19 Nov, 2015 2 commits
    • David Howells's avatar
      KEYS: Fix crash when attempt to garbage collect an uninstantiated keyring · 16d8da6c
      David Howells authored
      [ Upstream commit f05819df ]
      
      The following sequence of commands:
      
          i=`keyctl add user a a @s`
          keyctl request2 keyring foo bar @t
          keyctl unlink $i @s
      
      tries to invoke an upcall to instantiate a keyring if one doesn't already
      exist by that name within the user's keyring set.  However, if the upcall
      fails, the code sets keyring->type_data.reject_error to -ENOKEY or some
      other error code.  When the key is garbage collected, the key destroy
      function is called unconditionally and keyring_destroy() uses list_empty()
      on keyring->type_data.link - which is in a union with reject_error.
      Subsequently, the kernel tries to unlink the keyring from the keyring names
      list - which oopses like this:
      
      	BUG: unable to handle kernel paging request at 00000000ffffff8a
      	IP: [<ffffffff8126e051>] keyring_destroy+0x3d/0x88
      	...
      	Workqueue: events key_garbage_collector
      	...
      	RIP: 0010:[<ffffffff8126e051>] keyring_destroy+0x3d/0x88
      	RSP: 0018:ffff88003e2f3d30  EFLAGS: 00010203
      	RAX: 00000000ffffff82 RBX: ffff88003bf1a900 RCX: 0000000000000000
      	RDX: 0000000000000000 RSI: 000000003bfc6901 RDI: ffffffff81a73a40
      	RBP: ffff88003e2f3d38 R08: 0000000000000152 R09: 0000000000000000
      	R10: ffff88003e2f3c18 R11: 000000000000865b R12: ffff88003bf1a900
      	R13: 0000000000000000 R14: ffff88003bf1a908 R15: ffff88003e2f4000
      	...
      	CR2: 00000000ffffff8a CR3: 000000003e3ec000 CR4: 00000000000006f0
      	...
      	Call Trace:
      	 [<ffffffff8126c756>] key_gc_unused_keys.constprop.1+0x5d/0x10f
      	 [<ffffffff8126ca71>] key_garbage_collector+0x1fa/0x351
      	 [<ffffffff8105ec9b>] process_one_work+0x28e/0x547
      	 [<ffffffff8105fd17>] worker_thread+0x26e/0x361
      	 [<ffffffff8105faa9>] ? rescuer_thread+0x2a8/0x2a8
      	 [<ffffffff810648ad>] kthread+0xf3/0xfb
      	 [<ffffffff810647ba>] ? kthread_create_on_node+0x1c2/0x1c2
      	 [<ffffffff815f2ccf>] ret_from_fork+0x3f/0x70
      	 [<ffffffff810647ba>] ? kthread_create_on_node+0x1c2/0x1c2
      
      Note the value in RAX.  This is a 32-bit representation of -ENOKEY.
      
      The solution is to only call ->destroy() if the key was successfully
      instantiated.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Tested-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      16d8da6c
    • David Howells's avatar
      KEYS: Fix race between key destruction and finding a keyring by name · 1ee2c9bd
      David Howells authored
      [ Upstream commit 94c4554b ]
      
      There appears to be a race between:
      
       (1) key_gc_unused_keys() which frees key->security and then calls
           keyring_destroy() to unlink the name from the name list
      
       (2) find_keyring_by_name() which calls key_permission(), thus accessing
           key->security, on a key before checking to see whether the key usage is 0
           (ie. the key is dead and might be cleaned up).
      
      Fix this by calling ->destroy() before cleaning up the core key data -
      including key->security.
      Reported-by: default avatarPetr Matousek <pmatouse@redhat.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      1ee2c9bd
  3. 15 Nov, 2015 6 commits
    • Eric Whitney's avatar
      ext4: fix loss of delalloc extent info in ext4_zero_range() · b1e06008
      Eric Whitney authored
      [ Upstream commit 94426f4b ]
      
      In ext4_zero_range(), removing a file's entire block range from the
      extent status tree removes all records of that file's delalloc extents.
      The delalloc accounting code uses this information, and its loss can
      then lead to accounting errors and kernel warnings at writeback time and
      subsequent file system damage.  This is most noticeable on bigalloc
      file systems where code in ext4_ext_map_blocks() handles cases where
      delalloc extents share clusters with a newly allocated extent.
      
      Because we're not deleting a block range and are correctly updating the
      status of its associated extent, there is no need to remove anything
      from the extent status tree.
      
      When this patch is combined with an unrelated bug fix for
      ext4_zero_range(), kernel warnings and e2fsck errors reported during
      xfstests runs on bigalloc filesystems are greatly reduced without
      introducing regressions on other xfstests-bld test scenarios.
      Signed-off-by: default avatarEric Whitney <enwlinux@gmail.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      b1e06008
    • Lukas Czerner's avatar
      ext4: allocate entire range in zero range · b9fca5cb
      Lukas Czerner authored
      [ Upstream commit 0f2af21a ]
      
      Currently there is a bug in zero range code which causes zero range
      calls to only allocate block aligned portion of the range, while
      ignoring the rest in some cases.
      
      In some cases, namely if the end of the range is past i_size, we do
      attempt to preallocate the last nonaligned block. However this might
      cause kernel to BUG() in some carefully designed zero range requests
      on setups where page size > block size.
      
      Fix this problem by first preallocating the entire range, including
      the nonaligned edges and converting the written extents to unwritten
      in the next step. This approach will also give us the advantage of
      having the range to be as linearly contiguous as possible.
      Signed-off-by: default avatarLukas Czerner <lczerner@redhat.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      b9fca5cb
    • Dan Carpenter's avatar
      vhost/scsi: potential memory corruption · 0812542d
      Dan Carpenter authored
      [ Upstream commit 59c816c1 ]
      
      This code in vhost_scsi_make_tpg() is confusing because we limit "tpgt"
      to UINT_MAX but the data type of "tpg->tport_tpgt" and that is a u16.
      
      I looked at the context and it turns out that in
      vhost_scsi_set_endpoint(), "tpg->tport_tpgt" is used as an offset into
      the vs_tpg[] array which has VHOST_SCSI_MAX_TARGET (256) elements so
      anything higher than 255 then it is invalid.  I have made that the limit
      now.
      
      In vhost_scsi_send_evt() we mask away values higher than 255, but now
      that the limit has changed, we don't need the mask.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      0812542d
    • Soeren Grunewald's avatar
      serial: 8250_pci: Add support for 12 port Exar boards · 52e98050
      Soeren Grunewald authored
      [ Upstream commit be32c0cf ]
      
      The Exar XR17V358 can also be combined with a XR17V354 chip to act as a
      single 12 port chip. This works the same way as the combining two XR17V358
      chips. But the reported device id then is 0x4358.
      Signed-off-by: default avatarSoeren Grunewald <soeren.grunewald@desy.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      52e98050
    • Soeren Grunewald's avatar
      serial: 8250_pci: Add support for 16 port Exar boards · f1963e21
      Soeren Grunewald authored
      [ Upstream commit 96a5d18b ]
      
      The Exar XR17V358 chip usually provides only 8 ports. But two chips can be
      combined to act as a single 16 port chip. Therefor one chip is configured
      as master the second as slave by connecting the mode pin to VCC (master)
      or GND (slave).
      
      Then the master chip is reporting a different device-id depending on
      whether a slave is detected or not. The UARTs 8-15 are addressed from
      0x2000-0x3fff. So the offset of 0x400 from UART to UART can be used to
      address all 16 ports as before.
      
      See: https://www.exar.com/common/content/document.ashx?id=1587 page 11
      Signed-off-by: default avatarSoeren Grunewald <soeren.grunewald@desy.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      f1963e21
    • Roman Gushchin's avatar
      md/raid5: fix locking in handle_stripe_clean_event() · 0ac9586c
      Roman Gushchin authored
      [ Upstream commit b8a9d66d ]
      
      After commit 566c09c5 ("raid5: relieve lock contention in get_active_stripe()")
      __find_stripe() is called under conf->hash_locks + hash.
      But handle_stripe_clean_event() calls remove_hash() under
      conf->device_lock.
      
      Under some cirscumstances the hash chain can be circuited,
      and we get an infinite loop with disabled interrupts and locked hash
      lock in __find_stripe(). This leads to hard lockup on multiple CPUs
      and following system crash.
      
      I was able to reproduce this behavior on raid6 over 6 ssd disks.
      The devices_handle_discard_safely option should be set to enable trim
      support. The following script was used:
      
      for i in `seq 1 32`; do
          dd if=/dev/zero of=large$i bs=10M count=100 &
      done
      
      neilb: original was against a 3.x kernel.  I forward-ported
        to 4.3-rc.  This verison is suitable for any kernel since
        Commit: 59fc630b ("RAID5: batch adjacent full stripe write")
        (v4.1+).  I'll post a version for earlier kernels to stable.
      Signed-off-by: default avatarRoman Gushchin <klamm@yandex-team.ru>
      Fixes: 566c09c5 ("raid5: relieve lock contention in get_active_stripe()")
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Cc: Shaohua Li <shli@kernel.org>
      Cc: <stable@vger.kernel.org> # 3.13 - 4.2
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      0ac9586c