[PATCH 4.4 00/74] 4.4.5-stable review

classic Classic list List threaded Threaded
86 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

[PATCH 4.4 03/74] Btrfs: fix deadlock running delayed iputs at transaction commit time

Greg KH-4
4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Filipe Manana <[hidden email]>

commit c2d6cb1636d235257086f939a8194ef0bf93af6e upstream.

While running a stress test I ran into a deadlock when running the delayed
iputs at transaction time, which produced the following report and trace:

[  886.399989] =============================================
[  886.400871] [ INFO: possible recursive locking detected ]
[  886.401663] 4.4.0-rc6-btrfs-next-18+ #1 Not tainted
[  886.402384] ---------------------------------------------
[  886.403182] fio/8277 is trying to acquire lock:
[  886.403568]  (&fs_info->delayed_iput_sem){++++..}, at: [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
[  886.403568]
[  886.403568] but task is already holding lock:
[  886.403568]  (&fs_info->delayed_iput_sem){++++..}, at: [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
[  886.403568]
[  886.403568] other info that might help us debug this:
[  886.403568]  Possible unsafe locking scenario:
[  886.403568]
[  886.403568]        CPU0
[  886.403568]        ----
[  886.403568]   lock(&fs_info->delayed_iput_sem);
[  886.403568]   lock(&fs_info->delayed_iput_sem);
[  886.403568]
[  886.403568]  *** DEADLOCK ***
[  886.403568]
[  886.403568]  May be due to missing lock nesting notation
[  886.403568]
[  886.403568] 3 locks held by fio/8277:
[  886.403568]  #0:  (sb_writers#11){.+.+.+}, at: [<ffffffff81174c4c>] __sb_start_write+0x5f/0xb0
[  886.403568]  #1:  (&sb->s_type->i_mutex_key#15){+.+.+.}, at: [<ffffffffa054620d>] btrfs_file_write_iter+0x73/0x408 [btrfs]
[  886.403568]  #2:  (&fs_info->delayed_iput_sem){++++..}, at: [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
[  886.403568]
[  886.403568] stack backtrace:
[  886.403568] CPU: 6 PID: 8277 Comm: fio Not tainted 4.4.0-rc6-btrfs-next-18+ #1
[  886.403568] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014
[  886.403568]  0000000000000000 ffff88009f80f770 ffffffff8125d4fd ffffffff82af1fc0
[  886.403568]  ffff88009f80f830 ffffffff8108e5f9 0000000200000000 ffff88009fd92290
[  886.403568]  0000000000000000 ffffffff82af1fc0 ffffffff829cfb01 00042b216d008804
[  886.403568] Call Trace:
[  886.403568]  [<ffffffff8125d4fd>] dump_stack+0x4e/0x79
[  886.403568]  [<ffffffff8108e5f9>] __lock_acquire+0xd42/0xf0b
[  886.403568]  [<ffffffff810c22db>] ? __module_address+0xdf/0x108
[  886.403568]  [<ffffffff8108eb77>] lock_acquire+0x10d/0x194
[  886.403568]  [<ffffffff8108eb77>] ? lock_acquire+0x10d/0x194
[  886.403568]  [<ffffffffa0538823>] ? btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
[  886.489542]  [<ffffffff8148556b>] down_read+0x3e/0x4d
[  886.489542]  [<ffffffffa0538823>] ? btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
[  886.489542]  [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs]
[  886.489542]  [<ffffffffa0533953>] btrfs_commit_transaction+0x8f5/0x96e [btrfs]
[  886.489542]  [<ffffffffa0521d7a>] flush_space+0x435/0x44a [btrfs]
[  886.489542]  [<ffffffffa052218b>] ? reserve_metadata_bytes+0x26a/0x384 [btrfs]
[  886.489542]  [<ffffffffa05221ae>] reserve_metadata_bytes+0x28d/0x384 [btrfs]
[  886.489542]  [<ffffffffa052256c>] ? btrfs_block_rsv_refill+0x58/0x96 [btrfs]
[  886.489542]  [<ffffffffa0522584>] btrfs_block_rsv_refill+0x70/0x96 [btrfs]
[  886.489542]  [<ffffffffa053d747>] btrfs_evict_inode+0x394/0x55a [btrfs]
[  886.489542]  [<ffffffff81188e31>] evict+0xa7/0x15c
[  886.489542]  [<ffffffff81189878>] iput+0x1d3/0x266
[  886.489542]  [<ffffffffa053887c>] btrfs_run_delayed_iputs+0x8f/0xbf [btrfs]
[  886.489542]  [<ffffffffa0533953>] btrfs_commit_transaction+0x8f5/0x96e [btrfs]
[  886.489542]  [<ffffffff81085096>] ? signal_pending_state+0x31/0x31
[  886.489542]  [<ffffffffa0521191>] btrfs_alloc_data_chunk_ondemand+0x1d7/0x288 [btrfs]
[  886.489542]  [<ffffffffa0521282>] btrfs_check_data_free_space+0x40/0x59 [btrfs]
[  886.489542]  [<ffffffffa05228f5>] btrfs_delalloc_reserve_space+0x1e/0x4e [btrfs]
[  886.489542]  [<ffffffffa053620a>] btrfs_direct_IO+0x10c/0x27e [btrfs]
[  886.489542]  [<ffffffff8111d9a1>] generic_file_direct_write+0xb3/0x128
[  886.489542]  [<ffffffffa05463c3>] btrfs_file_write_iter+0x229/0x408 [btrfs]
[  886.489542]  [<ffffffff8108ae38>] ? __lock_is_held+0x38/0x50
[  886.489542]  [<ffffffff8117279e>] __vfs_write+0x7c/0xa5
[  886.489542]  [<ffffffff81172cda>] vfs_write+0xa0/0xe4
[  886.489542]  [<ffffffff811734cc>] SyS_write+0x50/0x7e
[  886.489542]  [<ffffffff814872d7>] entry_SYSCALL_64_fastpath+0x12/0x6f
[ 1081.852335] INFO: task fio:8244 blocked for more than 120 seconds.
[ 1081.854348]       Not tainted 4.4.0-rc6-btrfs-next-18+ #1
[ 1081.857560] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1081.863227] fio        D ffff880213f9bb28     0  8244   8240 0x00000000
[ 1081.868719]  ffff880213f9bb28 00ffffff810fc6b0 ffffffff0000000a ffff88023ed55240
[ 1081.872499]  ffff880206b5d400 ffff880213f9c000 ffff88020a4d5318 ffff880206b5d400
[ 1081.876834]  ffffffff00000001 ffff880206b5d400 ffff880213f9bb40 ffffffff81482ba4
[ 1081.880782] Call Trace:
[ 1081.881793]  [<ffffffff81482ba4>] schedule+0x7f/0x97
[ 1081.883340]  [<ffffffff81485eb5>] rwsem_down_write_failed+0x2d5/0x325
[ 1081.895525]  [<ffffffff8108d48d>] ? trace_hardirqs_on_caller+0x16/0x1ab
[ 1081.897419]  [<ffffffff81269723>] call_rwsem_down_write_failed+0x13/0x20
[ 1081.899251]  [<ffffffff81269723>] ? call_rwsem_down_write_failed+0x13/0x20
[ 1081.901063]  [<ffffffff81089fae>] ? __down_write_nested.isra.0+0x1f/0x21
[ 1081.902365]  [<ffffffff814855bd>] down_write+0x43/0x57
[ 1081.903846]  [<ffffffffa05211b0>] ? btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs]
[ 1081.906078]  [<ffffffffa05211b0>] btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs]
[ 1081.908846]  [<ffffffff8108d461>] ? mark_held_locks+0x56/0x6c
[ 1081.910409]  [<ffffffffa0521282>] btrfs_check_data_free_space+0x40/0x59 [btrfs]
[ 1081.912482]  [<ffffffffa05228f5>] btrfs_delalloc_reserve_space+0x1e/0x4e [btrfs]
[ 1081.914597]  [<ffffffffa053620a>] btrfs_direct_IO+0x10c/0x27e [btrfs]
[ 1081.919037]  [<ffffffff8111d9a1>] generic_file_direct_write+0xb3/0x128
[ 1081.920754]  [<ffffffffa05463c3>] btrfs_file_write_iter+0x229/0x408 [btrfs]
[ 1081.922496]  [<ffffffff8108ae38>] ? __lock_is_held+0x38/0x50
[ 1081.923922]  [<ffffffff8117279e>] __vfs_write+0x7c/0xa5
[ 1081.925275]  [<ffffffff81172cda>] vfs_write+0xa0/0xe4
[ 1081.926584]  [<ffffffff811734cc>] SyS_write+0x50/0x7e
[ 1081.927968]  [<ffffffff814872d7>] entry_SYSCALL_64_fastpath+0x12/0x6f
[ 1081.985293] INFO: lockdep is turned off.
[ 1081.986132] INFO: task fio:8249 blocked for more than 120 seconds.
[ 1081.987434]       Not tainted 4.4.0-rc6-btrfs-next-18+ #1
[ 1081.988534] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1081.990147] fio        D ffff880218febbb8     0  8249   8240 0x00000000
[ 1081.991626]  ffff880218febbb8 00ffffff81486b8e ffff88020000000b ffff88023ed75240
[ 1081.993258]  ffff8802120a9a00 ffff880218fec000 ffff88020a4d5318 ffff8802120a9a00
[ 1081.994850]  ffffffff00000001 ffff8802120a9a00 ffff880218febbd0 ffffffff81482ba4
[ 1081.996485] Call Trace:
[ 1081.997037]  [<ffffffff81482ba4>] schedule+0x7f/0x97
[ 1081.998017]  [<ffffffff81485eb5>] rwsem_down_write_failed+0x2d5/0x325
[ 1081.999241]  [<ffffffff810852a5>] ? finish_wait+0x6d/0x76
[ 1082.000306]  [<ffffffff81269723>] call_rwsem_down_write_failed+0x13/0x20
[ 1082.001533]  [<ffffffff81269723>] ? call_rwsem_down_write_failed+0x13/0x20
[ 1082.002776]  [<ffffffff81089fae>] ? __down_write_nested.isra.0+0x1f/0x21
[ 1082.003995]  [<ffffffff814855bd>] down_write+0x43/0x57
[ 1082.005000]  [<ffffffffa05211b0>] ? btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs]
[ 1082.007403]  [<ffffffffa05211b0>] btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs]
[ 1082.008988]  [<ffffffffa0545064>] btrfs_fallocate+0x7c1/0xc2f [btrfs]
[ 1082.010193]  [<ffffffff8108a1ba>] ? percpu_down_read+0x4e/0x77
[ 1082.011280]  [<ffffffff81174c4c>] ? __sb_start_write+0x5f/0xb0
[ 1082.012265]  [<ffffffff81174c4c>] ? __sb_start_write+0x5f/0xb0
[ 1082.013021]  [<ffffffff811712e4>] vfs_fallocate+0x170/0x1ff
[ 1082.013738]  [<ffffffff81181ebb>] ioctl_preallocate+0x89/0x9b
[ 1082.014778]  [<ffffffff811822d7>] do_vfs_ioctl+0x40a/0x4ea
[ 1082.015778]  [<ffffffff81176ea7>] ? SYSC_newfstat+0x25/0x2e
[ 1082.016806]  [<ffffffff8118b4de>] ? __fget_light+0x4d/0x71
[ 1082.017789]  [<ffffffff8118240e>] SyS_ioctl+0x57/0x79
[ 1082.018706]  [<ffffffff814872d7>] entry_SYSCALL_64_fastpath+0x12/0x6f

This happens because we can recursively acquire the semaphore
fs_info->delayed_iput_sem when attempting to allocate space to satisfy
a file write request as shown in the first trace above - when committing
a transaction we acquire (down_read) the semaphore before running the
delayed iputs, and when running a delayed iput() we can end up calling
an inode's eviction handler, which in turn commits another transaction
and attempts to acquire (down_read) again the semaphore to run more
delayed iput operations.
This results in a deadlock because if a task acquires multiple times a
semaphore it should invoke down_read_nested() with a different lockdep
class for each level of recursion.

Fix this by simplifying the implementation and use a mutex instead that
is acquired by the cleaner kthread before it runs the delayed iputs
instead of always acquiring a semaphore before delayed references are
run from anywhere.

Fixes: d7c151717a1e (btrfs: Fix NO_SPACE bug caused by delayed-iput)
Signed-off-by: Filipe Manana <[hidden email]>
Signed-off-by: Chris Mason <[hidden email]>
Signed-off-by: Greg Kroah-Hartman <[hidden email]>

---
 fs/btrfs/ctree.h       |    2 +-
 fs/btrfs/disk-io.c     |    5 ++++-
 fs/btrfs/extent-tree.c |    9 +++++----
 fs/btrfs/inode.c       |    4 ----
 4 files changed, 10 insertions(+), 10 deletions(-)

--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -1572,7 +1572,7 @@ struct btrfs_fs_info {
 
  spinlock_t delayed_iput_lock;
  struct list_head delayed_iputs;
- struct rw_semaphore delayed_iput_sem;
+ struct mutex cleaner_delayed_iput_mutex;
 
  /* this protects tree_mod_seq_list */
  spinlock_t tree_mod_seq_lock;
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -1796,7 +1796,10 @@ static int cleaner_kthread(void *arg)
  goto sleep;
  }
 
+ mutex_lock(&root->fs_info->cleaner_delayed_iput_mutex);
  btrfs_run_delayed_iputs(root);
+ mutex_unlock(&root->fs_info->cleaner_delayed_iput_mutex);
+
  again = btrfs_clean_one_deleted_snapshot(root);
  mutex_unlock(&root->fs_info->cleaner_mutex);
 
@@ -2556,8 +2559,8 @@ int open_ctree(struct super_block *sb,
  mutex_init(&fs_info->delete_unused_bgs_mutex);
  mutex_init(&fs_info->reloc_mutex);
  mutex_init(&fs_info->delalloc_root_mutex);
+ mutex_init(&fs_info->cleaner_delayed_iput_mutex);
  seqlock_init(&fs_info->profiles_lock);
- init_rwsem(&fs_info->delayed_iput_sem);
 
  INIT_LIST_HEAD(&fs_info->dirty_cowonly_roots);
  INIT_LIST_HEAD(&fs_info->space_info);
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -4100,11 +4100,12 @@ commit_trans:
  if (ret)
  return ret;
  /*
- * make sure that all running delayed iput are
- * done
+ * The cleaner kthread might still be doing iput
+ * operations. Wait for it to finish so that
+ * more space is released.
  */
- down_write(&root->fs_info->delayed_iput_sem);
- up_write(&root->fs_info->delayed_iput_sem);
+ mutex_lock(&root->fs_info->cleaner_delayed_iput_mutex);
+ mutex_unlock(&root->fs_info->cleaner_delayed_iput_mutex);
  goto again;
  } else {
  btrfs_end_transaction(trans, root);
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -3142,8 +3142,6 @@ void btrfs_run_delayed_iputs(struct btrf
  if (empty)
  return;
 
- down_read(&fs_info->delayed_iput_sem);
-
  spin_lock(&fs_info->delayed_iput_lock);
  list_splice_init(&fs_info->delayed_iputs, &list);
  spin_unlock(&fs_info->delayed_iput_lock);
@@ -3154,8 +3152,6 @@ void btrfs_run_delayed_iputs(struct btrf
  iput(delayed->inode);
  kfree(delayed);
  }
-
- up_read(&root->fs_info->delayed_iput_sem);
 }
 
 /*


Reply | Threaded
Open this post in threaded view
|

[PATCH 4.4 12/74] fbcon: set a default value to blink interval

Greg KH-4
In reply to this post by Greg KH-4
4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Jean-Philippe Brucker <[hidden email]>

commit a1e533ec07d583d01349ef13c0c965b8633e1b91 upstream.

Since commit 27a4c827c34ac4256a190cc9d24607f953c1c459
        fbcon: use the cursor blink interval provided by vt

two attempts have been made at fixing a possible hang caused by
cursor_timer_handler. That function registers a timer to be triggered at
"jiffies + fbcon_ops.cur_blink_jiffies".

A new case had been encountered during initialisation of clcd-pl11x:

    fbcon_fb_registered
    do_fbcon_takeover

    ->  do_register_con_driver
        fbcon_startup
    (A) add_cursor_timer (with cur_blink_jiffies = 0)

    ->  do_bind_con_driver
        visual_init
        fbcon_init
    (B) cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);

If we take an softirq anywhere between A and B (and we do),
cursor_timer_handler executes indefinitely.

Instead of patching all possible paths that lead to this case one at a
time, fix the issue at the source and initialise cur_blink_jiffies to
200ms when allocating fbcon_ops. This was its default value before
aforesaid commit. fbcon_cursor or fbcon_init will refine this value
downstream.

Signed-off-by: Jean-Philippe Brucker <[hidden email]>
Tested-by: Scot Doyle <[hidden email]>
Signed-off-by: Tomi Valkeinen <[hidden email]>
Signed-off-by: Greg Kroah-Hartman <[hidden email]>

---
 drivers/video/console/fbcon.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -709,6 +709,7 @@ static int con2fb_acquire_newinfo(struct
  }
 
  if (!err) {
+ ops->cur_blink_jiffies = HZ / 5;
  info->fbcon_par = ops;
 
  if (vc)
@@ -956,6 +957,7 @@ static const char *fbcon_startup(void)
  ops->currcon = -1;
  ops->graphics = 1;
  ops->cur_rotate = -1;
+ ops->cur_blink_jiffies = HZ / 5;
  info->fbcon_par = ops;
  p->con_rotate = initial_rotation;
  set_blitting_type(vc, info);


Reply | Threaded
Open this post in threaded view
|

[PATCH 4.4 16/74] vfio: fix ioctl error handling

Greg KH-4
In reply to this post by Greg KH-4
4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Michael S. Tsirkin <[hidden email]>

commit 8160c4e455820d5008a1116d2dca35f0363bb062 upstream.

Calling return copy_to_user(...) in an ioctl will not
do the right thing if there's a pagefault:
copy_to_user returns the number of bytes not copied
in this case.

Fix up vfio to do
        return copy_to_user(...)) ?
                -EFAULT : 0;

everywhere.

Signed-off-by: Michael S. Tsirkin <[hidden email]>
Signed-off-by: Alex Williamson <[hidden email]>
Signed-off-by: Greg Kroah-Hartman <[hidden email]>

---
 drivers/vfio/pci/vfio_pci.c                  |    9 ++++++---
 drivers/vfio/platform/vfio_platform_common.c |    9 ++++++---
 drivers/vfio/vfio_iommu_type1.c              |    6 ++++--
 3 files changed, 16 insertions(+), 8 deletions(-)

--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -446,7 +446,8 @@ static long vfio_pci_ioctl(void *device_
  info.num_regions = VFIO_PCI_NUM_REGIONS;
  info.num_irqs = VFIO_PCI_NUM_IRQS;
 
- return copy_to_user((void __user *)arg, &info, minsz);
+ return copy_to_user((void __user *)arg, &info, minsz) ?
+ -EFAULT : 0;
 
  } else if (cmd == VFIO_DEVICE_GET_REGION_INFO) {
  struct pci_dev *pdev = vdev->pdev;
@@ -520,7 +521,8 @@ static long vfio_pci_ioctl(void *device_
  return -EINVAL;
  }
 
- return copy_to_user((void __user *)arg, &info, minsz);
+ return copy_to_user((void __user *)arg, &info, minsz) ?
+ -EFAULT : 0;
 
  } else if (cmd == VFIO_DEVICE_GET_IRQ_INFO) {
  struct vfio_irq_info info;
@@ -555,7 +557,8 @@ static long vfio_pci_ioctl(void *device_
  else
  info.flags |= VFIO_IRQ_INFO_NORESIZE;
 
- return copy_to_user((void __user *)arg, &info, minsz);
+ return copy_to_user((void __user *)arg, &info, minsz) ?
+ -EFAULT : 0;
 
  } else if (cmd == VFIO_DEVICE_SET_IRQS) {
  struct vfio_irq_set hdr;
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -219,7 +219,8 @@ static long vfio_platform_ioctl(void *de
  info.num_regions = vdev->num_regions;
  info.num_irqs = vdev->num_irqs;
 
- return copy_to_user((void __user *)arg, &info, minsz);
+ return copy_to_user((void __user *)arg, &info, minsz) ?
+ -EFAULT : 0;
 
  } else if (cmd == VFIO_DEVICE_GET_REGION_INFO) {
  struct vfio_region_info info;
@@ -240,7 +241,8 @@ static long vfio_platform_ioctl(void *de
  info.size = vdev->regions[info.index].size;
  info.flags = vdev->regions[info.index].flags;
 
- return copy_to_user((void __user *)arg, &info, minsz);
+ return copy_to_user((void __user *)arg, &info, minsz) ?
+ -EFAULT : 0;
 
  } else if (cmd == VFIO_DEVICE_GET_IRQ_INFO) {
  struct vfio_irq_info info;
@@ -259,7 +261,8 @@ static long vfio_platform_ioctl(void *de
  info.flags = vdev->irqs[info.index].flags;
  info.count = vdev->irqs[info.index].count;
 
- return copy_to_user((void __user *)arg, &info, minsz);
+ return copy_to_user((void __user *)arg, &info, minsz) ?
+ -EFAULT : 0;
 
  } else if (cmd == VFIO_DEVICE_SET_IRQS) {
  struct vfio_irq_set hdr;
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -999,7 +999,8 @@ static long vfio_iommu_type1_ioctl(void
 
  info.iova_pgsizes = vfio_pgsize_bitmap(iommu);
 
- return copy_to_user((void __user *)arg, &info, minsz);
+ return copy_to_user((void __user *)arg, &info, minsz) ?
+ -EFAULT : 0;
 
  } else if (cmd == VFIO_IOMMU_MAP_DMA) {
  struct vfio_iommu_type1_dma_map map;
@@ -1032,7 +1033,8 @@ static long vfio_iommu_type1_ioctl(void
  if (ret)
  return ret;
 
- return copy_to_user((void __user *)arg, &unmap, minsz);
+ return copy_to_user((void __user *)arg, &unmap, minsz) ?
+ -EFAULT : 0;
  }
 
  return -ENOTTY;


Reply | Threaded
Open this post in threaded view
|

[PATCH 4.4 10/74] mips/kvm: fix ioctl error handling

Greg KH-4
In reply to this post by Greg KH-4
4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Michael S. Tsirkin <[hidden email]>

commit 0178fd7dcc4451fcb90bec5e91226586962478d2 upstream.

Returning directly whatever copy_to_user(...) or copy_from_user(...)
returns may not do the right thing if there's a pagefault:
copy_to_user/copy_from_user return the number of bytes not copied in
this case, but ioctls need to return -EFAULT instead.

Fix up kvm on mips to do
        return copy_to_user(...)) ?  -EFAULT : 0;
and
        return copy_from_user(...)) ?  -EFAULT : 0;

everywhere.

Signed-off-by: Michael S. Tsirkin <[hidden email]>
Signed-off-by: Paolo Bonzini <[hidden email]>
Signed-off-by: Greg Kroah-Hartman <[hidden email]>

---
 arch/mips/kvm/mips.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/mips/kvm/mips.c
+++ b/arch/mips/kvm/mips.c
@@ -702,7 +702,7 @@ static int kvm_mips_get_reg(struct kvm_v
  } else if ((reg->id & KVM_REG_SIZE_MASK) == KVM_REG_SIZE_U128) {
  void __user *uaddr = (void __user *)(long)reg->addr;
 
- return copy_to_user(uaddr, vs, 16);
+ return copy_to_user(uaddr, vs, 16) ? -EFAULT : 0;
  } else {
  return -EINVAL;
  }
@@ -732,7 +732,7 @@ static int kvm_mips_set_reg(struct kvm_v
  } else if ((reg->id & KVM_REG_SIZE_MASK) == KVM_REG_SIZE_U128) {
  void __user *uaddr = (void __user *)(long)reg->addr;
 
- return copy_from_user(vs, uaddr, 16);
+ return copy_from_user(vs, uaddr, 16) ? -EFAULT : 0;
  } else {
  return -EINVAL;
  }


Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 4.4 00/74] 4.4.5-stable review

Sedat Dilek-2
In reply to this post by Greg KH-4
Hi Greg,

I tested with my usual setup/config.

Looks good so far.

Missing some net-ppp-fixes / overlayfs-fixes / userfaultfd-fixes, but
I guess you will pick them up in a 6th run of Linux v4.4.y.

Regards,
- Sedat -

dmesg_4.4.5-rc1-1-iniza-small.txt (74K) Download Attachment
config-4.4.5-rc1-1-iniza-small (175K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 4.4 34/74] arm64: vmemmap: use virtual projection of linear region

Ard Biesheuvel
In reply to this post by Greg KH-4
On 8 March 2016 at 07:02, Greg Kroah-Hartman <[hidden email]> wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>

Please hold off on this one. We are seeing some breakage on 64k pages systems

> ------------------
>
> From: Ard Biesheuvel <[hidden email]>
>
> commit dfd55ad85e4a7fbaa82df12467515ac3c81e8a3e upstream.
>
> Commit dd006da21646 ("arm64: mm: increase VA range of identity map") made
> some changes to the memory mapping code to allow physical memory to reside
> at an offset that exceeds the size of the virtual mapping.
>
> However, since the size of the vmemmap area is proportional to the size of
> the VA area, but it is populated relative to the physical space, we may
> end up with the struct page array being mapped outside of the vmemmap
> region. For instance, on my Seattle A0 box, I can see the following output
> in the dmesg log.
>
>    vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000   (     8 GB maximum)
>              0xffffffbfc0000000 - 0xffffffbfd0000000   (   256 MB actual)
>
> We can fix this by deciding that the vmemmap region is not a projection of
> the physical space, but of the virtual space above PAGE_OFFSET, i.e., the
> linear region. This way, we are guaranteed that the vmemmap region is of
> sufficient size, and we can even reduce the size by half.
>
> Signed-off-by: Ard Biesheuvel <[hidden email]>
> Signed-off-by: Will Deacon <[hidden email]>
> Signed-off-by: Greg Kroah-Hartman <[hidden email]>
>
> ---
>  arch/arm64/include/asm/pgtable.h |    7 ++++---
>  arch/arm64/mm/init.c             |    4 ++--
>  2 files changed, 6 insertions(+), 5 deletions(-)
>
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -34,13 +34,13 @@
>  /*
>   * VMALLOC and SPARSEMEM_VMEMMAP ranges.
>   *
> - * VMEMAP_SIZE: allows the whole VA space to be covered by a struct page array
> + * VMEMAP_SIZE: allows the whole linear region to be covered by a struct page array
>   *     (rounded up to PUD_SIZE).
>   * VMALLOC_START: beginning of the kernel VA space
>   * VMALLOC_END: extends to the available space below vmmemmap, PCI I/O space,
>   *     fixed mappings and modules
>   */
> -#define VMEMMAP_SIZE           ALIGN((1UL << (VA_BITS - PAGE_SHIFT)) * sizeof(struct page), PUD_SIZE)
> +#define VMEMMAP_SIZE           ALIGN((1UL << (VA_BITS - PAGE_SHIFT - 1)) * sizeof(struct page), PUD_SIZE)
>
>  #ifndef CONFIG_KASAN
>  #define VMALLOC_START          (VA_START)
> @@ -51,7 +51,8 @@
>
>  #define VMALLOC_END            (PAGE_OFFSET - PUD_SIZE - VMEMMAP_SIZE - SZ_64K)
>
> -#define vmemmap                        ((struct page *)(VMALLOC_END + SZ_64K))
> +#define VMEMMAP_START          (VMALLOC_END + SZ_64K)
> +#define vmemmap                        ((struct page *)VMEMMAP_START - (memstart_addr >> PAGE_SHIFT))
>
>  #define FIRST_USER_ADDRESS     0UL
>
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -319,8 +319,8 @@ void __init mem_init(void)
>  #endif
>                   MLG(VMALLOC_START, VMALLOC_END),
>  #ifdef CONFIG_SPARSEMEM_VMEMMAP
> -                 MLG((unsigned long)vmemmap,
> -                     (unsigned long)vmemmap + VMEMMAP_SIZE),
> +                 MLG(VMEMMAP_START,
> +                     VMEMMAP_START + VMEMMAP_SIZE),
>                   MLM((unsigned long)virt_to_page(PAGE_OFFSET),
>                       (unsigned long)virt_to_page(high_memory)),
>  #endif
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 4.4 00/74] 4.4.5-stable review

Guenter Roeck-5
In reply to this post by Greg KH-4
On Mon, Mar 07, 2016 at 04:02:25PM -0800, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.5 release.
> There are 74 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Mar 10 00:02:56 UTC 2016.
> Anything received after that time might be too late.
>
Build results:
        total: 145 pass: 145 fail: 0
Qemu test results:
        total: 96 pass: 96 fail: 0

Detaila are available at http://kerneltests.org/builders.

Guenter
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 4.4 00/74] 4.4.5-stable review

Greg KH-4
In reply to this post by Sedat Dilek-2
On Tue, Mar 08, 2016 at 10:12:13AM +0100, Sedat Dilek wrote:
> Hi Greg,
>
> I tested with my usual setup/config.
>
> Looks good so far.
>
> Missing some net-ppp-fixes / overlayfs-fixes / userfaultfd-fixes, but
> I guess you will pick them up in a 6th run of Linux v4.4.y.

I have no idea what these "fixes" are you speak of, my queue is empty,
there are no known stable patches I haven't applied yet.  What exactly
are you referring to here?

thansk,

greg k-h
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 4.4 34/74] arm64: vmemmap: use virtual projection of linear region

Greg KH-4
In reply to this post by Ard Biesheuvel
On Tue, Mar 08, 2016 at 05:40:14PM +0700, Ard Biesheuvel wrote:
> On 8 March 2016 at 07:02, Greg Kroah-Hartman <[hidden email]> wrote:
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> >
>
> Please hold off on this one. We are seeing some breakage on 64k pages systems

If this problem is also in Linus's tree, I'd like to keep it in to keep
things "bug compatible".  Please let me know what fix that I should
apply to resolve this.

thanks,

greg k-h
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 4.4 34/74] arm64: vmemmap: use virtual projection of linear region

Ard Biesheuvel
On 8 March 2016 at 20:44, Greg Kroah-Hartman <[hidden email]> wrote:

> On Tue, Mar 08, 2016 at 05:40:14PM +0700, Ard Biesheuvel wrote:
>> On 8 March 2016 at 07:02, Greg Kroah-Hartman <[hidden email]> wrote:
>> > 4.4-stable review patch.  If anyone has any objections, please let me know.
>> >
>>
>> Please hold off on this one. We are seeing some breakage on 64k pages systems
>
> If this problem is also in Linus's tree, I'd like to keep it in to keep
> things "bug compatible".  Please let me know what fix that I should
> apply to resolve this.
>

I am about to send out the patch that should fix this, so I will put you on cc.

Thanks,
Ard.
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 4.4 00/74] 4.4.5-stable review

Greg KH-4
In reply to this post by Guenter Roeck-5
On Tue, Mar 08, 2016 at 03:45:59AM -0800, Guenter Roeck wrote:

> On Mon, Mar 07, 2016 at 04:02:25PM -0800, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.5 release.
> > There are 74 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu Mar 10 00:02:56 UTC 2016.
> > Anything received after that time might be too late.
> >
> Build results:
> total: 145 pass: 145 fail: 0
> Qemu test results:
> total: 96 pass: 96 fail: 0
>
> Detaila are available at http://kerneltests.org/builders.

Thanks for testing all of these and letting me know.

greg k-h
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 4.4 00/74] 4.4.5-stable review

Greg KH-4
In reply to this post by Greg KH-4
On Tue, Mar 08, 2016 at 02:11:08AM -0800, kernelci.org bot wrote:

> stable-queue boot: 205 boots: 14 failed, 190 passed with 1 offline (v4.4.4-74-gcc3ba9c14b31)
>
> Full Boot Summary: https://kernelci.org/boot/all/job/stable-queue/kernel/v4.4.4-74-gcc3ba9c14b31/
> Full Build Summary: https://kernelci.org/build/stable-queue/kernel/v4.4.4-74-gcc3ba9c14b31/
>
> Tree: stable-queue
> Branch: local/linux-4.4.y.queue
> Git Describe: v4.4.4-74-gcc3ba9c14b31
> Git Commit: cc3ba9c14b31161587ce85e9b5d642e730a2d0e8
> Git URL: git://server.roeck-us.net/git/linux-stable.git
> Tested: 47 unique boards, 13 SoC families, 18 builds out of 132
>
> Boot Failures Detected: https://kernelci.org/boot/?v4.4.4-74-gcc3ba9c14b31&fail
>
> arm:
>
>     mxs_defconfig:
>         imx23-olinuxino: 1 failed lab
>
>     omap2plus_defconfig:
>         omap4-panda: 1 failed lab
>
>     multi_v7_defconfig+CONFIG_LKDTM=y:
>         imx53-qsrb: 1 failed lab
>         imx6dl-riotboard: 1 failed lab
>         socfpga_cyclone5_socrates: 1 failed lab
>
>     multi_v7_defconfig+CONFIG_SMP=n:
>         imx53-qsrb: 1 failed lab
>         imx6dl-riotboard: 1 failed lab
>         socfpga_cyclone5_socrates: 1 failed lab
>
>     multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y:
>         socfpga_cyclone5_socrates: 1 failed lab
>
>     imx_v6_v7_defconfig:
>         imx53-qsrb: 1 failed lab
>         imx6dl-riotboard: 1 failed lab
>
>     multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
>         imx53-qsrb: 1 failed lab
>         imx6dl-riotboard: 1 failed lab
>         socfpga_cyclone5_socrates: 1 failed lab
>
> Offline Platforms:
>
> arm:
>
>     mxs_defconfig:
>         imx28-duckbill: 1 offline lab

I really don't know what these mean, any chance you can distill these
down to "all is fine", or "there is a problem with this arch" type
emails?

thanks,

greg k-h
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 4.4 00/74] 4.4.5-stable review

Sedat Dilek-2
In reply to this post by Greg KH-4
On Tue, Mar 8, 2016 at 2:39 PM, Greg Kroah-Hartman
<[hidden email]> wrote:

> On Tue, Mar 08, 2016 at 10:12:13AM +0100, Sedat Dilek wrote:
>> Hi Greg,
>>
>> I tested with my usual setup/config.
>>
>> Looks good so far.
>>
>> Missing some net-ppp-fixes / overlayfs-fixes / userfaultfd-fixes, but
>> I guess you will pick them up in a 6th run of Linux v4.4.y.
>
> I have no idea what these "fixes" are you speak of, my queue is empty,
> there are no known stable patches I haven't applied yet.  What exactly
> are you referring to here?
>
> thansk,
>
>

Here we go...

[1] "userfaultfd: don't block on the last VM updates at exit time"

[2] "ppp: release rtnl mutex when interface creation fails"

( I was involved in... Fixes: 58a89ecaca53 ("ppp: fix lockdep splat in
ppp_dev_uninit()" )

[3] "ovl: fix working on distributed fs as lower layer"

BTW, in [1] Linus forgot to add a "CC:stable", how is this handled
when a maintainer forgets this?
Once I read something like "CC:stable # Backport to all applicable
versions". Is that "allowed"?
And yes, netdev has its own rules, so - no comments on this.

- Sedat -

[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=39680f50ae54cbbb6e72ac38b8329dd3eb9105f4
[2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6faac63a6986f29ef39827f460edd3a5ba64ad5c
[3] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b5891cfab08fe3144a616e8e734df7749fb3b7d0
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 4.4 00/74] 4.4.5-stable review

Shuah Khan-5
In reply to this post by Greg KH-4
On 03/07/2016 05:02 PM, Greg Kroah-Hartman wrote:

> This is the start of the stable review cycle for the 4.4.5 release.
> There are 74 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Mar 10 00:02:56 UTC 2016.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.5-rc1.gz
> and the diffstat can be found below.
>

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
[hidden email] | (970) 217-8978
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 4.4 00/74] 4.4.5-stable review

Greg KH-4
On Tue, Mar 08, 2016 at 09:24:17AM -0700, Shuah Khan wrote:

> On 03/07/2016 05:02 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.5 release.
> > There are 74 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu Mar 10 00:02:56 UTC 2016.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.5-rc1.gz
> > and the diffstat can be found below.
> >
>
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 4.4 13/74] cifs: fix out-of-bounds access in lease parsing

Ben Hutchings
In reply to this post by Greg KH-4
On Mon, 2016-03-07 at 16:02 -0800, Greg Kroah-Hartman wrote:

> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Justin Maggard <[hidden email]>
>
> commit deb7deff2f00bdbbcb3d560dad2a89ef37df837d upstream.
>
> When opening a file, SMB2_open() attempts to parse the lease state from the
> SMB2 CREATE Response.  However, the parsing code was not careful to ensure
> that the create contexts are not empty or invalid, which can lead to out-
> of-bounds memory access.  This can be seen easily by trying
> to read a file from a OSX 10.11 SMB3 server.  Here is sample crash output:
>
> BUG: unable to handle kernel paging request at ffff8800a1a77cc6
> IP: [] SMB2_open+0x804/0x960
> PGD 8f77067 PUD 0
> Oops: 0000 [#1] SMP
> Modules linked in:
> CPU: 3 PID: 2876 Comm: cp Not tainted 4.5.0-rc3.x86_64.1+ #14
> Hardware name: NETGEAR ReadyNAS 314          /ReadyNAS 314          , BIOS 4.6.5 10/11/2012
> task: ffff880073cdc080 ti: ffff88005b31c000 task.ti: ffff88005b31c000
> RIP: 0010:[]  [] SMB2_open+0x804/0x960
> RSP: 0018:ffff88005b31fa08  EFLAGS: 00010282
> RAX: 0000000000000015 RBX: 0000000000000000 RCX: 0000000000000006
> RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff88007eb8c8b0
> RBP: ffff88005b31fad8 R08: 666666203d206363 R09: 6131613030383866
> R10: 3030383866666666 R11: 00000000000002b0 R12: ffff8800660fd800
> R13: ffff8800a1a77cc2 R14: 00000000424d53fe R15: ffff88005f5a28c0
> FS:  00007f7c8a2897c0(0000) GS:ffff88007eb80000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: ffff8800a1a77cc6 CR3: 000000005b281000 CR4: 00000000000006e0
> Stack:
>  ffff88005b31fa70 ffffffff88278789 00000000000001d3 ffff88005f5a2a80
>  ffffffff00000003 ffff88005d029d00 ffff88006fde05a0 0000000000000000
>  ffff88005b31fc78 ffff88006fde0780 ffff88005b31fb2f 0000000100000fe0
> Call Trace:
>  [] ? cifsConvertToUTF16+0x159/0x2d0
>  [] smb2_open_file+0x98/0x210
>  [] ? __kmalloc+0x1c/0xe0
>  [] cifs_open+0x2a4/0x720
>  [] do_dentry_open+0x1ff/0x310
>  [] ? cifsFileInfo_get+0x30/0x30
>  [] vfs_open+0x52/0x60
>  [] path_openat+0x170/0xf70
>  [] ? remove_wait_queue+0x48/0x50
>  [] do_filp_open+0x79/0xd0
>  [] ? __alloc_fd+0x3a/0x170
>  [] do_sys_open+0x114/0x1e0
>  [] SyS_open+0x19/0x20
>  [] entry_SYSCALL_64_fastpath+0x12/0x6a
> Code: 4d 8d 6c 07 04 31 c0 4c 89 ee e8 47 6f e5 ff 31 c9 41 89 ce 44 89 f1 48 c7 c7 28 b1 bd 88 31 c0 49 01 cd 4c 89 ee e8 2b 6f e5 ff <45> 0f b7 75 04 48 c7 c7 31 b1 bd 88 31 c0 4d 01 ee 4c 89 f6 e8
> RIP  [] SMB2_open+0x804/0x960
>  RSP
> CR2: ffff8800a1a77cc6
> ---[ end trace d9f69ba64feee469 ]---
>
> Signed-off-by: Justin Maggard <[hidden email]>
> Signed-off-by: Steve French <[hidden email]>
> Signed-off-by: Greg Kroah-Hartman <[hidden email]>
>
> ---
>  fs/cifs/smb2pdu.c |   24 ++++++++++++++----------
>  1 file changed, 14 insertions(+), 10 deletions(-)
>
> --- a/fs/cifs/smb2pdu.c
> +++ b/fs/cifs/smb2pdu.c
> @@ -1109,21 +1109,25 @@ parse_lease_state(struct TCP_Server_Info
>  {
>   char *data_offset;
>   struct create_context *cc;
> - unsigned int next = 0;
> + unsigned int next;
> + unsigned int remaining;
>   char *name;
>  
>   data_offset = (char *)rsp + 4 + le32_to_cpu(rsp->CreateContextsOffset);
> + remaining = le32_to_cpu(rsp->CreateContextsLength);
What if remaining is > the response length?

>   cc = (struct create_context *)data_offset;
> - do {
> - cc = (struct create_context *)((char *)cc + next);
> + while (remaining >= sizeof(struct create_context)) {
>   name = le16_to_cpu(cc->NameOffset) + (char *)cc;
> - if (le16_to_cpu(cc->NameLength) != 4 ||
> -     strncmp(name, "RqLs", 4)) {
> - next = le32_to_cpu(cc->Next);
> - continue;
> - }
> - return server->ops->parse_lease_buf(cc, epoch);
> - } while (next != 0);
> + if (le16_to_cpu(cc->NameLength) == 4 &&
> +     strncmp(name, "RqLs", 4) == 0)
> + return server->ops->parse_lease_buf(cc, epoch);
> +
> + next = le32_to_cpu(cc->Next);
> + if (!next)
> + break;
> + remaining -= next;
What if next > remaining?

This change seems to be only scratching the surface of the security
failure here.

Ben.

> + cc = (struct create_context *)((char *)cc + next);
> + }
>  
>   return 0;
>  }

--
Ben Hutchings
When in doubt, use brute force. - Ken Thompson

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 4.4 13/74] cifs: fix out-of-bounds access in lease parsing

Steve French-2
On Tue, Mar 8, 2016 at 9:47 PM, Ben Hutchings <[hidden email]> wrote:

> On Mon, 2016-03-07 at 16:02 -0800, Greg Kroah-Hartman wrote:
>> 4.4-stable review patch.  If anyone has any objections, please let me know.
>>
>> ------------------
>>
>> From: Justin Maggard <[hidden email]>
>>
>> commit deb7deff2f00bdbbcb3d560dad2a89ef37df837d upstream.
>>
>> When opening a file, SMB2_open() attempts to parse the lease state from the
>> SMB2 CREATE Response.  However, the parsing code was not careful to ensure
>> that the create contexts are not empty or invalid, which can lead to out-
>> of-bounds memory access.  This can be seen easily by trying
>> to read a file from a OSX 10.11 SMB3 server.  Here is sample crash output:
>>
>> BUG: unable to handle kernel paging request at ffff8800a1a77cc6
>> IP: [] SMB2_open+0x804/0x960
>> PGD 8f77067 PUD 0
>> Oops: 0000 [#1] SMP
>> Modules linked in:
>> CPU: 3 PID: 2876 Comm: cp Not tainted 4.5.0-rc3.x86_64.1+ #14
>> Hardware name: NETGEAR ReadyNAS 314          /ReadyNAS 314          , BIOS 4.6.5 10/11/2012
>> task: ffff880073cdc080 ti: ffff88005b31c000 task.ti: ffff88005b31c000
>> RIP: 0010:[]  [] SMB2_open+0x804/0x960
>> RSP: 0018:ffff88005b31fa08  EFLAGS: 00010282
>> RAX: 0000000000000015 RBX: 0000000000000000 RCX: 0000000000000006
>> RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff88007eb8c8b0
>> RBP: ffff88005b31fad8 R08: 666666203d206363 R09: 6131613030383866
>> R10: 3030383866666666 R11: 00000000000002b0 R12: ffff8800660fd800
>> R13: ffff8800a1a77cc2 R14: 00000000424d53fe R15: ffff88005f5a28c0
>> FS:  00007f7c8a2897c0(0000) GS:ffff88007eb80000(0000) knlGS:0000000000000000
>> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> CR2: ffff8800a1a77cc6 CR3: 000000005b281000 CR4: 00000000000006e0
>> Stack:
>>  ffff88005b31fa70 ffffffff88278789 00000000000001d3 ffff88005f5a2a80
>>  ffffffff00000003 ffff88005d029d00 ffff88006fde05a0 0000000000000000
>>  ffff88005b31fc78 ffff88006fde0780 ffff88005b31fb2f 0000000100000fe0
>> Call Trace:
>>  [] ? cifsConvertToUTF16+0x159/0x2d0
>>  [] smb2_open_file+0x98/0x210
>>  [] ? __kmalloc+0x1c/0xe0
>>  [] cifs_open+0x2a4/0x720
>>  [] do_dentry_open+0x1ff/0x310
>>  [] ? cifsFileInfo_get+0x30/0x30
>>  [] vfs_open+0x52/0x60
>>  [] path_openat+0x170/0xf70
>>  [] ? remove_wait_queue+0x48/0x50
>>  [] do_filp_open+0x79/0xd0
>>  [] ? __alloc_fd+0x3a/0x170
>>  [] do_sys_open+0x114/0x1e0
>>  [] SyS_open+0x19/0x20
>>  [] entry_SYSCALL_64_fastpath+0x12/0x6a
>> Code: 4d 8d 6c 07 04 31 c0 4c 89 ee e8 47 6f e5 ff 31 c9 41 89 ce 44 89 f1 48 c7 c7 28 b1 bd 88 31 c0 49 01 cd 4c 89 ee e8 2b 6f e5 ff <45> 0f b7 75 04 48 c7 c7 31 b1 bd 88 31 c0 4d 01 ee 4c 89 f6 e8
>> RIP  [] SMB2_open+0x804/0x960
>>  RSP
>> CR2: ffff8800a1a77cc6
>> ---[ end trace d9f69ba64feee469 ]---
>>
>> Signed-off-by: Justin Maggard <[hidden email]>
>> Signed-off-by: Steve French <[hidden email]>
>> Signed-off-by: Greg Kroah-Hartman <[hidden email]>
>>
>> ---
>>  fs/cifs/smb2pdu.c |   24 ++++++++++++++----------
>>  1 file changed, 14 insertions(+), 10 deletions(-)
>>
>> --- a/fs/cifs/smb2pdu.c
>> +++ b/fs/cifs/smb2pdu.c
>> @@ -1109,21 +1109,25 @@ parse_lease_state(struct TCP_Server_Info
>>  {
>>       char *data_offset;
>>       struct create_context *cc;
>> -     unsigned int next = 0;
>> +     unsigned int next;
>> +     unsigned int remaining;
>>       char *name;
>>
>>       data_offset = (char *)rsp + 4 + le32_to_cpu(rsp->CreateContextsOffset);
>> +     remaining = le32_to_cpu(rsp->CreateContextsLength);
>
> What if remaining is > the response length?

Do you want to do the followon patch to check for that, or do you want me
to write up a small patch for that?

>>       cc = (struct create_context *)data_offset;
>> -     do {
>> -             cc = (struct create_context *)((char *)cc + next);
>> +     while (remaining >= sizeof(struct create_context)) {
>>               name = le16_to_cpu(cc->NameOffset) + (char *)cc;
>> -             if (le16_to_cpu(cc->NameLength) != 4 ||
>> -                 strncmp(name, "RqLs", 4)) {
>> -                     next = le32_to_cpu(cc->Next);
>> -                     continue;
>> -             }
>> -             return server->ops->parse_lease_buf(cc, epoch);
>> -     } while (next != 0);
>> +             if (le16_to_cpu(cc->NameLength) == 4 &&
>> +                 strncmp(name, "RqLs", 4) == 0)
>> +                     return server->ops->parse_lease_buf(cc, epoch);
>> +
>> +             next = le32_to_cpu(cc->Next);
>> +             if (!next)
>> +                     break;
>> +             remaining -= next;
>
> What if next > remaining?
>
> This change seems to be only scratching the surface of the security
> failure here.
>
> Ben.
>
>> +             cc = (struct create_context *)((char *)cc + next);
>> +     }
>>
>>       return 0;
>>  }
>
> --
> Ben Hutchings
> When in doubt, use brute force. - Ken Thompson



--
Thanks,

Steve
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 4.4 00/74] 4.4.5-stable review

Kevin Hilman-8
In reply to this post by Greg KH-4
Greg Kroah-Hartman <[hidden email]> writes:

> On Tue, Mar 08, 2016 at 02:11:08AM -0800, kernelci.org bot wrote:
>> stable-queue boot: 205 boots: 14 failed, 190 passed with 1 offline (v4.4.4-74-gcc3ba9c14b31)
>>
>> Full Boot Summary: https://kernelci.org/boot/all/job/stable-queue/kernel/v4.4.4-74-gcc3ba9c14b31/
>> Full Build Summary: https://kernelci.org/build/stable-queue/kernel/v4.4.4-74-gcc3ba9c14b31/
>>
>> Tree: stable-queue
>> Branch: local/linux-4.4.y.queue
>> Git Describe: v4.4.4-74-gcc3ba9c14b31
>> Git Commit: cc3ba9c14b31161587ce85e9b5d642e730a2d0e8
>> Git URL: git://server.roeck-us.net/git/linux-stable.git
>> Tested: 47 unique boards, 13 SoC families, 18 builds out of 132
>>
>> Boot Failures Detected: https://kernelci.org/boot/?v4.4.4-74-gcc3ba9c14b31&fail
>>
>> arm:
>>
>>     mxs_defconfig:
>>         imx23-olinuxino: 1 failed lab
>>
>>     omap2plus_defconfig:
>>         omap4-panda: 1 failed lab
>>
>>     multi_v7_defconfig+CONFIG_LKDTM=y:
>>         imx53-qsrb: 1 failed lab
>>         imx6dl-riotboard: 1 failed lab
>>         socfpga_cyclone5_socrates: 1 failed lab
>>
>>     multi_v7_defconfig+CONFIG_SMP=n:
>>         imx53-qsrb: 1 failed lab
>>         imx6dl-riotboard: 1 failed lab
>>         socfpga_cyclone5_socrates: 1 failed lab
>>
>>     multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y:
>>         socfpga_cyclone5_socrates: 1 failed lab
>>
>>     imx_v6_v7_defconfig:
>>         imx53-qsrb: 1 failed lab
>>         imx6dl-riotboard: 1 failed lab
>>
>>     multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
>>         imx53-qsrb: 1 failed lab
>>         imx6dl-riotboard: 1 failed lab
>>         socfpga_cyclone5_socrates: 1 failed lab
>>
>> Offline Platforms:
>>
>> arm:
>>
>>     mxs_defconfig:
>>         imx28-duckbill: 1 offline lab
>
> I really don't know what these mean, any chance you can distill these
> down to "all is fine", or "there is a problem with this arch" type
> emails?

All is fine.

These failures are are on newly added boards coming from a new lab and
they're failing in other trees also, so we'll ignore them for now and
check with the specific lab owner.

Kevin
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 4.4 13/74] cifs: fix out-of-bounds access in lease parsing

Ben Hutchings
In reply to this post by Steve French-2
On Tue, 2016-03-08 at 22:23 -0600, Steve French wrote:

> On Tue, Mar 8, 2016 at 9:47 PM, Ben Hutchings <[hidden email]> wrote:
> >
> > On Mon, 2016-03-07 at 16:02 -0800, Greg Kroah-Hartman wrote:
> > >
> > > 4.4-stable review patch.  If anyone has any objections, please let me know.
> > >
> > > ------------------
> > >
> > > From: Justin Maggard <[hidden email]>
> > >
> > > commit deb7deff2f00bdbbcb3d560dad2a89ef37df837d upstream.
> > >
> > > When opening a file, SMB2_open() attempts to parse the lease state from the
> > > SMB2 CREATE Response.  However, the parsing code was not careful to ensure
> > > that the create contexts are not empty or invalid, which can lead to out-
> > > of-bounds memory access.  This can be seen easily by trying
> > > to read a file from a OSX 10.11 SMB3 server.  Here is sample crash output:
[...]

> > > --- a/fs/cifs/smb2pdu.c
> > > +++ b/fs/cifs/smb2pdu.c
> > > @@ -1109,21 +1109,25 @@ parse_lease_state(struct TCP_Server_Info
> > >  {
> > >       char *data_offset;
> > >       struct create_context *cc;
> > > -     unsigned int next = 0;
> > > +     unsigned int next;
> > > +     unsigned int remaining;
> > >       char *name;
> > >
> > >       data_offset = (char *)rsp + 4 + le32_to_cpu(rsp->CreateContextsOffset);
> > > +     remaining = le32_to_cpu(rsp->CreateContextsLength);
> > What if remaining is > the response length?
> Do you want to do the followon patch to check for that, or do you want me
> to write up a small patch for that?
[...]

I'm not likely to find time to dig into cifs, so please do work on the
complete fix.

Ben.

--
Ben Hutchings
When in doubt, use brute force. - Ken Thompson

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 4.4 34/74] arm64: vmemmap: use virtual projection of linear region

Ard Biesheuvel
In reply to this post by Ard Biesheuvel
On 8 March 2016 at 20:45, Ard Biesheuvel <[hidden email]> wrote:

> On 8 March 2016 at 20:44, Greg Kroah-Hartman <[hidden email]> wrote:
>> On Tue, Mar 08, 2016 at 05:40:14PM +0700, Ard Biesheuvel wrote:
>>> On 8 March 2016 at 07:02, Greg Kroah-Hartman <[hidden email]> wrote:
>>> > 4.4-stable review patch.  If anyone has any objections, please let me know.
>>> >
>>>
>>> Please hold off on this one. We are seeing some breakage on 64k pages systems
>>
>> If this problem is also in Linus's tree, I'd like to keep it in to keep
>> things "bug compatible".  Please let me know what fix that I should
>> apply to resolve this.
>>
>
> I am about to send out the patch that should fix this, so I will put you on cc.
>

Not sure what happened here, but this patch is in 4.4-stable now, but
the fix is not.
12345