From: Greg Kroah-Hartman Date: Mon, 16 Sep 2019 15:32:56 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v4.14.145~40 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=620dde259abd7de43149e79e6a19008e7f8f74f8;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: btrfs-fix-assertion-failure-during-fsync-and-use-of-stale-transaction.patch genirq-prevent-null-pointer-dereference-in-resend_irqs.patch gpio-fix-line-flag-validation-in-lineevent_create.patch gpio-fix-line-flag-validation-in-linehandle_create.patch kvm-nvmx-handle-page-fault-in-vmread.patch kvm-s390-do-not-leak-kernel-stack-data-in-the-kvm_s390_interrupt-ioctl.patch kvm-x86-work-around-leak-of-uninitialized-stack-contents.patch revert-mips-sibyte-enable-swiotlb-for-swarm-littlesur-and.patch --- diff --git a/queue-4.9/btrfs-fix-assertion-failure-during-fsync-and-use-of-stale-transaction.patch b/queue-4.9/btrfs-fix-assertion-failure-during-fsync-and-use-of-stale-transaction.patch new file mode 100644 index 00000000000..c34305283c7 --- /dev/null +++ b/queue-4.9/btrfs-fix-assertion-failure-during-fsync-and-use-of-stale-transaction.patch @@ -0,0 +1,152 @@ +From 410f954cb1d1c79ae485dd83a175f21954fd87cd Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Tue, 10 Sep 2019 15:26:49 +0100 +Subject: Btrfs: fix assertion failure during fsync and use of stale transaction + +From: Filipe Manana + +commit 410f954cb1d1c79ae485dd83a175f21954fd87cd upstream. + +Sometimes when fsync'ing a file we need to log that other inodes exist and +when we need to do that we acquire a reference on the inodes and then drop +that reference using iput() after logging them. + +That generally is not a problem except if we end up doing the final iput() +(dropping the last reference) on the inode and that inode has a link count +of 0, which can happen in a very short time window if the logging path +gets a reference on the inode while it's being unlinked. + +In that case we end up getting the eviction callback, btrfs_evict_inode(), +invoked through the iput() call chain which needs to drop all of the +inode's items from its subvolume btree, and in order to do that, it needs +to join a transaction at the helper function evict_refill_and_join(). +However because the task previously started a transaction at the fsync +handler, btrfs_sync_file(), it has current->journal_info already pointing +to a transaction handle and therefore evict_refill_and_join() will get +that transaction handle from btrfs_join_transaction(). From this point on, +two different problems can happen: + +1) evict_refill_and_join() will often change the transaction handle's + block reserve (->block_rsv) and set its ->bytes_reserved field to a + value greater than 0. If evict_refill_and_join() never commits the + transaction, the eviction handler ends up decreasing the reference + count (->use_count) of the transaction handle through the call to + btrfs_end_transaction(), and after that point we have a transaction + handle with a NULL ->block_rsv (which is the value prior to the + transaction join from evict_refill_and_join()) and a ->bytes_reserved + value greater than 0. If after the eviction/iput completes the inode + logging path hits an error or it decides that it must fallback to a + transaction commit, the btrfs fsync handle, btrfs_sync_file(), gets a + non-zero value from btrfs_log_dentry_safe(), and because of that + non-zero value it tries to commit the transaction using a handle with + a NULL ->block_rsv and a non-zero ->bytes_reserved value. This makes + the transaction commit hit an assertion failure at + btrfs_trans_release_metadata() because ->bytes_reserved is not zero but + the ->block_rsv is NULL. The produced stack trace for that is like the + following: + + [192922.917158] assertion failed: !trans->bytes_reserved, file: fs/btrfs/transaction.c, line: 816 + [192922.917553] ------------[ cut here ]------------ + [192922.917922] kernel BUG at fs/btrfs/ctree.h:3532! + [192922.918310] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC PTI + [192922.918666] CPU: 2 PID: 883 Comm: fsstress Tainted: G W 5.1.4-btrfs-next-47 #1 + [192922.919035] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.2-0-gf9626ccb91-prebuilt.qemu-project.org 04/01/2014 + [192922.919801] RIP: 0010:assfail.constprop.25+0x18/0x1a [btrfs] + (...) + [192922.920925] RSP: 0018:ffffaebdc8a27da8 EFLAGS: 00010286 + [192922.921315] RAX: 0000000000000051 RBX: ffff95c9c16a41c0 RCX: 0000000000000000 + [192922.921692] RDX: 0000000000000000 RSI: ffff95cab6b16838 RDI: ffff95cab6b16838 + [192922.922066] RBP: ffff95c9c16a41c0 R08: 0000000000000000 R09: 0000000000000000 + [192922.922442] R10: ffffaebdc8a27e70 R11: 0000000000000000 R12: ffff95ca731a0980 + [192922.922820] R13: 0000000000000000 R14: ffff95ca84c73338 R15: ffff95ca731a0ea8 + [192922.923200] FS: 00007f337eda4e80(0000) GS:ffff95cab6b00000(0000) knlGS:0000000000000000 + [192922.923579] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + [192922.923948] CR2: 00007f337edad000 CR3: 00000001e00f6002 CR4: 00000000003606e0 + [192922.924329] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 + [192922.924711] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 + [192922.925105] Call Trace: + [192922.925505] btrfs_trans_release_metadata+0x10c/0x170 [btrfs] + [192922.925911] btrfs_commit_transaction+0x3e/0xaf0 [btrfs] + [192922.926324] btrfs_sync_file+0x44c/0x490 [btrfs] + [192922.926731] do_fsync+0x38/0x60 + [192922.927138] __x64_sys_fdatasync+0x13/0x20 + [192922.927543] do_syscall_64+0x60/0x1c0 + [192922.927939] entry_SYSCALL_64_after_hwframe+0x49/0xbe + (...) + [192922.934077] ---[ end trace f00808b12068168f ]--- + +2) If evict_refill_and_join() decides to commit the transaction, it will + be able to do it, since the nested transaction join only increments the + transaction handle's ->use_count reference counter and it does not + prevent the transaction from getting committed. This means that after + eviction completes, the fsync logging path will be using a transaction + handle that refers to an already committed transaction. What happens + when using such a stale transaction can be unpredictable, we are at + least having a use-after-free on the transaction handle itself, since + the transaction commit will call kmem_cache_free() against the handle + regardless of its ->use_count value, or we can end up silently losing + all the updates to the log tree after that iput() in the logging path, + or using a transaction handle that in the meanwhile was allocated to + another task for a new transaction, etc, pretty much unpredictable + what can happen. + +In order to fix both of them, instead of using iput() during logging, use +btrfs_add_delayed_iput(), so that the logging path of fsync never drops +the last reference on an inode, that step is offloaded to a safe context +(usually the cleaner kthread). + +The assertion failure issue was sporadically triggered by the test case +generic/475 from fstests, which loads the dm error target while fsstress +is running, which lead to fsync failing while logging inodes with -EIO +errors and then trying later to commit the transaction, triggering the +assertion failure. + +CC: stable@vger.kernel.org # 4.4+ +Reviewed-by: Josef Bacik +Signed-off-by: Filipe Manana +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + + +--- + fs/btrfs/tree-log.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/fs/btrfs/tree-log.c ++++ b/fs/btrfs/tree-log.c +@@ -4846,7 +4846,7 @@ again: + err = btrfs_log_inode(trans, root, other_inode, + LOG_OTHER_INODE, + 0, LLONG_MAX, ctx); +- iput(other_inode); ++ btrfs_add_delayed_iput(other_inode); + if (err) + goto out_unlock; + else +@@ -5264,7 +5264,7 @@ process_leaf: + } + + if (btrfs_inode_in_log(di_inode, trans->transid)) { +- iput(di_inode); ++ btrfs_add_delayed_iput(di_inode); + break; + } + +@@ -5276,7 +5276,7 @@ process_leaf: + if (!ret && + btrfs_must_commit_transaction(trans, di_inode)) + ret = 1; +- iput(di_inode); ++ btrfs_add_delayed_iput(di_inode); + if (ret) + goto next_dir_inode; + if (ctx->log_new_dentries) { +@@ -5422,7 +5422,7 @@ static int btrfs_log_all_parents(struct + if (!ret && ctx && ctx->log_new_dentries) + ret = log_new_dir_dentries(trans, root, + dir_inode, ctx); +- iput(dir_inode); ++ btrfs_add_delayed_iput(dir_inode); + if (ret) + goto out; + } diff --git a/queue-4.9/genirq-prevent-null-pointer-dereference-in-resend_irqs.patch b/queue-4.9/genirq-prevent-null-pointer-dereference-in-resend_irqs.patch new file mode 100644 index 00000000000..4f6ec5cb45e --- /dev/null +++ b/queue-4.9/genirq-prevent-null-pointer-dereference-in-resend_irqs.patch @@ -0,0 +1,76 @@ +From eddf3e9c7c7e4d0707c68d1bb22cc6ec8aef7d4a Mon Sep 17 00:00:00 2001 +From: Yunfeng Ye +Date: Wed, 4 Sep 2019 20:46:25 +0800 +Subject: genirq: Prevent NULL pointer dereference in resend_irqs() + +From: Yunfeng Ye + +commit eddf3e9c7c7e4d0707c68d1bb22cc6ec8aef7d4a upstream. + +The following crash was observed: + + Unable to handle kernel NULL pointer dereference at 0000000000000158 + Internal error: Oops: 96000004 [#1] SMP + pc : resend_irqs+0x68/0xb0 + lr : resend_irqs+0x64/0xb0 + ... + Call trace: + resend_irqs+0x68/0xb0 + tasklet_action_common.isra.6+0x84/0x138 + tasklet_action+0x2c/0x38 + __do_softirq+0x120/0x324 + run_ksoftirqd+0x44/0x60 + smpboot_thread_fn+0x1ac/0x1e8 + kthread+0x134/0x138 + ret_from_fork+0x10/0x18 + +The reason for this is that the interrupt resend mechanism happens in soft +interrupt context, which is a asynchronous mechanism versus other +operations on interrupts. free_irq() does not take resend handling into +account. Thus, the irq descriptor might be already freed before the resend +tasklet is executed. resend_irqs() does not check the return value of the +interrupt descriptor lookup and derefences the return value +unconditionally. + + 1): + __setup_irq + irq_startup + check_irq_resend // activate softirq to handle resend irq + 2): + irq_domain_free_irqs + irq_free_descs + free_desc + call_rcu(&desc->rcu, delayed_free_desc) + 3): + __do_softirq + tasklet_action + resend_irqs + desc = irq_to_desc(irq) + desc->handle_irq(desc) // desc is NULL --> Ooops + +Fix this by adding a NULL pointer check in resend_irqs() before derefencing +the irq descriptor. + +Fixes: a4633adcdbc1 ("[PATCH] genirq: add genirq sw IRQ-retrigger") +Signed-off-by: Yunfeng Ye +Signed-off-by: Thomas Gleixner +Reviewed-by: Zhiqiang Liu +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/1630ae13-5c8e-901e-de09-e740b6a426a7@huawei.com +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/irq/resend.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/kernel/irq/resend.c ++++ b/kernel/irq/resend.c +@@ -37,6 +37,8 @@ static void resend_irqs(unsigned long ar + irq = find_first_bit(irqs_resend, nr_irqs); + clear_bit(irq, irqs_resend); + desc = irq_to_desc(irq); ++ if (!desc) ++ continue; + local_irq_disable(); + desc->handle_irq(desc); + local_irq_enable(); diff --git a/queue-4.9/gpio-fix-line-flag-validation-in-lineevent_create.patch b/queue-4.9/gpio-fix-line-flag-validation-in-lineevent_create.patch new file mode 100644 index 00000000000..6976dcf04ad --- /dev/null +++ b/queue-4.9/gpio-fix-line-flag-validation-in-lineevent_create.patch @@ -0,0 +1,46 @@ +From 5ca2f54b597c816df54ff1b28eb99cf7262b955d Mon Sep 17 00:00:00 2001 +From: Kent Gibson +Date: Mon, 9 Sep 2019 03:24:06 +0000 +Subject: gpio: fix line flag validation in lineevent_create + +From: Kent Gibson + +commit 5ca2f54b597c816df54ff1b28eb99cf7262b955d upstream. + +lineevent_create should not allow any of GPIOHANDLE_REQUEST_OUTPUT, +GPIOHANDLE_REQUEST_OPEN_DRAIN or GPIOHANDLE_REQUEST_OPEN_SOURCE to be set. + +Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") +Cc: stable +Signed-off-by: Kent Gibson +Signed-off-by: Bartosz Golaszewski +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpio/gpiolib.c | 8 +++----- + 1 file changed, 3 insertions(+), 5 deletions(-) + +--- a/drivers/gpio/gpiolib.c ++++ b/drivers/gpio/gpiolib.c +@@ -797,7 +797,9 @@ static int lineevent_create(struct gpio_ + } + + /* This is just wrong: we don't look for events on output lines */ +- if (lflags & GPIOHANDLE_REQUEST_OUTPUT) { ++ if ((lflags & GPIOHANDLE_REQUEST_OUTPUT) || ++ (lflags & GPIOHANDLE_REQUEST_OPEN_DRAIN) || ++ (lflags & GPIOHANDLE_REQUEST_OPEN_SOURCE)) { + ret = -EINVAL; + goto out_free_label; + } +@@ -811,10 +813,6 @@ static int lineevent_create(struct gpio_ + + if (lflags & GPIOHANDLE_REQUEST_ACTIVE_LOW) + set_bit(FLAG_ACTIVE_LOW, &desc->flags); +- if (lflags & GPIOHANDLE_REQUEST_OPEN_DRAIN) +- set_bit(FLAG_OPEN_DRAIN, &desc->flags); +- if (lflags & GPIOHANDLE_REQUEST_OPEN_SOURCE) +- set_bit(FLAG_OPEN_SOURCE, &desc->flags); + + ret = gpiod_direction_input(desc); + if (ret) diff --git a/queue-4.9/gpio-fix-line-flag-validation-in-linehandle_create.patch b/queue-4.9/gpio-fix-line-flag-validation-in-linehandle_create.patch new file mode 100644 index 00000000000..d96d3c9284c --- /dev/null +++ b/queue-4.9/gpio-fix-line-flag-validation-in-linehandle_create.patch @@ -0,0 +1,56 @@ +From e95fbc130a162ba9ad956311b95aa0da269eea48 Mon Sep 17 00:00:00 2001 +From: Kent Gibson +Date: Mon, 9 Sep 2019 03:22:18 +0000 +Subject: gpio: fix line flag validation in linehandle_create + +From: Kent Gibson + +commit e95fbc130a162ba9ad956311b95aa0da269eea48 upstream. + +linehandle_create should not allow both GPIOHANDLE_REQUEST_INPUT +and GPIOHANDLE_REQUEST_OUTPUT to be set. + +Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") +Cc: stable +Signed-off-by: Kent Gibson +Signed-off-by: Bartosz Golaszewski +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpio/gpiolib.c | 12 +++++++++++- + 1 file changed, 11 insertions(+), 1 deletion(-) + +--- a/drivers/gpio/gpiolib.c ++++ b/drivers/gpio/gpiolib.c +@@ -426,12 +426,23 @@ static int linehandle_create(struct gpio + struct linehandle_state *lh; + struct file *file; + int fd, i, count = 0, ret; ++ u32 lflags; + + if (copy_from_user(&handlereq, ip, sizeof(handlereq))) + return -EFAULT; + if ((handlereq.lines == 0) || (handlereq.lines > GPIOHANDLES_MAX)) + return -EINVAL; + ++ lflags = handlereq.flags; ++ ++ /* ++ * Do not allow both INPUT & OUTPUT flags to be set as they are ++ * contradictory. ++ */ ++ if ((lflags & GPIOHANDLE_REQUEST_INPUT) && ++ (lflags & GPIOHANDLE_REQUEST_OUTPUT)) ++ return -EINVAL; ++ + lh = kzalloc(sizeof(*lh), GFP_KERNEL); + if (!lh) + return -ENOMEM; +@@ -452,7 +463,6 @@ static int linehandle_create(struct gpio + /* Request each GPIO */ + for (i = 0; i < handlereq.lines; i++) { + u32 offset = handlereq.lineoffsets[i]; +- u32 lflags = handlereq.flags; + struct gpio_desc *desc; + + if (offset >= gdev->ngpio) { diff --git a/queue-4.9/kvm-nvmx-handle-page-fault-in-vmread.patch b/queue-4.9/kvm-nvmx-handle-page-fault-in-vmread.patch new file mode 100644 index 00000000000..5db128e350f --- /dev/null +++ b/queue-4.9/kvm-nvmx-handle-page-fault-in-vmread.patch @@ -0,0 +1,43 @@ +From f7eea636c3d505fe6f1d1066234f1aaf7171b681 Mon Sep 17 00:00:00 2001 +From: Paolo Bonzini +Date: Sat, 14 Sep 2019 00:26:27 +0200 +Subject: KVM: nVMX: handle page fault in vmread + +From: Paolo Bonzini + +commit f7eea636c3d505fe6f1d1066234f1aaf7171b681 upstream. + +The implementation of vmread to memory is still incomplete, as it +lacks the ability to do vmread to I/O memory just like vmptrst. + +Cc: stable@vger.kernel.org +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/vmx.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +--- a/arch/x86/kvm/vmx.c ++++ b/arch/x86/kvm/vmx.c +@@ -7639,6 +7639,7 @@ static int handle_vmread(struct kvm_vcpu + unsigned long exit_qualification = vmcs_readl(EXIT_QUALIFICATION); + u32 vmx_instruction_info = vmcs_read32(VMX_INSTRUCTION_INFO); + gva_t gva = 0; ++ struct x86_exception e; + + if (!nested_vmx_check_permission(vcpu) || + !nested_vmx_check_vmcs12(vcpu)) +@@ -7665,8 +7666,10 @@ static int handle_vmread(struct kvm_vcpu + vmx_instruction_info, true, &gva)) + return 1; + /* _system ok, as nested_vmx_check_permission verified cpl=0 */ +- kvm_write_guest_virt_system(vcpu, gva, &field_value, +- (is_long_mode(vcpu) ? 8 : 4), NULL); ++ if (kvm_write_guest_virt_system(vcpu, gva, &field_value, ++ (is_long_mode(vcpu) ? 8 : 4), ++ NULL)) ++ kvm_inject_page_fault(vcpu, &e); + } + + nested_vmx_succeed(vcpu); diff --git a/queue-4.9/kvm-s390-do-not-leak-kernel-stack-data-in-the-kvm_s390_interrupt-ioctl.patch b/queue-4.9/kvm-s390-do-not-leak-kernel-stack-data-in-the-kvm_s390_interrupt-ioctl.patch new file mode 100644 index 00000000000..cb6ebaef65a --- /dev/null +++ b/queue-4.9/kvm-s390-do-not-leak-kernel-stack-data-in-the-kvm_s390_interrupt-ioctl.patch @@ -0,0 +1,77 @@ +From 53936b5bf35e140ae27e4bbf0447a61063f400da Mon Sep 17 00:00:00 2001 +From: Thomas Huth +Date: Thu, 12 Sep 2019 13:54:38 +0200 +Subject: KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl + +From: Thomas Huth + +commit 53936b5bf35e140ae27e4bbf0447a61063f400da upstream. + +When the userspace program runs the KVM_S390_INTERRUPT ioctl to inject +an interrupt, we convert them from the legacy struct kvm_s390_interrupt +to the new struct kvm_s390_irq via the s390int_to_s390irq() function. +However, this function does not take care of all types of interrupts +that we can inject into the guest later (see do_inject_vcpu()). Since we +do not clear out the s390irq values before calling s390int_to_s390irq(), +there is a chance that we copy random data from the kernel stack which +could be leaked to the userspace later. + +Specifically, the problem exists with the KVM_S390_INT_PFAULT_INIT +interrupt: s390int_to_s390irq() does not handle it, and the function +__inject_pfault_init() later copies irq->u.ext which contains the +random kernel stack data. This data can then be leaked either to +the guest memory in __deliver_pfault_init(), or the userspace might +retrieve it directly with the KVM_S390_GET_IRQ_STATE ioctl. + +Fix it by handling that interrupt type in s390int_to_s390irq(), too, +and by making sure that the s390irq struct is properly pre-initialized. +And while we're at it, make sure that s390int_to_s390irq() now +directly returns -EINVAL for unknown interrupt types, so that we +immediately get a proper error code in case we add more interrupt +types to do_inject_vcpu() without updating s390int_to_s390irq() +sometime in the future. + +Cc: stable@vger.kernel.org +Reviewed-by: David Hildenbrand +Reviewed-by: Christian Borntraeger +Reviewed-by: Janosch Frank +Signed-off-by: Thomas Huth +Link: https://lore.kernel.org/kvm/20190912115438.25761-1-thuth@redhat.com +Signed-off-by: Christian Borntraeger +Signed-off-by: Greg Kroah-Hartman + +--- + arch/s390/kvm/interrupt.c | 10 ++++++++++ + arch/s390/kvm/kvm-s390.c | 2 +- + 2 files changed, 11 insertions(+), 1 deletion(-) + +--- a/arch/s390/kvm/interrupt.c ++++ b/arch/s390/kvm/interrupt.c +@@ -1652,6 +1652,16 @@ int s390int_to_s390irq(struct kvm_s390_i + case KVM_S390_MCHK: + irq->u.mchk.mcic = s390int->parm64; + break; ++ case KVM_S390_INT_PFAULT_INIT: ++ irq->u.ext.ext_params = s390int->parm; ++ irq->u.ext.ext_params2 = s390int->parm64; ++ break; ++ case KVM_S390_RESTART: ++ case KVM_S390_INT_CLOCK_COMP: ++ case KVM_S390_INT_CPU_TIMER: ++ break; ++ default: ++ return -EINVAL; + } + return 0; + } +--- a/arch/s390/kvm/kvm-s390.c ++++ b/arch/s390/kvm/kvm-s390.c +@@ -3105,7 +3105,7 @@ long kvm_arch_vcpu_ioctl(struct file *fi + } + case KVM_S390_INTERRUPT: { + struct kvm_s390_interrupt s390int; +- struct kvm_s390_irq s390irq; ++ struct kvm_s390_irq s390irq = {}; + + r = -EFAULT; + if (copy_from_user(&s390int, argp, sizeof(s390int))) diff --git a/queue-4.9/kvm-x86-work-around-leak-of-uninitialized-stack-contents.patch b/queue-4.9/kvm-x86-work-around-leak-of-uninitialized-stack-contents.patch new file mode 100644 index 00000000000..81ef07d75d8 --- /dev/null +++ b/queue-4.9/kvm-x86-work-around-leak-of-uninitialized-stack-contents.patch @@ -0,0 +1,44 @@ +From 541ab2aeb28251bf7135c7961f3a6080eebcc705 Mon Sep 17 00:00:00 2001 +From: Fuqian Huang +Date: Thu, 12 Sep 2019 12:18:17 +0800 +Subject: KVM: x86: work around leak of uninitialized stack contents + +From: Fuqian Huang + +commit 541ab2aeb28251bf7135c7961f3a6080eebcc705 upstream. + +Emulation of VMPTRST can incorrectly inject a page fault +when passed an operand that points to an MMIO address. +The page fault will use uninitialized kernel stack memory +as the CR2 and error code. + +The right behavior would be to abort the VM with a KVM_EXIT_INTERNAL_ERROR +exit to userspace; however, it is not an easy fix, so for now just ensure +that the error code and CR2 are zero. + +Signed-off-by: Fuqian Huang +Cc: stable@vger.kernel.org +[add comment] +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/x86.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -4620,6 +4620,13 @@ int kvm_write_guest_virt_system(struct k + /* kvm_write_guest_virt_system can pull in tons of pages. */ + vcpu->arch.l1tf_flush_l1d = true; + ++ /* ++ * FIXME: this should call handle_emulation_failure if X86EMUL_IO_NEEDED ++ * is returned, but our callers are not ready for that and they blindly ++ * call kvm_inject_page_fault. Ensure that they at least do not leak ++ * uninitialized kernel stack memory into cr2 and error code. ++ */ ++ memset(exception, 0, sizeof(*exception)); + return kvm_write_guest_virt_helper(addr, val, bytes, vcpu, + PFERR_WRITE_MASK, exception); + } diff --git a/queue-4.9/revert-mips-sibyte-enable-swiotlb-for-swarm-littlesur-and.patch b/queue-4.9/revert-mips-sibyte-enable-swiotlb-for-swarm-littlesur-and.patch new file mode 100644 index 00000000000..ea34b3b44a0 --- /dev/null +++ b/queue-4.9/revert-mips-sibyte-enable-swiotlb-for-swarm-littlesur-and.patch @@ -0,0 +1,92 @@ +From 1c7c801c76438c9ff184aa6fb071d64502d35be8 Mon Sep 17 00:00:00 2001 +From: Greg Kroah-Hartman +Date: Mon, 16 Sep 2019 16:59:01 +0200 +Subject: Revert "MIPS: SiByte: Enable swiotlb for SWARM, LittleSur and BigSur" + +From: Greg Kroah-Hartman + +This reverts commit 8ac4ad063e1a32e321a7a0e6ea9fd305a6ecd033 which is +commit e4849aff1e169b86c561738daf8ff020e9de1011 upstream + +Guenter writes: + Upstream commit e4849aff1e16 ("MIPS: SiByte: Enable swiotlb for SWARM, + LittleSur and BigSur") results in build failures in v4.4.y and v4.14.y. + + make bigsur_defconfig: + + warning: (SIBYTE_SWARM && SIBYTE_SENTOSA && SIBYTE_BIGSUR && SWIOTLB_XEN && AMD_IOMMU) selects SWIOTLB which has unmet direct dependencies (CAVIUM_OCTEON_SOC || MACH_LOONGSON64 && CPU_LOONGSON3 || NLM_XLP_BOARD || NLM_XLR_BOARD) + warning: (SIBYTE_SWARM && SIBYTE_SENTOSA && SIBYTE_BIGSUR && SWIOTLB_XEN && AMD_IOMMU) selects SWIOTLB which has unmet direct dependencies (CAVIUM_OCTEON_SOC || MACH_LOONGSON64 && CPU_LOONGSON3 || NLM_XLP_BOARD || NLM_XLR_BOARD) + + and the actual build: + + lib/swiotlb.o: In function `swiotlb_tbl_map_single': + (.text+0x1c0): undefined reference to `iommu_is_span_boundary' + Makefile:1021: recipe for target 'vmlinux' failed + +Reported-by: Guenter Roeck +Cc: Maciej W. Rozycki +Cc: Paul Burton +Cc: Christoph Hellwig +Cc: Ralf Baechle +Cc: linux-mips@linux-mips.org +Cc: linux-kernel@vger.kernel.org +Cc: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + arch/mips/Kconfig | 3 --- + arch/mips/sibyte/common/Makefile | 1 - + arch/mips/sibyte/common/dma.c | 14 -------------- + 3 files changed, 18 deletions(-) + delete mode 100644 arch/mips/sibyte/common/dma.c + +--- a/arch/mips/Kconfig ++++ b/arch/mips/Kconfig +@@ -792,7 +792,6 @@ config SIBYTE_SWARM + select SYS_SUPPORTS_HIGHMEM + select SYS_SUPPORTS_LITTLE_ENDIAN + select ZONE_DMA32 if 64BIT +- select SWIOTLB if ARCH_DMA_ADDR_T_64BIT && PCI + + config SIBYTE_LITTLESUR + bool "Sibyte BCM91250C2-LittleSur" +@@ -815,7 +814,6 @@ config SIBYTE_SENTOSA + select SYS_HAS_CPU_SB1 + select SYS_SUPPORTS_BIG_ENDIAN + select SYS_SUPPORTS_LITTLE_ENDIAN +- select SWIOTLB if ARCH_DMA_ADDR_T_64BIT && PCI + + config SIBYTE_BIGSUR + bool "Sibyte BCM91480B-BigSur" +@@ -829,7 +827,6 @@ config SIBYTE_BIGSUR + select SYS_SUPPORTS_HIGHMEM + select SYS_SUPPORTS_LITTLE_ENDIAN + select ZONE_DMA32 if 64BIT +- select SWIOTLB if ARCH_DMA_ADDR_T_64BIT && PCI + + config SNI_RM + bool "SNI RM200/300/400" +--- a/arch/mips/sibyte/common/Makefile ++++ b/arch/mips/sibyte/common/Makefile +@@ -1,5 +1,4 @@ + obj-y := cfe.o +-obj-$(CONFIG_SWIOTLB) += dma.o + obj-$(CONFIG_SIBYTE_BUS_WATCHER) += bus_watcher.o + obj-$(CONFIG_SIBYTE_CFE_CONSOLE) += cfe_console.o + obj-$(CONFIG_SIBYTE_TBPROF) += sb_tbprof.o +--- a/arch/mips/sibyte/common/dma.c ++++ /dev/null +@@ -1,14 +0,0 @@ +-// SPDX-License-Identifier: GPL-2.0+ +-/* +- * DMA support for Broadcom SiByte platforms. +- * +- * Copyright (c) 2018 Maciej W. Rozycki +- */ +- +-#include +-#include +- +-void __init plat_swiotlb_setup(void) +-{ +- swiotlb_init(1); +-} diff --git a/queue-4.9/series b/queue-4.9/series index f9473ad27d4..d38847036ea 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -10,3 +10,11 @@ sctp-use-transport-pf_retrans-in-sctp_do_8_2_transport_strike.patch tcp-fix-tcp_ecn_withdraw_cwr-to-clear-tcp_ecn_queue_cwr.patch tipc-add-null-pointer-check-before-calling-kfree_rcu.patch tun-fix-use-after-free-when-register-netdev-failed.patch +revert-mips-sibyte-enable-swiotlb-for-swarm-littlesur-and.patch +gpio-fix-line-flag-validation-in-linehandle_create.patch +gpio-fix-line-flag-validation-in-lineevent_create.patch +btrfs-fix-assertion-failure-during-fsync-and-use-of-stale-transaction.patch +genirq-prevent-null-pointer-dereference-in-resend_irqs.patch +kvm-s390-do-not-leak-kernel-stack-data-in-the-kvm_s390_interrupt-ioctl.patch +kvm-x86-work-around-leak-of-uninitialized-stack-contents.patch +kvm-nvmx-handle-page-fault-in-vmread.patch