From: Greg Kroah-Hartman Date: Mon, 10 May 2021 07:56:36 +0000 (+0200) Subject: 5.11-stable patches X-Git-Tag: v5.4.118~23 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=c1f3fb31752f5eeddc9de5f4ffcb99b5450a8383;p=thirdparty%2Fkernel%2Fstable-queue.git 5.11-stable patches added patches: futex-do-not-apply-time-namespace-adjustment-on-futex_lock_pi.patch jffs2-check-the-validity-of-dstlen-in-jffs2_zlib_compress.patch revert-337f13046ff0-futex-allow-futex_clock_realtime-with-futex_wait-op.patch smb3-do-not-attempt-multichannel-to-server-which-does-not-support-it.patch smb3-if-max_channels-set-to-more-than-one-channel-request-multichannel.patch smb3-when-mounting-with-multichannel-include-it-in-requested-capabilities.patch x86-cpu-initialize-msr_tsc_aux-if-rdtscp-or-rdpid-is-supported.patch --- diff --git a/queue-5.11/futex-do-not-apply-time-namespace-adjustment-on-futex_lock_pi.patch b/queue-5.11/futex-do-not-apply-time-namespace-adjustment-on-futex_lock_pi.patch new file mode 100644 index 00000000000..6c71371762f --- /dev/null +++ b/queue-5.11/futex-do-not-apply-time-namespace-adjustment-on-futex_lock_pi.patch @@ -0,0 +1,47 @@ +From cdf78db4070967869e4d027c11f4dd825d8f815a Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Thu, 22 Apr 2021 21:44:19 +0200 +Subject: futex: Do not apply time namespace adjustment on FUTEX_LOCK_PI + +From: Thomas Gleixner + +commit cdf78db4070967869e4d027c11f4dd825d8f815a upstream. + +FUTEX_LOCK_PI does not require to have the FUTEX_CLOCK_REALTIME bit set +because it has been using CLOCK_REALTIME based absolute timeouts +forever. Due to that, the time namespace adjustment which is applied when +FUTEX_CLOCK_REALTIME is not set, will wrongly take place for FUTEX_LOCK_PI +and wreckage the timeout. + +Exclude it from that procedure. + +Fixes: c2f7d08cccf4 ("futex: Adjust absolute futex timeouts with per time namespace offset") +Signed-off-by: Thomas Gleixner +Acked-by: Peter Zijlstra (Intel) +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20210422194704.984540159@linutronix.de +Signed-off-by: Greg Kroah-Hartman +--- + kernel/futex.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/kernel/futex.c ++++ b/kernel/futex.c +@@ -3782,7 +3782,7 @@ SYSCALL_DEFINE6(futex, u32 __user *, uad + t = timespec64_to_ktime(ts); + if (cmd == FUTEX_WAIT) + t = ktime_add_safe(ktime_get(), t); +- else if (!(op & FUTEX_CLOCK_REALTIME)) ++ else if (cmd != FUTEX_LOCK_PI && !(op & FUTEX_CLOCK_REALTIME)) + t = timens_ktime_to_host(CLOCK_MONOTONIC, t); + tp = &t; + } +@@ -3976,7 +3976,7 @@ SYSCALL_DEFINE6(futex_time32, u32 __user + t = timespec64_to_ktime(ts); + if (cmd == FUTEX_WAIT) + t = ktime_add_safe(ktime_get(), t); +- else if (!(op & FUTEX_CLOCK_REALTIME)) ++ else if (cmd != FUTEX_LOCK_PI && !(op & FUTEX_CLOCK_REALTIME)) + t = timens_ktime_to_host(CLOCK_MONOTONIC, t); + tp = &t; + } diff --git a/queue-5.11/jffs2-check-the-validity-of-dstlen-in-jffs2_zlib_compress.patch b/queue-5.11/jffs2-check-the-validity-of-dstlen-in-jffs2_zlib_compress.patch new file mode 100644 index 00000000000..7fcc90d2fb4 --- /dev/null +++ b/queue-5.11/jffs2-check-the-validity-of-dstlen-in-jffs2_zlib_compress.patch @@ -0,0 +1,103 @@ +From 90ada91f4610c5ef11bc52576516d96c496fc3f1 Mon Sep 17 00:00:00 2001 +From: Yang Yang +Date: Thu, 28 Jan 2021 02:55:35 -0800 +Subject: jffs2: check the validity of dstlen in jffs2_zlib_compress() + +From: Yang Yang + +commit 90ada91f4610c5ef11bc52576516d96c496fc3f1 upstream. + +KASAN reports a BUG when download file in jffs2 filesystem.It is +because when dstlen == 1, cpage_out will write array out of bounds. +Actually, data will not be compressed in jffs2_zlib_compress() if +data's length less than 4. + +[ 393.799778] BUG: KASAN: slab-out-of-bounds in jffs2_rtime_compress+0x214/0x2f0 at addr ffff800062e3b281 +[ 393.809166] Write of size 1 by task tftp/2918 +[ 393.813526] CPU: 3 PID: 2918 Comm: tftp Tainted: G B 4.9.115-rt93-EMBSYS-CGEL-6.1.R6-dirty #1 +[ 393.823173] Hardware name: LS1043A RDB Board (DT) +[ 393.827870] Call trace: +[ 393.830322] [] dump_backtrace+0x0/0x2f0 +[ 393.835721] [] show_stack+0x14/0x20 +[ 393.840774] [] dump_stack+0x90/0xb0 +[ 393.845829] [] kasan_object_err+0x24/0x80 +[ 393.851402] [] kasan_report_error+0x1b4/0x4d8 +[ 393.857323] [] kasan_report+0x38/0x40 +[ 393.862548] [] __asan_store1+0x4c/0x58 +[ 393.867859] [] jffs2_rtime_compress+0x214/0x2f0 +[ 393.873955] [] jffs2_selected_compress+0x178/0x2a0 +[ 393.880308] [] jffs2_compress+0x58/0x478 +[ 393.885796] [] jffs2_write_inode_range+0x13c/0x450 +[ 393.892150] [] jffs2_write_end+0x2a8/0x4a0 +[ 393.897811] [] generic_perform_write+0x1c0/0x280 +[ 393.903990] [] __generic_file_write_iter+0x1c4/0x228 +[ 393.910517] [] generic_file_write_iter+0x138/0x288 +[ 393.916870] [] __vfs_write+0x1b4/0x238 +[ 393.922181] [] vfs_write+0xd0/0x238 +[ 393.927232] [] SyS_write+0xa0/0x110 +[ 393.932283] [] __sys_trace_return+0x0/0x4 +[ 393.937851] Object at ffff800062e3b280, in cache kmalloc-64 size: 64 +[ 393.944197] Allocated: +[ 393.946552] PID = 2918 +[ 393.948913] save_stack_trace_tsk+0x0/0x220 +[ 393.953096] save_stack_trace+0x18/0x20 +[ 393.956932] kasan_kmalloc+0xd8/0x188 +[ 393.960594] __kmalloc+0x144/0x238 +[ 393.963994] jffs2_selected_compress+0x48/0x2a0 +[ 393.968524] jffs2_compress+0x58/0x478 +[ 393.972273] jffs2_write_inode_range+0x13c/0x450 +[ 393.976889] jffs2_write_end+0x2a8/0x4a0 +[ 393.980810] generic_perform_write+0x1c0/0x280 +[ 393.985251] __generic_file_write_iter+0x1c4/0x228 +[ 393.990040] generic_file_write_iter+0x138/0x288 +[ 393.994655] __vfs_write+0x1b4/0x238 +[ 393.998228] vfs_write+0xd0/0x238 +[ 394.001543] SyS_write+0xa0/0x110 +[ 394.004856] __sys_trace_return+0x0/0x4 +[ 394.008684] Freed: +[ 394.010691] PID = 2918 +[ 394.013051] save_stack_trace_tsk+0x0/0x220 +[ 394.017233] save_stack_trace+0x18/0x20 +[ 394.021069] kasan_slab_free+0x88/0x188 +[ 394.024902] kfree+0x6c/0x1d8 +[ 394.027868] jffs2_sum_write_sumnode+0x2c4/0x880 +[ 394.032486] jffs2_do_reserve_space+0x198/0x598 +[ 394.037016] jffs2_reserve_space+0x3f8/0x4d8 +[ 394.041286] jffs2_write_inode_range+0xf0/0x450 +[ 394.045816] jffs2_write_end+0x2a8/0x4a0 +[ 394.049737] generic_perform_write+0x1c0/0x280 +[ 394.054179] __generic_file_write_iter+0x1c4/0x228 +[ 394.058968] generic_file_write_iter+0x138/0x288 +[ 394.063583] __vfs_write+0x1b4/0x238 +[ 394.067157] vfs_write+0xd0/0x238 +[ 394.070470] SyS_write+0xa0/0x110 +[ 394.073783] __sys_trace_return+0x0/0x4 +[ 394.077612] Memory state around the buggy address: +[ 394.082404] ffff800062e3b180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc +[ 394.089623] ffff800062e3b200: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc +[ 394.096842] >ffff800062e3b280: 01 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc +[ 394.104056] ^ +[ 394.107283] ffff800062e3b300: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc +[ 394.114502] ffff800062e3b380: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc +[ 394.121718] ================================================================== + +Signed-off-by: Yang Yang +Cc: Joel Stanley +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman +--- + fs/jffs2/compr_rtime.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/fs/jffs2/compr_rtime.c ++++ b/fs/jffs2/compr_rtime.c +@@ -37,6 +37,9 @@ static int jffs2_rtime_compress(unsigned + int outpos = 0; + int pos=0; + ++ if (*dstlen <= 3) ++ return -1; ++ + memset(positions,0,sizeof(positions)); + + while (pos < (*sourcelen) && outpos <= (*dstlen)-2) { diff --git a/queue-5.11/revert-337f13046ff0-futex-allow-futex_clock_realtime-with-futex_wait-op.patch b/queue-5.11/revert-337f13046ff0-futex-allow-futex_clock_realtime-with-futex_wait-op.patch new file mode 100644 index 00000000000..c054f83a716 --- /dev/null +++ b/queue-5.11/revert-337f13046ff0-futex-allow-futex_clock_realtime-with-futex_wait-op.patch @@ -0,0 +1,46 @@ +From 4fbf5d6837bf81fd7a27d771358f4ee6c4f243f8 Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Thu, 22 Apr 2021 21:44:18 +0200 +Subject: Revert 337f13046ff0 ("futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op") + +From: Thomas Gleixner + +commit 4fbf5d6837bf81fd7a27d771358f4ee6c4f243f8 upstream. + +The FUTEX_WAIT operand has historically a relative timeout which means that +the clock id is irrelevant as relative timeouts on CLOCK_REALTIME are not +subject to wall clock changes and therefore are mapped by the kernel to +CLOCK_MONOTONIC for simplicity. + +If a caller would set FUTEX_CLOCK_REALTIME for FUTEX_WAIT the timeout is +still treated relative vs. CLOCK_MONOTONIC and then the wait arms that +timeout based on CLOCK_REALTIME which is broken and obviously has never +been used or even tested. + +Reject any attempt to use FUTEX_CLOCK_REALTIME with FUTEX_WAIT again. + +The desired functionality can be achieved with FUTEX_WAIT_BITSET and a +FUTEX_BITSET_MATCH_ANY argument. + +Fixes: 337f13046ff0 ("futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op") +Signed-off-by: Thomas Gleixner +Acked-by: Peter Zijlstra (Intel) +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20210422194704.834797921@linutronix.de +Signed-off-by: Greg Kroah-Hartman +--- + kernel/futex.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/kernel/futex.c ++++ b/kernel/futex.c +@@ -3712,8 +3712,7 @@ long do_futex(u32 __user *uaddr, int op, + + if (op & FUTEX_CLOCK_REALTIME) { + flags |= FLAGS_CLOCKRT; +- if (cmd != FUTEX_WAIT && cmd != FUTEX_WAIT_BITSET && \ +- cmd != FUTEX_WAIT_REQUEUE_PI) ++ if (cmd != FUTEX_WAIT_BITSET && cmd != FUTEX_WAIT_REQUEUE_PI) + return -ENOSYS; + } + diff --git a/queue-5.11/series b/queue-5.11/series index f77a4b06f2a..397b9d07cf9 100644 --- a/queue-5.11/series +++ b/queue-5.11/series @@ -294,3 +294,10 @@ sfc-farch-fix-tx-queue-lookup-in-tx-event-handling.patch rcu-nocb-fix-missed-nocb_timer-requeue.patch security-commoncap-fix-wstringop-overread-warning.patch fix-misc-new-gcc-warnings.patch +jffs2-check-the-validity-of-dstlen-in-jffs2_zlib_compress.patch +smb3-when-mounting-with-multichannel-include-it-in-requested-capabilities.patch +smb3-if-max_channels-set-to-more-than-one-channel-request-multichannel.patch +smb3-do-not-attempt-multichannel-to-server-which-does-not-support-it.patch +revert-337f13046ff0-futex-allow-futex_clock_realtime-with-futex_wait-op.patch +futex-do-not-apply-time-namespace-adjustment-on-futex_lock_pi.patch +x86-cpu-initialize-msr_tsc_aux-if-rdtscp-or-rdpid-is-supported.patch diff --git a/queue-5.11/smb3-do-not-attempt-multichannel-to-server-which-does-not-support-it.patch b/queue-5.11/smb3-do-not-attempt-multichannel-to-server-which-does-not-support-it.patch new file mode 100644 index 00000000000..af53cff55ca --- /dev/null +++ b/queue-5.11/smb3-do-not-attempt-multichannel-to-server-which-does-not-support-it.patch @@ -0,0 +1,38 @@ +From 9c2dc11df50d1c8537075ff6b98472198e24438e Mon Sep 17 00:00:00 2001 +From: Steve French +Date: Fri, 7 May 2021 20:00:41 -0500 +Subject: smb3: do not attempt multichannel to server which does not support it + +From: Steve French + +commit 9c2dc11df50d1c8537075ff6b98472198e24438e upstream. + +We were ignoring CAP_MULTI_CHANNEL in the server response - if the +server doesn't support multichannel we should not be attempting it. + +See MS-SMB2 section 3.2.5.2 + +Reviewed-by: Shyam Prasad N +Reviewed-By: Tom Talpey +Cc: # v5.8+ +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + fs/cifs/sess.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/fs/cifs/sess.c ++++ b/fs/cifs/sess.c +@@ -97,6 +97,12 @@ int cifs_try_adding_channels(struct cifs + return 0; + } + ++ if (!(ses->server->capabilities & SMB2_GLOBAL_CAP_MULTI_CHANNEL)) { ++ cifs_dbg(VFS, "server %s does not support multichannel\n", ses->server->hostname); ++ ses->chan_max = 1; ++ return 0; ++ } ++ + /* + * Make a copy of the iface list at the time and use that + * instead so as to not hold the iface spinlock for opening diff --git a/queue-5.11/smb3-if-max_channels-set-to-more-than-one-channel-request-multichannel.patch b/queue-5.11/smb3-if-max_channels-set-to-more-than-one-channel-request-multichannel.patch new file mode 100644 index 00000000000..2000983414e --- /dev/null +++ b/queue-5.11/smb3-if-max_channels-set-to-more-than-one-channel-request-multichannel.patch @@ -0,0 +1,36 @@ +From c1f8a398b6d661b594556a91224b096d92293061 Mon Sep 17 00:00:00 2001 +From: Steve French +Date: Fri, 7 May 2021 19:33:51 -0500 +Subject: smb3: if max_channels set to more than one channel request multichannel + +From: Steve French + +commit c1f8a398b6d661b594556a91224b096d92293061 upstream. + +Mounting with "multichannel" is obviously implied if user requested +more than one channel on mount (ie mount parm max_channels>1). +Currently both have to be specified. Fix that so that if max_channels +is greater than 1 on mount, enable multichannel rather than silently +falling back to non-multichannel. + +Signed-off-by: Steve French +Reviewed-By: Tom Talpey +Cc: # v5.11+ +Reviewed-by: Shyam Prasad N +Signed-off-by: Greg Kroah-Hartman +--- + fs/cifs/fs_context.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/fs/cifs/fs_context.c ++++ b/fs/cifs/fs_context.c +@@ -978,6 +978,9 @@ static int smb3_fs_context_parse_param(s + goto cifs_parse_mount_err; + } + ctx->max_channels = result.uint_32; ++ /* If more than one channel requested ... they want multichan */ ++ if (result.uint_32 > 1) ++ ctx->multichannel = true; + break; + case Opt_handletimeout: + ctx->handle_timeout = result.uint_32; diff --git a/queue-5.11/smb3-when-mounting-with-multichannel-include-it-in-requested-capabilities.patch b/queue-5.11/smb3-when-mounting-with-multichannel-include-it-in-requested-capabilities.patch new file mode 100644 index 00000000000..ab2d99f471f --- /dev/null +++ b/queue-5.11/smb3-when-mounting-with-multichannel-include-it-in-requested-capabilities.patch @@ -0,0 +1,47 @@ +From 679971e7213174efb56abc8fab1299d0a88db0e8 Mon Sep 17 00:00:00 2001 +From: Steve French +Date: Fri, 7 May 2021 18:24:11 -0500 +Subject: smb3: when mounting with multichannel include it in requested capabilities + +From: Steve French + +commit 679971e7213174efb56abc8fab1299d0a88db0e8 upstream. + +In the SMB3/SMB3.1.1 negotiate protocol request, we are supposed to +advertise CAP_MULTICHANNEL capability when establishing multiple +channels has been requested by the user doing the mount. See MS-SMB2 +sections 2.2.3 and 3.2.5.2 + +Without setting it there is some risk that multichannel could fail +if the server interpreted the field strictly. + +Reviewed-By: Tom Talpey +Reviewed-by: Shyam Prasad N +Cc: # v5.8+ +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + fs/cifs/smb2pdu.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/fs/cifs/smb2pdu.c ++++ b/fs/cifs/smb2pdu.c +@@ -840,6 +840,8 @@ SMB2_negotiate(const unsigned int xid, s + req->SecurityMode = 0; + + req->Capabilities = cpu_to_le32(server->vals->req_capabilities); ++ if (ses->chan_max > 1) ++ req->Capabilities |= cpu_to_le32(SMB2_GLOBAL_CAP_MULTI_CHANNEL); + + /* ClientGUID must be zero for SMB2.02 dialect */ + if (server->vals->protocol_id == SMB20_PROT_ID) +@@ -1025,6 +1027,9 @@ int smb3_validate_negotiate(const unsign + + pneg_inbuf->Capabilities = + cpu_to_le32(server->vals->req_capabilities); ++ if (tcon->ses->chan_max > 1) ++ pneg_inbuf->Capabilities |= cpu_to_le32(SMB2_GLOBAL_CAP_MULTI_CHANNEL); ++ + memcpy(pneg_inbuf->Guid, server->client_guid, + SMB2_CLIENT_GUID_SIZE); + diff --git a/queue-5.11/x86-cpu-initialize-msr_tsc_aux-if-rdtscp-or-rdpid-is-supported.patch b/queue-5.11/x86-cpu-initialize-msr_tsc_aux-if-rdtscp-or-rdpid-is-supported.patch new file mode 100644 index 00000000000..569be2db4db --- /dev/null +++ b/queue-5.11/x86-cpu-initialize-msr_tsc_aux-if-rdtscp-or-rdpid-is-supported.patch @@ -0,0 +1,43 @@ +From b6b4fbd90b155a0025223df2c137af8a701d53b3 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Tue, 4 May 2021 15:56:31 -0700 +Subject: x86/cpu: Initialize MSR_TSC_AUX if RDTSCP *or* RDPID is supported + +From: Sean Christopherson + +commit b6b4fbd90b155a0025223df2c137af8a701d53b3 upstream. + +Initialize MSR_TSC_AUX with CPU node information if RDTSCP or RDPID is +supported. This fixes a bug where vdso_read_cpunode() will read garbage +via RDPID if RDPID is supported but RDTSCP is not. While no known CPU +supports RDPID but not RDTSCP, both Intel's SDM and AMD's APM allow for +RDPID to exist without RDTSCP, e.g. it's technically a legal CPU model +for a virtual machine. + +Note, technically MSR_TSC_AUX could be initialized if and only if RDPID +is supported since RDTSCP is currently not used to retrieve the CPU node. +But, the cost of the superfluous WRMSR is negigible, whereas leaving +MSR_TSC_AUX uninitialized is just asking for future breakage if someone +decides to utilize RDTSCP. + +Fixes: a582c540ac1b ("x86/vdso: Use RDPID in preference to LSL when available") +Signed-off-by: Sean Christopherson +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20210504225632.1532621-2-seanjc@google.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/cpu/common.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kernel/cpu/common.c ++++ b/arch/x86/kernel/cpu/common.c +@@ -1847,7 +1847,7 @@ static inline void setup_getcpu(int cpu) + unsigned long cpudata = vdso_encode_cpunode(cpu, early_cpu_to_node(cpu)); + struct desc_struct d = { }; + +- if (boot_cpu_has(X86_FEATURE_RDTSCP)) ++ if (boot_cpu_has(X86_FEATURE_RDTSCP) || boot_cpu_has(X86_FEATURE_RDPID)) + write_rdtscp_aux(cpudata); + + /* Store CPU and node number in limit. */