From: Greg Kroah-Hartman Date: Fri, 9 Oct 2020 07:33:44 +0000 (+0200) Subject: 5.8-stable patches X-Git-Tag: v4.4.239~74 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=c139114028db4d332991e57675e475ba215e14ac;p=thirdparty%2Fkernel%2Fstable-queue.git 5.8-stable patches added patches: block-scsi-ioctl-fix-kernel-infoleak-in-scsi_put_cdrom_generic_arg.patch bpf-fix-scalar32_min_max_or-bounds-tracking.patch crypto-arm64-use-x16-with-indirect-branch-to-bti_c.patch drm-nouveau-device-return-error-for-unknown-chipsets.patch drm-nouveau-mem-guard-against-null-pointer-access-in-mem_del.patch exfat-fix-use-of-uninitialized-spinlock-on-error-path.patch net-wireless-nl80211-fix-out-of-bounds-access-in-nl80211_del_key.patch partitions-ibm-fix-non-dasd-devices.patch splice-teach-splice-pipe-reading-about-empty-pipe-buffers.patch usermodehelper-reset-umask-to-default-before-executing-user-process.patch vhost-don-t-call-access_ok-when-using-iotlb.patch vhost-use-vhost_get_used_size-in-vhost_vring_set_addr.patch --- diff --git a/queue-5.8/block-scsi-ioctl-fix-kernel-infoleak-in-scsi_put_cdrom_generic_arg.patch b/queue-5.8/block-scsi-ioctl-fix-kernel-infoleak-in-scsi_put_cdrom_generic_arg.patch new file mode 100644 index 00000000000..2f644394176 --- /dev/null +++ b/queue-5.8/block-scsi-ioctl-fix-kernel-infoleak-in-scsi_put_cdrom_generic_arg.patch @@ -0,0 +1,37 @@ +From 6d53a9fe5a1983490bc14b3a64d49fabb4ccc651 Mon Sep 17 00:00:00 2001 +From: Peilin Ye +Date: Fri, 2 Oct 2020 10:22:23 -0400 +Subject: block/scsi-ioctl: Fix kernel-infoleak in scsi_put_cdrom_generic_arg() + +From: Peilin Ye + +commit 6d53a9fe5a1983490bc14b3a64d49fabb4ccc651 upstream. + +scsi_put_cdrom_generic_arg() is copying uninitialized stack memory to +userspace, since the compiler may leave a 3-byte hole in the middle of +`cgc32`. Fix it by adding a padding field to `struct +compat_cdrom_generic_command`. + +Cc: stable@vger.kernel.org +Fixes: f3ee6e63a9df ("compat_ioctl: move CDROM_SEND_PACKET handling into scsi") +Suggested-by: Dan Carpenter +Suggested-by: Arnd Bergmann +Reported-by: syzbot+85433a479a646a064ab3@syzkaller.appspotmail.com +Signed-off-by: Peilin Ye +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + block/scsi_ioctl.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/block/scsi_ioctl.c ++++ b/block/scsi_ioctl.c +@@ -651,6 +651,7 @@ struct compat_cdrom_generic_command { + compat_int_t stat; + compat_caddr_t sense; + unsigned char data_direction; ++ unsigned char pad[3]; + compat_int_t quiet; + compat_int_t timeout; + compat_caddr_t reserved[1]; diff --git a/queue-5.8/bpf-fix-scalar32_min_max_or-bounds-tracking.patch b/queue-5.8/bpf-fix-scalar32_min_max_or-bounds-tracking.patch new file mode 100644 index 00000000000..b76b5a35d65 --- /dev/null +++ b/queue-5.8/bpf-fix-scalar32_min_max_or-bounds-tracking.patch @@ -0,0 +1,107 @@ +From 5b9fbeb75b6a98955f628e205ac26689bcb1383e Mon Sep 17 00:00:00 2001 +From: Daniel Borkmann +Date: Wed, 7 Oct 2020 15:48:58 +0200 +Subject: bpf: Fix scalar32_min_max_or bounds tracking + +From: Daniel Borkmann + +commit 5b9fbeb75b6a98955f628e205ac26689bcb1383e upstream. + +Simon reported an issue with the current scalar32_min_max_or() implementation. +That is, compared to the other 32 bit subreg tracking functions, the code in +scalar32_min_max_or() stands out that it's using the 64 bit registers instead +of 32 bit ones. This leads to bounds tracking issues, for example: + + [...] + 8: R0=map_value(id=0,off=0,ks=4,vs=48,imm=0) R10=fp0 fp-8=mmmmmmmm + 8: (79) r1 = *(u64 *)(r0 +0) + R0=map_value(id=0,off=0,ks=4,vs=48,imm=0) R10=fp0 fp-8=mmmmmmmm + 9: R0=map_value(id=0,off=0,ks=4,vs=48,imm=0) R1_w=inv(id=0) R10=fp0 fp-8=mmmmmmmm + 9: (b7) r0 = 1 + 10: R0_w=inv1 R1_w=inv(id=0) R10=fp0 fp-8=mmmmmmmm + 10: (18) r2 = 0x600000002 + 12: R0_w=inv1 R1_w=inv(id=0) R2_w=inv25769803778 R10=fp0 fp-8=mmmmmmmm + 12: (ad) if r1 < r2 goto pc+1 + R0_w=inv1 R1_w=inv(id=0,umin_value=25769803778) R2_w=inv25769803778 R10=fp0 fp-8=mmmmmmmm + 13: R0_w=inv1 R1_w=inv(id=0,umin_value=25769803778) R2_w=inv25769803778 R10=fp0 fp-8=mmmmmmmm + 13: (95) exit + 14: R0_w=inv1 R1_w=inv(id=0,umax_value=25769803777,var_off=(0x0; 0x7ffffffff)) R2_w=inv25769803778 R10=fp0 fp-8=mmmmmmmm + 14: (25) if r1 > 0x0 goto pc+1 + R0_w=inv1 R1_w=inv(id=0,umax_value=0,var_off=(0x0; 0x7fffffff),u32_max_value=2147483647) R2_w=inv25769803778 R10=fp0 fp-8=mmmmmmmm + 15: R0_w=inv1 R1_w=inv(id=0,umax_value=0,var_off=(0x0; 0x7fffffff),u32_max_value=2147483647) R2_w=inv25769803778 R10=fp0 fp-8=mmmmmmmm + 15: (95) exit + 16: R0_w=inv1 R1_w=inv(id=0,umin_value=1,umax_value=25769803777,var_off=(0x0; 0x77fffffff),u32_max_value=2147483647) R2_w=inv25769803778 R10=fp0 fp-8=mmmmmmmm + 16: (47) r1 |= 0 + 17: R0_w=inv1 R1_w=inv(id=0,umin_value=1,umax_value=32212254719,var_off=(0x1; 0x700000000),s32_max_value=1,u32_max_value=1) R2_w=inv25769803778 R10=fp0 fp-8=mmmmmmmm + [...] + +The bound tests on the map value force the upper unsigned bound to be 25769803777 +in 64 bit (0b11000000000000000000000000000000001) and then lower one to be 1. By +using OR they are truncated and thus result in the range [1,1] for the 32 bit reg +tracker. This is incorrect given the only thing we know is that the value must be +positive and thus 2147483647 (0b1111111111111111111111111111111) at max for the +subregs. Fix it by using the {u,s}32_{min,max}_value vars instead. This also makes +sense, for example, for the case where we update dst_reg->s32_{min,max}_value in +the else branch we need to use the newly computed dst_reg->u32_{min,max}_value as +we know that these are positive. Previously, in the else branch the 64 bit values +of umin_value=1 and umax_value=32212254719 were used and latter got truncated to +be 1 as upper bound there. After the fix the subreg range is now correct: + + [...] + 8: R0=map_value(id=0,off=0,ks=4,vs=48,imm=0) R10=fp0 fp-8=mmmmmmmm + 8: (79) r1 = *(u64 *)(r0 +0) + R0=map_value(id=0,off=0,ks=4,vs=48,imm=0) R10=fp0 fp-8=mmmmmmmm + 9: R0=map_value(id=0,off=0,ks=4,vs=48,imm=0) R1_w=inv(id=0) R10=fp0 fp-8=mmmmmmmm + 9: (b7) r0 = 1 + 10: R0_w=inv1 R1_w=inv(id=0) R10=fp0 fp-8=mmmmmmmm + 10: (18) r2 = 0x600000002 + 12: R0_w=inv1 R1_w=inv(id=0) R2_w=inv25769803778 R10=fp0 fp-8=mmmmmmmm + 12: (ad) if r1 < r2 goto pc+1 + R0_w=inv1 R1_w=inv(id=0,umin_value=25769803778) R2_w=inv25769803778 R10=fp0 fp-8=mmmmmmmm + 13: R0_w=inv1 R1_w=inv(id=0,umin_value=25769803778) R2_w=inv25769803778 R10=fp0 fp-8=mmmmmmmm + 13: (95) exit + 14: R0_w=inv1 R1_w=inv(id=0,umax_value=25769803777,var_off=(0x0; 0x7ffffffff)) R2_w=inv25769803778 R10=fp0 fp-8=mmmmmmmm + 14: (25) if r1 > 0x0 goto pc+1 + R0_w=inv1 R1_w=inv(id=0,umax_value=0,var_off=(0x0; 0x7fffffff),u32_max_value=2147483647) R2_w=inv25769803778 R10=fp0 fp-8=mmmmmmmm + 15: R0_w=inv1 R1_w=inv(id=0,umax_value=0,var_off=(0x0; 0x7fffffff),u32_max_value=2147483647) R2_w=inv25769803778 R10=fp0 fp-8=mmmmmmmm + 15: (95) exit + 16: R0_w=inv1 R1_w=inv(id=0,umin_value=1,umax_value=25769803777,var_off=(0x0; 0x77fffffff),u32_max_value=2147483647) R2_w=inv25769803778 R10=fp0 fp-8=mmmmmmmm + 16: (47) r1 |= 0 + 17: R0_w=inv1 R1_w=inv(id=0,umin_value=1,umax_value=32212254719,var_off=(0x0; 0x77fffffff),u32_max_value=2147483647) R2_w=inv25769803778 R10=fp0 fp-8=mmmmmmmm + [...] + +Fixes: 3f50f132d840 ("bpf: Verifier, do explicit ALU32 bounds tracking") +Reported-by: Simon Scannell +Signed-off-by: Daniel Borkmann +Reviewed-by: John Fastabend +Acked-by: Alexei Starovoitov +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/bpf/verifier.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/kernel/bpf/verifier.c ++++ b/kernel/bpf/verifier.c +@@ -5490,8 +5490,8 @@ static void scalar32_min_max_or(struct b + bool src_known = tnum_subreg_is_const(src_reg->var_off); + bool dst_known = tnum_subreg_is_const(dst_reg->var_off); + struct tnum var32_off = tnum_subreg(dst_reg->var_off); +- s32 smin_val = src_reg->smin_value; +- u32 umin_val = src_reg->umin_value; ++ s32 smin_val = src_reg->s32_min_value; ++ u32 umin_val = src_reg->u32_min_value; + + /* Assuming scalar64_min_max_or will be called so it is safe + * to skip updating register for known case. +@@ -5514,8 +5514,8 @@ static void scalar32_min_max_or(struct b + /* ORing two positives gives a positive, so safe to + * cast result into s64. + */ +- dst_reg->s32_min_value = dst_reg->umin_value; +- dst_reg->s32_max_value = dst_reg->umax_value; ++ dst_reg->s32_min_value = dst_reg->u32_min_value; ++ dst_reg->s32_max_value = dst_reg->u32_max_value; + } + } + diff --git a/queue-5.8/crypto-arm64-use-x16-with-indirect-branch-to-bti_c.patch b/queue-5.8/crypto-arm64-use-x16-with-indirect-branch-to-bti_c.patch new file mode 100644 index 00000000000..8ba5cd5422b --- /dev/null +++ b/queue-5.8/crypto-arm64-use-x16-with-indirect-branch-to-bti_c.patch @@ -0,0 +1,67 @@ +From 39e4716caa598a07a98598b2e7cd03055ce25fb9 Mon Sep 17 00:00:00 2001 +From: Jeremy Linton +Date: Tue, 6 Oct 2020 11:33:26 -0500 +Subject: crypto: arm64: Use x16 with indirect branch to bti_c + +From: Jeremy Linton + +commit 39e4716caa598a07a98598b2e7cd03055ce25fb9 upstream. + +The AES code uses a 'br x7' as part of a function called by +a macro. That branch needs a bti_j as a target. This results +in a panic as seen below. Using x16 (or x17) with an indirect +branch keeps the target bti_c. + + Bad mode in Synchronous Abort handler detected on CPU1, code 0x34000003 -- BTI + CPU: 1 PID: 265 Comm: cryptomgr_test Not tainted 5.8.11-300.fc33.aarch64 #1 + pstate: 20400c05 (nzCv daif +PAN -UAO BTYPE=j-) + pc : aesbs_encrypt8+0x0/0x5f0 [aes_neon_bs] + lr : aesbs_xts_encrypt+0x48/0xe0 [aes_neon_bs] + sp : ffff80001052b730 + + aesbs_encrypt8+0x0/0x5f0 [aes_neon_bs] + __xts_crypt+0xb0/0x2dc [aes_neon_bs] + xts_encrypt+0x28/0x3c [aes_neon_bs] + crypto_skcipher_encrypt+0x50/0x84 + simd_skcipher_encrypt+0xc8/0xe0 + crypto_skcipher_encrypt+0x50/0x84 + test_skcipher_vec_cfg+0x224/0x5f0 + test_skcipher+0xbc/0x120 + alg_test_skcipher+0xa0/0x1b0 + alg_test+0x3dc/0x47c + cryptomgr_test+0x38/0x60 + +Fixes: 0e89640b640d ("crypto: arm64 - Use modern annotations for assembly functions") +Cc: # 5.6.x- +Signed-off-by: Jeremy Linton +Suggested-by: Dave P Martin +Reviewed-by: Ard Biesheuvel +Reviewed-by: Mark Brown +Link: https://lore.kernel.org/r/20201006163326.2780619-1-jeremy.linton@arm.com +Signed-off-by: Catalin Marinas +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm64/crypto/aes-neonbs-core.S | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/arm64/crypto/aes-neonbs-core.S ++++ b/arch/arm64/crypto/aes-neonbs-core.S +@@ -788,7 +788,7 @@ SYM_FUNC_START_LOCAL(__xts_crypt8) + + 0: mov bskey, x21 + mov rounds, x22 +- br x7 ++ br x16 + SYM_FUNC_END(__xts_crypt8) + + .macro __xts_crypt, do8, o0, o1, o2, o3, o4, o5, o6, o7 +@@ -806,7 +806,7 @@ SYM_FUNC_END(__xts_crypt8) + uzp1 v30.4s, v30.4s, v25.4s + ld1 {v25.16b}, [x24] + +-99: adr x7, \do8 ++99: adr x16, \do8 + bl __xts_crypt8 + + ldp q16, q17, [sp, #.Lframe_local_offset] diff --git a/queue-5.8/drm-nouveau-device-return-error-for-unknown-chipsets.patch b/queue-5.8/drm-nouveau-device-return-error-for-unknown-chipsets.patch new file mode 100644 index 00000000000..6c264dc7788 --- /dev/null +++ b/queue-5.8/drm-nouveau-device-return-error-for-unknown-chipsets.patch @@ -0,0 +1,39 @@ +From c3e0276c31ca8c7b8615da890727481260d4676f Mon Sep 17 00:00:00 2001 +From: Karol Herbst +Date: Wed, 7 Oct 2020 00:05:27 +0200 +Subject: drm/nouveau/device: return error for unknown chipsets + +From: Karol Herbst + +commit c3e0276c31ca8c7b8615da890727481260d4676f upstream. + +Previously the code relied on device->pri to be NULL and to fail probing +later. We really should just return an error inside nvkm_device_ctor for +unsupported GPUs. + +Fixes: 24d5ff40a732 ("drm/nouveau/device: rework mmio mapping code to get rid of second map") + +Signed-off-by: Karol Herbst +Cc: dann frazier +Cc: dri-devel +Cc: Dave Airlie +Cc: stable@vger.kernel.org +Reviewed-by: Jeremy Cline +Signed-off-by: Dave Airlie +Link: https://patchwork.freedesktop.org/patch/msgid/20201006220528.13925-1-kherbst@redhat.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c ++++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c +@@ -3149,6 +3149,7 @@ nvkm_device_ctor(const struct nvkm_devic + case 0x168: device->chip = &nv168_chipset; break; + default: + nvdev_error(device, "unknown chipset (%08x)\n", boot0); ++ ret = -ENODEV; + goto done; + } + diff --git a/queue-5.8/drm-nouveau-mem-guard-against-null-pointer-access-in-mem_del.patch b/queue-5.8/drm-nouveau-mem-guard-against-null-pointer-access-in-mem_del.patch new file mode 100644 index 00000000000..58422cfb64e --- /dev/null +++ b/queue-5.8/drm-nouveau-mem-guard-against-null-pointer-access-in-mem_del.patch @@ -0,0 +1,34 @@ +From d10285a25e29f13353bbf7760be8980048c1ef2f Mon Sep 17 00:00:00 2001 +From: Karol Herbst +Date: Wed, 7 Oct 2020 00:05:28 +0200 +Subject: drm/nouveau/mem: guard against NULL pointer access in mem_del + +From: Karol Herbst + +commit d10285a25e29f13353bbf7760be8980048c1ef2f upstream. + +other drivers seems to do something similar + +Signed-off-by: Karol Herbst +Cc: dri-devel +Cc: Dave Airlie +Cc: stable@vger.kernel.org +Signed-off-by: Dave Airlie +Link: https://patchwork.freedesktop.org/patch/msgid/20201006220528.13925-2-kherbst@redhat.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/nouveau/nouveau_mem.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/gpu/drm/nouveau/nouveau_mem.c ++++ b/drivers/gpu/drm/nouveau/nouveau_mem.c +@@ -176,6 +176,8 @@ void + nouveau_mem_del(struct ttm_mem_reg *reg) + { + struct nouveau_mem *mem = nouveau_mem(reg); ++ if (!mem) ++ return; + nouveau_mem_fini(mem); + kfree(reg->mm_node); + reg->mm_node = NULL; diff --git a/queue-5.8/exfat-fix-use-of-uninitialized-spinlock-on-error-path.patch b/queue-5.8/exfat-fix-use-of-uninitialized-spinlock-on-error-path.patch new file mode 100644 index 00000000000..59495775b84 --- /dev/null +++ b/queue-5.8/exfat-fix-use-of-uninitialized-spinlock-on-error-path.patch @@ -0,0 +1,130 @@ +From 8ff006e57ad3a25f909c456d053aa498b6673a39 Mon Sep 17 00:00:00 2001 +From: Namjae Jeon +Date: Tue, 29 Sep 2020 09:09:49 +0900 +Subject: exfat: fix use of uninitialized spinlock on error path + +From: Namjae Jeon + +commit 8ff006e57ad3a25f909c456d053aa498b6673a39 upstream. + +syzbot reported warning message: + +Call Trace: + __dump_stack lib/dump_stack.c:77 [inline] + dump_stack+0x1d6/0x29e lib/dump_stack.c:118 + register_lock_class+0xf06/0x1520 kernel/locking/lockdep.c:893 + __lock_acquire+0xfd/0x2ae0 kernel/locking/lockdep.c:4320 + lock_acquire+0x148/0x720 kernel/locking/lockdep.c:5029 + __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline] + _raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:151 + spin_lock include/linux/spinlock.h:354 [inline] + exfat_cache_inval_inode+0x30/0x280 fs/exfat/cache.c:226 + exfat_evict_inode+0x124/0x270 fs/exfat/inode.c:660 + evict+0x2bb/0x6d0 fs/inode.c:576 + exfat_fill_super+0x1e07/0x27d0 fs/exfat/super.c:681 + get_tree_bdev+0x3e9/0x5f0 fs/super.c:1342 + vfs_get_tree+0x88/0x270 fs/super.c:1547 + do_new_mount fs/namespace.c:2875 [inline] + path_mount+0x179d/0x29e0 fs/namespace.c:3192 + do_mount fs/namespace.c:3205 [inline] + __do_sys_mount fs/namespace.c:3413 [inline] + __se_sys_mount+0x126/0x180 fs/namespace.c:3390 + do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + +If exfat_read_root() returns an error, spinlock is used in +exfat_evict_inode() without initialization. This patch combines +exfat_cache_init_inode() with exfat_inode_init_once() to initialize +spinlock by slab constructor. + +Fixes: c35b6810c495 ("exfat: add exfat cache") +Cc: stable@vger.kernel.org # v5.7+ +Reported-by: syzbot +Signed-off-by: Namjae Jeon +Signed-off-by: Greg Kroah-Hartman + +--- + fs/exfat/cache.c | 11 ----------- + fs/exfat/exfat_fs.h | 3 ++- + fs/exfat/inode.c | 2 -- + fs/exfat/super.c | 5 ++++- + 4 files changed, 6 insertions(+), 15 deletions(-) + +--- a/fs/exfat/cache.c ++++ b/fs/exfat/cache.c +@@ -17,7 +17,6 @@ + #include "exfat_raw.h" + #include "exfat_fs.h" + +-#define EXFAT_CACHE_VALID 0 + #define EXFAT_MAX_CACHE 16 + + struct exfat_cache { +@@ -61,16 +60,6 @@ void exfat_cache_shutdown(void) + kmem_cache_destroy(exfat_cachep); + } + +-void exfat_cache_init_inode(struct inode *inode) +-{ +- struct exfat_inode_info *ei = EXFAT_I(inode); +- +- spin_lock_init(&ei->cache_lru_lock); +- ei->nr_caches = 0; +- ei->cache_valid_id = EXFAT_CACHE_VALID + 1; +- INIT_LIST_HEAD(&ei->cache_lru); +-} +- + static inline struct exfat_cache *exfat_cache_alloc(void) + { + return kmem_cache_alloc(exfat_cachep, GFP_NOFS); +--- a/fs/exfat/exfat_fs.h ++++ b/fs/exfat/exfat_fs.h +@@ -250,6 +250,8 @@ struct exfat_sb_info { + struct rcu_head rcu; + }; + ++#define EXFAT_CACHE_VALID 0 ++ + /* + * EXFAT file system inode in-memory data + */ +@@ -429,7 +431,6 @@ extern const struct dentry_operations ex + /* cache.c */ + int exfat_cache_init(void); + void exfat_cache_shutdown(void); +-void exfat_cache_init_inode(struct inode *inode); + void exfat_cache_inval_inode(struct inode *inode); + int exfat_get_cluster(struct inode *inode, unsigned int cluster, + unsigned int *fclus, unsigned int *dclus, +--- a/fs/exfat/inode.c ++++ b/fs/exfat/inode.c +@@ -610,8 +610,6 @@ static int exfat_fill_inode(struct inode + ei->i_crtime = info->crtime; + inode->i_atime = info->atime; + +- exfat_cache_init_inode(inode); +- + return 0; + } + +--- a/fs/exfat/super.c ++++ b/fs/exfat/super.c +@@ -361,7 +361,6 @@ static int exfat_read_root(struct inode + inode->i_mtime = inode->i_atime = inode->i_ctime = ei->i_crtime = + current_time(inode); + exfat_truncate_atime(&inode->i_atime); +- exfat_cache_init_inode(inode); + return 0; + } + +@@ -747,6 +746,10 @@ static void exfat_inode_init_once(void * + { + struct exfat_inode_info *ei = (struct exfat_inode_info *)foo; + ++ spin_lock_init(&ei->cache_lru_lock); ++ ei->nr_caches = 0; ++ ei->cache_valid_id = EXFAT_CACHE_VALID + 1; ++ INIT_LIST_HEAD(&ei->cache_lru); + INIT_HLIST_NODE(&ei->i_hash_fat); + inode_init_once(&ei->vfs_inode); + } diff --git a/queue-5.8/net-wireless-nl80211-fix-out-of-bounds-access-in-nl80211_del_key.patch b/queue-5.8/net-wireless-nl80211-fix-out-of-bounds-access-in-nl80211_del_key.patch new file mode 100644 index 00000000000..98b834b9747 --- /dev/null +++ b/queue-5.8/net-wireless-nl80211-fix-out-of-bounds-access-in-nl80211_del_key.patch @@ -0,0 +1,42 @@ +From 3dc289f8f139997f4e9d3cfccf8738f20d23e47b Mon Sep 17 00:00:00 2001 +From: Anant Thazhemadam +Date: Wed, 7 Oct 2020 09:24:01 +0530 +Subject: net: wireless: nl80211: fix out-of-bounds access in nl80211_del_key() + +From: Anant Thazhemadam + +commit 3dc289f8f139997f4e9d3cfccf8738f20d23e47b upstream. + +In nl80211_parse_key(), key.idx is first initialized as -1. +If this value of key.idx remains unmodified and gets returned, and +nl80211_key_allowed() also returns 0, then rdev_del_key() gets called +with key.idx = -1. +This causes an out-of-bounds array access. + +Handle this issue by checking if the value of key.idx after +nl80211_parse_key() is called and return -EINVAL if key.idx < 0. + +Cc: stable@vger.kernel.org +Reported-by: syzbot+b1bb342d1d097516cbda@syzkaller.appspotmail.com +Tested-by: syzbot+b1bb342d1d097516cbda@syzkaller.appspotmail.com +Signed-off-by: Anant Thazhemadam +Link: https://lore.kernel.org/r/20201007035401.9522-1-anant.thazhemadam@gmail.com +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman + +--- + net/wireless/nl80211.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/net/wireless/nl80211.c ++++ b/net/wireless/nl80211.c +@@ -4172,6 +4172,9 @@ static int nl80211_del_key(struct sk_buf + if (err) + return err; + ++ if (key.idx < 0) ++ return -EINVAL; ++ + if (info->attrs[NL80211_ATTR_MAC]) + mac_addr = nla_data(info->attrs[NL80211_ATTR_MAC]); + diff --git a/queue-5.8/partitions-ibm-fix-non-dasd-devices.patch b/queue-5.8/partitions-ibm-fix-non-dasd-devices.patch new file mode 100644 index 00000000000..2aa7c02dd28 --- /dev/null +++ b/queue-5.8/partitions-ibm-fix-non-dasd-devices.patch @@ -0,0 +1,54 @@ +From 7370997d48520ad923e8eb4deb59ebf290396202 Mon Sep 17 00:00:00 2001 +From: Christoph Hellwig +Date: Wed, 7 Oct 2020 14:40:09 +0200 +Subject: partitions/ibm: fix non-DASD devices + +From: Christoph Hellwig + +commit 7370997d48520ad923e8eb4deb59ebf290396202 upstream. + +Don't error out if the dasd_biodasdinfo symbol is not available. + +Cc: stable@vger.kernel.org +Fixes: 26d7e28e3820 ("s390/dasd: remove ioctl_by_bdev calls") +Reported-by: Christian Borntraeger +Signed-off-by: Christoph Hellwig +Tested-by: Christian Borntraeger +Reviewed-by: Stefan Haberland +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + block/partitions/ibm.c | 7 +++---- + 1 file changed, 3 insertions(+), 4 deletions(-) + +--- a/block/partitions/ibm.c ++++ b/block/partitions/ibm.c +@@ -305,8 +305,6 @@ int ibm_partition(struct parsed_partitio + if (!disk->fops->getgeo) + goto out_exit; + fn = symbol_get(dasd_biodasdinfo); +- if (!fn) +- goto out_exit; + blocksize = bdev_logical_block_size(bdev); + if (blocksize <= 0) + goto out_symbol; +@@ -326,7 +324,7 @@ int ibm_partition(struct parsed_partitio + geo->start = get_start_sect(bdev); + if (disk->fops->getgeo(bdev, geo)) + goto out_freeall; +- if (fn(disk, info)) { ++ if (!fn || fn(disk, info)) { + kfree(info); + info = NULL; + } +@@ -370,7 +368,8 @@ out_nolab: + out_nogeo: + kfree(info); + out_symbol: +- symbol_put(dasd_biodasdinfo); ++ if (fn) ++ symbol_put(dasd_biodasdinfo); + out_exit: + return res; + } diff --git a/queue-5.8/series b/queue-5.8/series index 98cdea3c901..7fee6021ef9 100644 --- a/queue-5.8/series +++ b/queue-5.8/series @@ -2,3 +2,15 @@ fbdev-newport_con-move-font_extra_words-macros-into-linux-font.h.patch fonts-support-font_extra_words-macros-for-built-in-fonts.patch fbcon-fix-global-out-of-bounds-read-in-fbcon_get_font.patch revert-ravb-fixed-to-be-able-to-unload-modules.patch +bpf-fix-scalar32_min_max_or-bounds-tracking.patch +crypto-arm64-use-x16-with-indirect-branch-to-bti_c.patch +exfat-fix-use-of-uninitialized-spinlock-on-error-path.patch +net-wireless-nl80211-fix-out-of-bounds-access-in-nl80211_del_key.patch +drm-nouveau-device-return-error-for-unknown-chipsets.patch +drm-nouveau-mem-guard-against-null-pointer-access-in-mem_del.patch +partitions-ibm-fix-non-dasd-devices.patch +block-scsi-ioctl-fix-kernel-infoleak-in-scsi_put_cdrom_generic_arg.patch +vhost-don-t-call-access_ok-when-using-iotlb.patch +vhost-use-vhost_get_used_size-in-vhost_vring_set_addr.patch +usermodehelper-reset-umask-to-default-before-executing-user-process.patch +splice-teach-splice-pipe-reading-about-empty-pipe-buffers.patch diff --git a/queue-5.8/splice-teach-splice-pipe-reading-about-empty-pipe-buffers.patch b/queue-5.8/splice-teach-splice-pipe-reading-about-empty-pipe-buffers.patch new file mode 100644 index 00000000000..e108a34b1f2 --- /dev/null +++ b/queue-5.8/splice-teach-splice-pipe-reading-about-empty-pipe-buffers.patch @@ -0,0 +1,99 @@ +From d1a819a2ec2d3b5e6a8f8a9f67386bda0ad315bc Mon Sep 17 00:00:00 2001 +From: Linus Torvalds +Date: Mon, 5 Oct 2020 11:26:27 -0700 +Subject: splice: teach splice pipe reading about empty pipe buffers + +From: Linus Torvalds + +commit d1a819a2ec2d3b5e6a8f8a9f67386bda0ad315bc upstream. + +Tetsuo Handa reports that splice() can return 0 before the real EOF, if +the data in the splice source pipe is an empty pipe buffer. That empty +pipe buffer case doesn't happen in any normal situation, but you can +trigger it by doing a write to a pipe that fails due to a page fault. + +Tetsuo has a test-case to show the behavior: + + #define _GNU_SOURCE + #include + #include + #include + #include + + int main(int argc, char *argv[]) + { + const int fd = open("/tmp/testfile", O_WRONLY | O_CREAT, 0600); + int pipe_fd[2] = { -1, -1 }; + pipe(pipe_fd); + write(pipe_fd[1], NULL, 4096); + /* This splice() should wait unless interrupted. */ + return !splice(pipe_fd[0], NULL, fd, NULL, 65536, 0); + } + +which results in + + write(5, NULL, 4096) = -1 EFAULT (Bad address) + splice(4, NULL, 3, NULL, 65536, 0) = 0 + +and this can confuse splice() users into believing they have hit EOF +prematurely. + +The issue was introduced when the pipe write code started pre-allocating +the pipe buffers before copying data from user space. + +This is modified verion of Tetsuo's original patch. + +Fixes: a194dfe6e6f6 ("pipe: Rearrange sequence in pipe_write() to preallocate slot") +Link:https://lore.kernel.org/linux-fsdevel/20201005121339.4063-1-penguin-kernel@I-love.SAKURA.ne.jp/ +Reported-by: Tetsuo Handa +Acked-by: Tetsuo Handa +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + fs/splice.c | 20 ++++++++++++++++++++ + 1 file changed, 20 insertions(+) + +--- a/fs/splice.c ++++ b/fs/splice.c +@@ -526,6 +526,22 @@ static int splice_from_pipe_feed(struct + return 1; + } + ++/* We know we have a pipe buffer, but maybe it's empty? */ ++static inline bool eat_empty_buffer(struct pipe_inode_info *pipe) ++{ ++ unsigned int tail = pipe->tail; ++ unsigned int mask = pipe->ring_size - 1; ++ struct pipe_buffer *buf = &pipe->bufs[tail & mask]; ++ ++ if (unlikely(!buf->len)) { ++ pipe_buf_release(pipe, buf); ++ pipe->tail = tail+1; ++ return true; ++ } ++ ++ return false; ++} ++ + /** + * splice_from_pipe_next - wait for some data to splice from + * @pipe: pipe to splice from +@@ -545,6 +561,7 @@ static int splice_from_pipe_next(struct + if (signal_pending(current)) + return -ERESTARTSYS; + ++repeat: + while (pipe_empty(pipe->head, pipe->tail)) { + if (!pipe->writers) + return 0; +@@ -566,6 +583,9 @@ static int splice_from_pipe_next(struct + pipe_wait_readable(pipe); + } + ++ if (eat_empty_buffer(pipe)) ++ goto repeat; ++ + return 1; + } + diff --git a/queue-5.8/usermodehelper-reset-umask-to-default-before-executing-user-process.patch b/queue-5.8/usermodehelper-reset-umask-to-default-before-executing-user-process.patch new file mode 100644 index 00000000000..eb7dec57a46 --- /dev/null +++ b/queue-5.8/usermodehelper-reset-umask-to-default-before-executing-user-process.patch @@ -0,0 +1,64 @@ +From 4013c1496c49615d90d36b9d513eee8e369778e9 Mon Sep 17 00:00:00 2001 +From: Linus Torvalds +Date: Mon, 5 Oct 2020 10:56:22 -0700 +Subject: usermodehelper: reset umask to default before executing user process + +From: Linus Torvalds + +commit 4013c1496c49615d90d36b9d513eee8e369778e9 upstream. + +Kernel threads intentionally do CLONE_FS in order to follow any changes +that 'init' does to set up the root directory (or cwd). + +It is admittedly a bit odd, but it avoids the situation where 'init' +does some extensive setup to initialize the system environment, and then +we execute a usermode helper program, and it uses the original FS setup +from boot time that may be very limited and incomplete. + +[ Both Al Viro and Eric Biederman point out that 'pivot_root()' will + follow the root regardless, since it fixes up other users of root (see + chroot_fs_refs() for details), but overmounting root and doing a + chroot() would not. ] + +However, Vegard Nossum noticed that the CLONE_FS not only means that we +follow the root and current working directories, it also means we share +umask with whatever init changed it to. That wasn't intentional. + +Just reset umask to the original default (0022) before actually starting +the usermode helper program. + +Reported-by: Vegard Nossum +Cc: Al Viro +Acked-by: Eric W. Biederman +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/umh.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +--- a/kernel/umh.c ++++ b/kernel/umh.c +@@ -14,6 +14,7 @@ + #include + #include + #include ++#include + #include + #include + #include +@@ -76,6 +77,14 @@ static int call_usermodehelper_exec_asyn + spin_unlock_irq(¤t->sighand->siglock); + + /* ++ * Initial kernel threads share ther FS with init, in order to ++ * get the init root directory. But we've now created a new ++ * thread that is going to execve a user process and has its own ++ * 'struct fs_struct'. Reset umask to the default. ++ */ ++ current->fs->umask = 0022; ++ ++ /* + * Our parent (unbound workqueue) runs with elevated scheduling + * priority. Avoid propagating that into the userspace child. + */ diff --git a/queue-5.8/vhost-don-t-call-access_ok-when-using-iotlb.patch b/queue-5.8/vhost-don-t-call-access_ok-when-using-iotlb.patch new file mode 100644 index 00000000000..518102fd356 --- /dev/null +++ b/queue-5.8/vhost-don-t-call-access_ok-when-using-iotlb.patch @@ -0,0 +1,58 @@ +From 0210a8db2aeca393fb3067e234967877e3146266 Mon Sep 17 00:00:00 2001 +From: Greg Kurz +Date: Sat, 3 Oct 2020 12:01:52 +0200 +Subject: vhost: Don't call access_ok() when using IOTLB + +From: Greg Kurz + +commit 0210a8db2aeca393fb3067e234967877e3146266 upstream. + +When the IOTLB device is enabled, the vring addresses we get +from userspace are GIOVAs. It is thus wrong to pass them down +to access_ok() which only takes HVAs. + +Access validation is done at prefetch time with IOTLB. Teach +vq_access_ok() about that by moving the (vq->iotlb) check +from vhost_vq_access_ok() to vq_access_ok(). This prevents +vhost_vring_set_addr() to fail when verifying the accesses. +No behavior change for vhost_vq_access_ok(). + +BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1883084 +Fixes: 6b1e6cc7855b ("vhost: new device IOTLB API") +Cc: jasowang@redhat.com +CC: stable@vger.kernel.org # 4.14+ +Signed-off-by: Greg Kurz +Acked-by: Jason Wang +Link: https://lore.kernel.org/r/160171931213.284610.2052489816407219136.stgit@bahia.lan +Signed-off-by: Michael S. Tsirkin +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/vhost/vhost.c | 9 +++++---- + 1 file changed, 5 insertions(+), 4 deletions(-) + +--- a/drivers/vhost/vhost.c ++++ b/drivers/vhost/vhost.c +@@ -1283,6 +1283,11 @@ static bool vq_access_ok(struct vhost_vi + vring_used_t __user *used) + + { ++ /* If an IOTLB device is present, the vring addresses are ++ * GIOVAs. Access validation occurs at prefetch time. */ ++ if (vq->iotlb) ++ return true; ++ + return access_ok(desc, vhost_get_desc_size(vq, num)) && + access_ok(avail, vhost_get_avail_size(vq, num)) && + access_ok(used, vhost_get_used_size(vq, num)); +@@ -1376,10 +1381,6 @@ bool vhost_vq_access_ok(struct vhost_vir + if (!vq_log_access_ok(vq, vq->log_base)) + return false; + +- /* Access validation occurs at prefetch time with IOTLB */ +- if (vq->iotlb) +- return true; +- + return vq_access_ok(vq, vq->num, vq->desc, vq->avail, vq->used); + } + EXPORT_SYMBOL_GPL(vhost_vq_access_ok); diff --git a/queue-5.8/vhost-use-vhost_get_used_size-in-vhost_vring_set_addr.patch b/queue-5.8/vhost-use-vhost_get_used_size-in-vhost_vring_set_addr.patch new file mode 100644 index 00000000000..871d0b20144 --- /dev/null +++ b/queue-5.8/vhost-use-vhost_get_used_size-in-vhost_vring_set_addr.patch @@ -0,0 +1,36 @@ +From 71878fa46c7e3b40fa7b3f1b6e4ba3f92f1ac359 Mon Sep 17 00:00:00 2001 +From: Greg Kurz +Date: Sat, 3 Oct 2020 12:02:03 +0200 +Subject: vhost: Use vhost_get_used_size() in vhost_vring_set_addr() + +From: Greg Kurz + +commit 71878fa46c7e3b40fa7b3f1b6e4ba3f92f1ac359 upstream. + +The open-coded computation of the used size doesn't take the event +into account when the VIRTIO_RING_F_EVENT_IDX feature is present. +Fix that by using vhost_get_used_size(). + +Fixes: 8ea8cf89e19a ("vhost: support event index") +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kurz +Link: https://lore.kernel.org/r/160171932300.284610.11846106312938909461.stgit@bahia.lan +Signed-off-by: Michael S. Tsirkin +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/vhost/vhost.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/drivers/vhost/vhost.c ++++ b/drivers/vhost/vhost.c +@@ -1512,8 +1512,7 @@ static long vhost_vring_set_addr(struct + /* Also validate log access for used ring if enabled. */ + if ((a.flags & (0x1 << VHOST_VRING_F_LOG)) && + !log_access_ok(vq->log_base, a.log_guest_addr, +- sizeof *vq->used + +- vq->num * sizeof *vq->used->ring)) ++ vhost_get_used_size(vq, vq->num))) + return -EINVAL; + } +