--- /dev/null
+From 410f954cb1d1c79ae485dd83a175f21954fd87cd Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Tue, 10 Sep 2019 15:26:49 +0100
+Subject: Btrfs: fix assertion failure during fsync and use of stale transaction
+
+From: Filipe Manana <fdmanana@suse.com>
+
+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 <josef@toxicpanda.com>
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+
+---
+ fs/btrfs/tree-log.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/fs/btrfs/tree-log.c
++++ b/fs/btrfs/tree-log.c
+@@ -5133,7 +5133,7 @@ process_leaf:
+ }
+
+ if (btrfs_inode_in_log(di_inode, trans->transid)) {
+- iput(di_inode);
++ btrfs_add_delayed_iput(di_inode);
+ continue;
+ }
+
+@@ -5143,7 +5143,7 @@ process_leaf:
+ btrfs_release_path(path);
+ ret = btrfs_log_inode(trans, root, di_inode,
+ log_mode, 0, LLONG_MAX, ctx);
+- iput(di_inode);
++ btrfs_add_delayed_iput(di_inode);
+ if (ret)
+ goto next_dir_inode;
+ if (ctx->log_new_dentries) {
+@@ -5281,7 +5281,7 @@ static int btrfs_log_all_parents(struct
+
+ ret = btrfs_log_inode(trans, root, dir_inode,
+ LOG_INODE_ALL, 0, LLONG_MAX, ctx);
+- iput(dir_inode);
++ btrfs_add_delayed_iput(dir_inode);
+ if (ret)
+ goto out;
+ }
--- /dev/null
+From eddf3e9c7c7e4d0707c68d1bb22cc6ec8aef7d4a Mon Sep 17 00:00:00 2001
+From: Yunfeng Ye <yeyunfeng@huawei.com>
+Date: Wed, 4 Sep 2019 20:46:25 +0800
+Subject: genirq: Prevent NULL pointer dereference in resend_irqs()
+
+From: Yunfeng Ye <yeyunfeng@huawei.com>
+
+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 <yeyunfeng@huawei.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Reviewed-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/1630ae13-5c8e-901e-de09-e740b6a426a7@huawei.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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();
--- /dev/null
+From f7eea636c3d505fe6f1d1066234f1aaf7171b681 Mon Sep 17 00:00:00 2001
+From: Paolo Bonzini <pbonzini@redhat.com>
+Date: Sat, 14 Sep 2019 00:26:27 +0200
+Subject: KVM: nVMX: handle page fault in vmread
+
+From: Paolo Bonzini <pbonzini@redhat.com>
+
+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 <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -7247,6 +7247,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))
+@@ -7273,8 +7274,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);
--- /dev/null
+From 53936b5bf35e140ae27e4bbf0447a61063f400da Mon Sep 17 00:00:00 2001
+From: Thomas Huth <thuth@redhat.com>
+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 <thuth@redhat.com>
+
+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 <david@redhat.com>
+Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
+Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
+Signed-off-by: Thomas Huth <thuth@redhat.com>
+Link: https://lore.kernel.org/kvm/20190912115438.25761-1-thuth@redhat.com
+Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -1487,6 +1487,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
+@@ -2541,7 +2541,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)))
--- /dev/null
+From 541ab2aeb28251bf7135c7961f3a6080eebcc705 Mon Sep 17 00:00:00 2001
+From: Fuqian Huang <huangfq.daxian@gmail.com>
+Date: Thu, 12 Sep 2019 12:18:17 +0800
+Subject: KVM: x86: work around leak of uninitialized stack contents
+
+From: Fuqian Huang <huangfq.daxian@gmail.com>
+
+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 <huangfq.daxian@gmail.com>
+Cc: stable@vger.kernel.org
+[add comment]
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/x86.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -4337,6 +4337,13 @@ static int emulator_write_std(struct x86
+ if (!system && kvm_x86_ops->get_cpl(vcpu) == 3)
+ access |= PFERR_USER_MASK;
+
++ /*
++ * 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,
+ access, exception);
+ }
--- /dev/null
+From 1c7c801c76438c9ff184aa6fb071d64502d35be8 Mon Sep 17 00:00:00 2001
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Date: Mon, 16 Sep 2019 16:59:01 +0200
+Subject: Revert "MIPS: SiByte: Enable swiotlb for SWARM, LittleSur and BigSur"
+
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+This reverts commit c890a458e27210d1a749a18941047a9e4209fa93 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 <linux@roeck-us.net>
+Cc: Maciej W. Rozycki <macro@linux-mips.org>
+Cc: Paul Burton <paul.burton@mips.com>
+Cc: Christoph Hellwig <hch@lst.de>
+Cc: Ralf Baechle <ralf@linux-mips.org>
+Cc: linux-mips@linux-mips.org
+Cc: linux-kernel@vger.kernel.org
+Cc: Sasha Levin <sashal@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -761,7 +761,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"
+@@ -784,7 +783,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"
+@@ -798,7 +796,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 <linux/swiotlb.h>
+-#include <asm/bootinfo.h>
+-
+-void __init plat_swiotlb_setup(void)
+-{
+- swiotlb_init(1);
+-}
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
+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
projects / thirdparty / kernel / stable-queue.git / commitdiff
