--- /dev/null
+From 6833fb1ec120bf078e1a527c573a09d4de286224 Mon Sep 17 00:00:00 2001
+From: Lyude Paul <lyude@redhat.com>
+Date: Wed, 15 Aug 2018 15:00:14 -0400
+Subject: drm/nouveau/drm/nouveau: Use pm_runtime_get_noresume() in connector_detect()
+
+From: Lyude Paul <lyude@redhat.com>
+
+commit 6833fb1ec120bf078e1a527c573a09d4de286224 upstream.
+
+It's true we can't resume the device from poll workers in
+nouveau_connector_detect(). We can however, prevent the autosuspend
+timer from elapsing immediately if it hasn't already without risking any
+sort of deadlock with the runtime suspend/resume operations. So do that
+instead of entirely avoiding grabbing a power reference.
+
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Reviewed-by: Karol Herbst <kherbst@redhat.com>
+Acked-by: Daniel Vetter <daniel@ffwll.ch>
+Cc: stable@vger.kernel.org
+Cc: Lukas Wunner <lukas@wunner.de>
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/nouveau/nouveau_connector.c | 20 +++++++++++---------
+ 1 file changed, 11 insertions(+), 9 deletions(-)
+
+--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
++++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
+@@ -253,12 +253,16 @@ nouveau_connector_detect(struct drm_conn
+ nv_connector->edid = NULL;
+ }
+
+- /* Outputs are only polled while runtime active, so acquiring a
+- * runtime PM ref here is unnecessary (and would deadlock upon
+- * runtime suspend because it waits for polling to finish).
++ /* Outputs are only polled while runtime active, so resuming the
++ * device here is unnecessary (and would deadlock upon runtime suspend
++ * because it waits for polling to finish). We do however, want to
++ * prevent the autosuspend timer from elapsing during this operation
++ * if possible.
+ */
+- if (!drm_kms_helper_is_poll_worker()) {
+- ret = pm_runtime_get_sync(connector->dev->dev);
++ if (drm_kms_helper_is_poll_worker()) {
++ pm_runtime_get_noresume(dev->dev);
++ } else {
++ ret = pm_runtime_get_sync(dev->dev);
+ if (ret < 0 && ret != -EACCES)
+ return conn_status;
+ }
+@@ -329,10 +333,8 @@ detect_analog:
+
+ out:
+
+- if (!drm_kms_helper_is_poll_worker()) {
+- pm_runtime_mark_last_busy(connector->dev->dev);
+- pm_runtime_put_autosuspend(connector->dev->dev);
+- }
++ pm_runtime_mark_last_busy(dev->dev);
++ pm_runtime_put_autosuspend(dev->dev);
+
+ return conn_status;
+ }
--- /dev/null
+From 4d982e25d0bdc83d8c64e66fdeca0b89240b3b85 Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o <tytso@mit.edu>
+Date: Mon, 27 Aug 2018 09:22:45 -0400
+Subject: ext4: avoid divide by zero fault when deleting corrupted inline directories
+
+From: Theodore Ts'o <tytso@mit.edu>
+
+commit 4d982e25d0bdc83d8c64e66fdeca0b89240b3b85 upstream.
+
+A specially crafted file system can trick empty_inline_dir() into
+reading past the last valid entry in a inline directory, and then run
+into the end of xattr marker. This will trigger a divide by zero
+fault. Fix this by using the size of the inline directory instead of
+dir->i_size.
+
+Also clean up error reporting in __ext4_check_dir_entry so that the
+message is clearer and more understandable --- and avoids the division
+by zero trap if the size passed in is zero. (I'm not sure why we
+coded it that way in the first place; printing offset % size is
+actually more confusing and less useful.)
+
+https://bugzilla.kernel.org/show_bug.cgi?id=200933
+
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Reported-by: Wen Xu <wen.xu@gatech.edu>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/dir.c | 20 +++++++++-----------
+ fs/ext4/inline.c | 4 +++-
+ 2 files changed, 12 insertions(+), 12 deletions(-)
+
+--- a/fs/ext4/dir.c
++++ b/fs/ext4/dir.c
+@@ -74,7 +74,7 @@ int __ext4_check_dir_entry(const char *f
+ else if (unlikely(rlen < EXT4_DIR_REC_LEN(de->name_len)))
+ error_msg = "rec_len is too small for name_len";
+ else if (unlikely(((char *) de - buf) + rlen > size))
+- error_msg = "directory entry across range";
++ error_msg = "directory entry overrun";
+ else if (unlikely(le32_to_cpu(de->inode) >
+ le32_to_cpu(EXT4_SB(dir->i_sb)->s_es->s_inodes_count)))
+ error_msg = "inode out of bounds";
+@@ -83,18 +83,16 @@ int __ext4_check_dir_entry(const char *f
+
+ if (filp)
+ ext4_error_file(filp, function, line, bh->b_blocknr,
+- "bad entry in directory: %s - offset=%u(%u), "
+- "inode=%u, rec_len=%d, name_len=%d",
+- error_msg, (unsigned) (offset % size),
+- offset, le32_to_cpu(de->inode),
+- rlen, de->name_len);
++ "bad entry in directory: %s - offset=%u, "
++ "inode=%u, rec_len=%d, name_len=%d, size=%d",
++ error_msg, offset, le32_to_cpu(de->inode),
++ rlen, de->name_len, size);
+ else
+ ext4_error_inode(dir, function, line, bh->b_blocknr,
+- "bad entry in directory: %s - offset=%u(%u), "
+- "inode=%u, rec_len=%d, name_len=%d",
+- error_msg, (unsigned) (offset % size),
+- offset, le32_to_cpu(de->inode),
+- rlen, de->name_len);
++ "bad entry in directory: %s - offset=%u, "
++ "inode=%u, rec_len=%d, name_len=%d, size=%d",
++ error_msg, offset, le32_to_cpu(de->inode),
++ rlen, de->name_len, size);
+
+ return 1;
+ }
+--- a/fs/ext4/inline.c
++++ b/fs/ext4/inline.c
+@@ -1756,6 +1756,7 @@ int empty_inline_dir(struct inode *dir,
+ {
+ int err, inline_size;
+ struct ext4_iloc iloc;
++ size_t inline_len;
+ void *inline_pos;
+ unsigned int offset;
+ struct ext4_dir_entry_2 *de;
+@@ -1783,8 +1784,9 @@ int empty_inline_dir(struct inode *dir,
+ goto out;
+ }
+
++ inline_len = ext4_get_inline_size(dir);
+ offset = EXT4_INLINE_DOTDOT_SIZE;
+- while (offset < dir->i_size) {
++ while (offset < inline_len) {
+ de = ext4_get_inline_entry(dir, &iloc, offset,
+ &inline_pos, &inline_size);
+ if (ext4_check_dir_entry(dir, NULL, de,
--- /dev/null
+From fe18d649891d813964d3aaeebad873f281627fbc Mon Sep 17 00:00:00 2001
+From: Li Dongyang <dongyangli@ddn.com>
+Date: Sat, 15 Sep 2018 17:11:25 -0400
+Subject: ext4: don't mark mmp buffer head dirty
+
+From: Li Dongyang <dongyangli@ddn.com>
+
+commit fe18d649891d813964d3aaeebad873f281627fbc upstream.
+
+Marking mmp bh dirty before writing it will make writeback
+pick up mmp block later and submit a write, we don't want the
+duplicate write as kmmpd thread should have full control of
+reading and writing the mmp block.
+Another reason is we will also have random I/O error on
+the writeback request when blk integrity is enabled, because
+kmmpd could modify the content of the mmp block(e.g. setting
+new seq and time) while the mmp block is under I/O requested
+by writeback.
+
+Signed-off-by: Li Dongyang <dongyangli@ddn.com>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Reviewed-by: Andreas Dilger <adilger@dilger.ca>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/mmp.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/fs/ext4/mmp.c
++++ b/fs/ext4/mmp.c
+@@ -48,7 +48,6 @@ static int write_mmp_block(struct super_
+ */
+ sb_start_write(sb);
+ ext4_mmp_csum_set(sb, mmp);
+- mark_buffer_dirty(bh);
+ lock_buffer(bh);
+ bh->b_end_io = end_buffer_write_sync;
+ get_bh(bh);
--- /dev/null
+From f0a459dec5495a3580f8d784555e6f8f3bf7f263 Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o <tytso@mit.edu>
+Date: Mon, 3 Sep 2018 22:19:43 -0400
+Subject: ext4: fix online resize's handling of a too-small final block group
+
+From: Theodore Ts'o <tytso@mit.edu>
+
+commit f0a459dec5495a3580f8d784555e6f8f3bf7f263 upstream.
+
+Avoid growing the file system to an extent so that the last block
+group is too small to hold all of the metadata that must be stored in
+the block group.
+
+This problem can be triggered with the following reproducer:
+
+umount /mnt
+mke2fs -F -m0 -b 4096 -t ext4 -O resize_inode,^has_journal \
+ -E resize=1073741824 /tmp/foo.img 128M
+mount /tmp/foo.img /mnt
+truncate --size 1708M /tmp/foo.img
+resize2fs /dev/loop0 295400
+umount /mnt
+e2fsck -fy /tmp/foo.img
+
+Reported-by: Torsten Hilbrich <torsten.hilbrich@secunet.com>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/resize.c | 20 ++++++++++++++++++++
+ 1 file changed, 20 insertions(+)
+
+--- a/fs/ext4/resize.c
++++ b/fs/ext4/resize.c
+@@ -1954,6 +1954,26 @@ retry:
+ }
+ }
+
++ /*
++ * Make sure the last group has enough space so that it's
++ * guaranteed to have enough space for all metadata blocks
++ * that it might need to hold. (We might not need to store
++ * the inode table blocks in the last block group, but there
++ * will be cases where this might be needed.)
++ */
++ if ((ext4_group_first_block_no(sb, n_group) +
++ ext4_group_overhead_blocks(sb, n_group) + 2 +
++ sbi->s_itb_per_group + sbi->s_cluster_ratio) >= n_blocks_count) {
++ n_blocks_count = ext4_group_first_block_no(sb, n_group);
++ n_group--;
++ n_blocks_count_retry = 0;
++ if (resize_inode) {
++ iput(resize_inode);
++ resize_inode = NULL;
++ }
++ goto retry;
++ }
++
+ /* extend the last group */
+ if (n_group == o_group)
+ add = n_blocks_count - o_blocks_count;
--- /dev/null
+From 5f8c10936fab2b69a487400f2872902e597dd320 Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o <tytso@mit.edu>
+Date: Mon, 3 Sep 2018 22:25:01 -0400
+Subject: ext4: fix online resizing for bigalloc file systems with a 1k block size
+
+From: Theodore Ts'o <tytso@mit.edu>
+
+commit 5f8c10936fab2b69a487400f2872902e597dd320 upstream.
+
+An online resize of a file system with the bigalloc feature enabled
+and a 1k block size would be refused since ext4_resize_begin() did not
+understand s_first_data_block is 0 for all bigalloc file systems, even
+when the block size is 1k.
+
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/resize.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/fs/ext4/resize.c
++++ b/fs/ext4/resize.c
+@@ -18,6 +18,7 @@
+
+ int ext4_resize_begin(struct super_block *sb)
+ {
++ struct ext4_sb_info *sbi = EXT4_SB(sb);
+ int ret = 0;
+
+ if (!capable(CAP_SYS_RESOURCE))
+@@ -28,7 +29,7 @@ int ext4_resize_begin(struct super_block
+ * because the user tools have no way of handling this. Probably a
+ * bad time to do it anyways.
+ */
+- if (EXT4_SB(sb)->s_sbh->b_blocknr !=
++ if (EXT4_B2C(sbi, sbi->s_sbh->b_blocknr) !=
+ le32_to_cpu(EXT4_SB(sb)->s_es->s_first_data_block)) {
+ ext4_warning(sb, "won't resize using backup superblock at %llu",
+ (unsigned long long)EXT4_SB(sb)->s_sbh->b_blocknr);
--- /dev/null
+From 4274f516d4bc50648a4d97e4f67ecbd7b65cde4a Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o <tytso@mit.edu>
+Date: Sat, 1 Sep 2018 14:42:14 -0400
+Subject: ext4: recalucate superblock checksum after updating free blocks/inodes
+
+From: Theodore Ts'o <tytso@mit.edu>
+
+commit 4274f516d4bc50648a4d97e4f67ecbd7b65cde4a upstream.
+
+When mounting the superblock, ext4_fill_super() calculates the free
+blocks and free inodes and stores them in the superblock. It's not
+strictly necessary, since we don't use them any more, but it's nice to
+keep them roughly aligned to reality.
+
+Since it's not critical for file system correctness, the code doesn't
+call ext4_commit_super(). The problem is that it's in
+ext4_commit_super() that we recalculate the superblock checksum. So
+if we're not going to call ext4_commit_super(), we need to call
+ext4_superblock_csum_set() to make sure the superblock checksum is
+consistent.
+
+Most of the time, this doesn't matter, since we end up calling
+ext4_commit_super() very soon thereafter, and definitely by the time
+the file system is unmounted. However, it doesn't work in this
+sequence:
+
+mke2fs -Fq -t ext4 /dev/vdc 128M
+mount /dev/vdc /vdc
+cp xfstests/git-versions /vdc
+godown /vdc
+umount /vdc
+mount /dev/vdc
+tune2fs -l /dev/vdc
+
+With this commit, the "tune2fs -l" no longer fails.
+
+Reported-by: Chengguang Xu <cgxu519@gmx.com>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/super.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/ext4/super.c
++++ b/fs/ext4/super.c
+@@ -4024,11 +4024,13 @@ no_journal:
+ block = ext4_count_free_clusters(sb);
+ ext4_free_blocks_count_set(sbi->s_es,
+ EXT4_C2B(sbi, block));
++ ext4_superblock_csum_set(sb);
+ err = percpu_counter_init(&sbi->s_freeclusters_counter, block,
+ GFP_KERNEL);
+ if (!err) {
+ unsigned long freei = ext4_count_free_inodes(sb);
+ sbi->s_es->s_free_inodes_count = cpu_to_le32(freei);
++ ext4_superblock_csum_set(sb);
+ err = percpu_counter_init(&sbi->s_freeinodes_counter, freei,
+ GFP_KERNEL);
+ }
--- /dev/null
+From 234b69e3e089d850a98e7b3145bd00e9b52b1111 Mon Sep 17 00:00:00 2001
+From: Junxiao Bi <junxiao.bi@oracle.com>
+Date: Thu, 20 Sep 2018 12:22:51 -0700
+Subject: ocfs2: fix ocfs2 read block panic
+
+From: Junxiao Bi <junxiao.bi@oracle.com>
+
+commit 234b69e3e089d850a98e7b3145bd00e9b52b1111 upstream.
+
+While reading block, it is possible that io error return due to underlying
+storage issue, in this case, BH_NeedsValidate was left in the buffer head.
+Then when reading the very block next time, if it was already linked into
+journal, that will trigger the following panic.
+
+[203748.702517] kernel BUG at fs/ocfs2/buffer_head_io.c:342!
+[203748.702533] invalid opcode: 0000 [#1] SMP
+[203748.702561] Modules linked in: ocfs2 ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs sunrpc dm_switch dm_queue_length dm_multipath bonding be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i iw_cxgb4 cxgb4 cxgb3i libcxgbi iw_cxgb3 cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_devintf iTCO_wdt iTCO_vendor_support dcdbas ipmi_ssif i2c_core ipmi_si ipmi_msghandler acpi_pad pcspkr sb_edac edac_core lpc_ich mfd_core shpchp sg tg3 ptp pps_core ext4 jbd2 mbcache2 sr_mod cdrom sd_mod ahci libahci megaraid_sas wmi dm_mirror dm_region_hash dm_log dm_mod
+[203748.703024] CPU: 7 PID: 38369 Comm: touch Not tainted 4.1.12-124.18.6.el6uek.x86_64 #2
+[203748.703045] Hardware name: Dell Inc. PowerEdge R620/0PXXHP, BIOS 2.5.2 01/28/2015
+[203748.703067] task: ffff880768139c00 ti: ffff88006ff48000 task.ti: ffff88006ff48000
+[203748.703088] RIP: 0010:[<ffffffffa05e9f09>] [<ffffffffa05e9f09>] ocfs2_read_blocks+0x669/0x7f0 [ocfs2]
+[203748.703130] RSP: 0018:ffff88006ff4b818 EFLAGS: 00010206
+[203748.703389] RAX: 0000000008620029 RBX: ffff88006ff4b910 RCX: 0000000000000000
+[203748.703885] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 00000000023079fe
+[203748.704382] RBP: ffff88006ff4b8d8 R08: 0000000000000000 R09: ffff8807578c25b0
+[203748.704877] R10: 000000000f637376 R11: 000000003030322e R12: 0000000000000000
+[203748.705373] R13: ffff88006ff4b910 R14: ffff880732fe38f0 R15: 0000000000000000
+[203748.705871] FS: 00007f401992c700(0000) GS:ffff880bfebc0000(0000) knlGS:0000000000000000
+[203748.706370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[203748.706627] CR2: 00007f4019252440 CR3: 00000000a621e000 CR4: 0000000000060670
+[203748.707124] Stack:
+[203748.707371] ffff88006ff4b828 ffffffffa0609f52 ffff88006ff4b838 0000000000000001
+[203748.707885] 0000000000000000 0000000000000000 ffff880bf67c3800 ffffffffa05eca00
+[203748.708399] 00000000023079ff ffffffff81c58b80 0000000000000000 0000000000000000
+[203748.708915] Call Trace:
+[203748.709175] [<ffffffffa0609f52>] ? ocfs2_inode_cache_io_unlock+0x12/0x20 [ocfs2]
+[203748.709680] [<ffffffffa05eca00>] ? ocfs2_empty_dir_filldir+0x80/0x80 [ocfs2]
+[203748.710185] [<ffffffffa05ec0cb>] ocfs2_read_dir_block_direct+0x3b/0x200 [ocfs2]
+[203748.710691] [<ffffffffa05f0fbf>] ocfs2_prepare_dx_dir_for_insert.isra.57+0x19f/0xf60 [ocfs2]
+[203748.711204] [<ffffffffa065660f>] ? ocfs2_metadata_cache_io_unlock+0x1f/0x30 [ocfs2]
+[203748.711716] [<ffffffffa05f4f3a>] ocfs2_prepare_dir_for_insert+0x13a/0x890 [ocfs2]
+[203748.712227] [<ffffffffa05f442e>] ? ocfs2_check_dir_for_entry+0x8e/0x140 [ocfs2]
+[203748.712737] [<ffffffffa061b2f2>] ocfs2_mknod+0x4b2/0x1370 [ocfs2]
+[203748.713003] [<ffffffffa061c385>] ocfs2_create+0x65/0x170 [ocfs2]
+[203748.713263] [<ffffffff8121714b>] vfs_create+0xdb/0x150
+[203748.713518] [<ffffffff8121b225>] do_last+0x815/0x1210
+[203748.713772] [<ffffffff812192e9>] ? path_init+0xb9/0x450
+[203748.714123] [<ffffffff8121bca0>] path_openat+0x80/0x600
+[203748.714378] [<ffffffff811bcd45>] ? handle_pte_fault+0xd15/0x1620
+[203748.714634] [<ffffffff8121d7ba>] do_filp_open+0x3a/0xb0
+[203748.714888] [<ffffffff8122a767>] ? __alloc_fd+0xa7/0x130
+[203748.715143] [<ffffffff81209ffc>] do_sys_open+0x12c/0x220
+[203748.715403] [<ffffffff81026ddb>] ? syscall_trace_enter_phase1+0x11b/0x180
+[203748.715668] [<ffffffff816f0c9f>] ? system_call_after_swapgs+0xe9/0x190
+[203748.715928] [<ffffffff8120a10e>] SyS_open+0x1e/0x20
+[203748.716184] [<ffffffff816f0d5e>] system_call_fastpath+0x18/0xd7
+[203748.716440] Code: 00 00 48 8b 7b 08 48 83 c3 10 45 89 f8 44 89 e1 44 89 f2 4c 89 ee e8 07 06 11 e1 48 8b 03 48 85 c0 75 df 8b 5d c8 e9 4d fa ff ff <0f> 0b 48 8b 7d a0 e8 dc c6 06 00 48 b8 00 00 00 00 00 00 00 10
+[203748.717505] RIP [<ffffffffa05e9f09>] ocfs2_read_blocks+0x669/0x7f0 [ocfs2]
+[203748.717775] RSP <ffff88006ff4b818>
+
+Joesph ever reported a similar panic.
+Link: https://oss.oracle.com/pipermail/ocfs2-devel/2013-May/008931.html
+
+Link: http://lkml.kernel.org/r/20180912063207.29484-1-junxiao.bi@oracle.com
+Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
+Cc: Joseph Qi <jiangqi903@gmail.com>
+Cc: Mark Fasheh <mark@fasheh.com>
+Cc: Joel Becker <jlbec@evilplan.org>
+Cc: Changwei Ge <ge.changwei@h3c.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ocfs2/buffer_head_io.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/ocfs2/buffer_head_io.c
++++ b/fs/ocfs2/buffer_head_io.c
+@@ -336,6 +336,7 @@ int ocfs2_read_blocks(struct ocfs2_cachi
+ * for this bh as it's not marked locally
+ * uptodate. */
+ status = -EIO;
++ clear_buffer_needs_validate(bh);
+ put_bh(bh);
+ bhs[i] = NULL;
+ continue;
--- /dev/null
+From 1816494330a83f2a064499d8ed2797045641f92c Mon Sep 17 00:00:00 2001
+From: Vincent Pelletier <plr.vincent@gmail.com>
+Date: Sun, 9 Sep 2018 04:09:26 +0000
+Subject: scsi: target: iscsi: Use hex2bin instead of a re-implementation
+
+From: Vincent Pelletier <plr.vincent@gmail.com>
+
+commit 1816494330a83f2a064499d8ed2797045641f92c upstream.
+
+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: Vincent Pelletier <plr.vincent@gmail.com>
+Reviewed-by: Mike Christie <mchristi@redhat.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/target/iscsi/iscsi_target_auth.c | 30 ++++++++++++++----------------
+ 1 file changed, 14 insertions(+), 16 deletions(-)
+
+--- a/drivers/target/iscsi/iscsi_target_auth.c
++++ b/drivers/target/iscsi/iscsi_target_auth.c
+@@ -26,18 +26,6 @@
+ #include "iscsi_target_nego.h"
+ #include "iscsi_target_auth.h"
+
+-static int chap_string_to_hex(unsigned char *dst, unsigned char *src, int len)
+-{
+- int j = DIV_ROUND_UP(len, 2), rc;
+-
+- rc = hex2bin(dst, src, j);
+- if (rc < 0)
+- pr_debug("CHAP string contains non hex digit symbols\n");
+-
+- dst[j] = '\0';
+- return j;
+-}
+-
+ static void chap_binaryhex_to_asciihex(char *dst, char *src, int src_len)
+ {
+ int i;
+@@ -241,9 +229,16 @@ static int chap_server_compute_md5(
+ pr_err("Could not find CHAP_R.\n");
+ goto out;
+ }
++ if (strlen(chap_r) != MD5_SIGNATURE_SIZE * 2) {
++ pr_err("Malformed CHAP_R\n");
++ goto out;
++ }
++ if (hex2bin(client_digest, chap_r, MD5_SIGNATURE_SIZE) < 0) {
++ pr_err("Malformed CHAP_R\n");
++ goto out;
++ }
+
+ pr_debug("[server] Got CHAP_R=%s\n", chap_r);
+- chap_string_to_hex(client_digest, chap_r, strlen(chap_r));
+
+ tfm = crypto_alloc_hash("md5", 0, CRYPTO_ALG_ASYNC);
+ if (IS_ERR(tfm)) {
+@@ -348,9 +343,7 @@ static int chap_server_compute_md5(
+ pr_err("Could not find CHAP_C.\n");
+ goto out;
+ }
+- pr_debug("[server] Got CHAP_C=%s\n", challenge);
+- challenge_len = chap_string_to_hex(challenge_binhex, challenge,
+- strlen(challenge));
++ challenge_len = DIV_ROUND_UP(strlen(challenge), 2);
+ if (!challenge_len) {
+ pr_err("Unable to convert incoming challenge\n");
+ goto out;
+@@ -359,6 +352,11 @@ static int chap_server_compute_md5(
+ pr_err("CHAP_C exceeds maximum binary size of 1024 bytes\n");
+ goto out;
+ }
++ if (hex2bin(challenge_binhex, challenge, challenge_len) < 0) {
++ pr_err("Malformed CHAP_C\n");
++ goto out;
++ }
++ pr_debug("[server] Got CHAP_C=%s\n", challenge);
+ /*
+ * During mutual authentication, the CHAP_C generated by the
+ * initiator must not match the original CHAP_C generated by
net-appletalk-fix-minor-pointer-leak-to-userspace-in-siocfindipddprt.patch
net-hp100-fix-always-true-check-for-link-up-state.patch
neighbour-confirm-neigh-entries-when-arp-packet-is-received.patch
+scsi-target-iscsi-use-hex2bin-instead-of-a-re-implementation.patch
+ocfs2-fix-ocfs2-read-block-panic.patch
+drm-nouveau-drm-nouveau-use-pm_runtime_get_noresume-in-connector_detect.patch
+tty-vt_ioctl-fix-potential-spectre-v1.patch
+ext4-avoid-divide-by-zero-fault-when-deleting-corrupted-inline-directories.patch
+ext4-recalucate-superblock-checksum-after-updating-free-blocks-inodes.patch
+ext4-fix-online-resize-s-handling-of-a-too-small-final-block-group.patch
+ext4-fix-online-resizing-for-bigalloc-file-systems-with-a-1k-block-size.patch
+ext4-don-t-mark-mmp-buffer-head-dirty.patch
--- /dev/null
+From e97267cb4d1ee01ca0929638ec0fcbb0904f903d Mon Sep 17 00:00:00 2001
+From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
+Date: Thu, 16 Aug 2018 15:30:38 -0500
+Subject: tty: vt_ioctl: fix potential Spectre v1
+
+From: Gustavo A. R. Silva <gustavo@embeddedor.com>
+
+commit e97267cb4d1ee01ca0929638ec0fcbb0904f903d upstream.
+
+vsa.console is indirectly controlled by user-space, hence leading to
+a potential exploitation of the Spectre variant 1 vulnerability.
+
+This issue was detected with the help of Smatch:
+
+drivers/tty/vt/vt_ioctl.c:711 vt_ioctl() warn: potential spectre issue
+'vc_cons' [r]
+
+Fix this by sanitizing vsa.console before using it to index vc_cons
+
+Notice that given that speculation windows are large, the policy is
+to kill the speculation on the first load and not worry if it can be
+completed with a dependent load/store [1].
+
+[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
+Reviewed-by: Alan Cox <alan@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/vt/vt_ioctl.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/tty/vt/vt_ioctl.c
++++ b/drivers/tty/vt/vt_ioctl.c
+@@ -31,6 +31,8 @@
+ #include <asm/io.h>
+ #include <asm/uaccess.h>
+
++#include <linux/nospec.h>
++
+ #include <linux/kbd_kern.h>
+ #include <linux/vt_kern.h>
+ #include <linux/kbd_diacr.h>
+@@ -703,6 +705,8 @@ int vt_ioctl(struct tty_struct *tty,
+ if (vsa.console == 0 || vsa.console > MAX_NR_CONSOLES)
+ ret = -ENXIO;
+ else {
++ vsa.console = array_index_nospec(vsa.console,
++ MAX_NR_CONSOLES + 1);
+ vsa.console--;
+ console_lock();
+ ret = vc_allocate(vsa.console);
projects / thirdparty / kernel / stable-queue.git / commitdiff
