--- /dev/null
+From cdf78db4070967869e4d027c11f4dd825d8f815a Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Thu, 22 Apr 2021 21:44:19 +0200
+Subject: futex: Do not apply time namespace adjustment on FUTEX_LOCK_PI
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+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 <tglx@linutronix.de>
+Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20210422194704.984540159@linutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/futex.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/kernel/futex.c
++++ b/kernel/futex.c
+@@ -3784,7 +3784,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;
+ }
+@@ -3978,7 +3978,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;
+ }
--- /dev/null
+From 90ada91f4610c5ef11bc52576516d96c496fc3f1 Mon Sep 17 00:00:00 2001
+From: Yang Yang <yang.yang29@zte.com.cn>
+Date: Thu, 28 Jan 2021 02:55:35 -0800
+Subject: jffs2: check the validity of dstlen in jffs2_zlib_compress()
+
+From: Yang Yang <yang.yang29@zte.com.cn>
+
+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] [<ffff20000808c700>] dump_backtrace+0x0/0x2f0
+[ 393.835721] [<ffff20000808ca04>] show_stack+0x14/0x20
+[ 393.840774] [<ffff2000086ef700>] dump_stack+0x90/0xb0
+[ 393.845829] [<ffff20000827b19c>] kasan_object_err+0x24/0x80
+[ 393.851402] [<ffff20000827b404>] kasan_report_error+0x1b4/0x4d8
+[ 393.857323] [<ffff20000827bae8>] kasan_report+0x38/0x40
+[ 393.862548] [<ffff200008279d44>] __asan_store1+0x4c/0x58
+[ 393.867859] [<ffff2000084ce2ec>] jffs2_rtime_compress+0x214/0x2f0
+[ 393.873955] [<ffff2000084bb3b0>] jffs2_selected_compress+0x178/0x2a0
+[ 393.880308] [<ffff2000084bb530>] jffs2_compress+0x58/0x478
+[ 393.885796] [<ffff2000084c5b34>] jffs2_write_inode_range+0x13c/0x450
+[ 393.892150] [<ffff2000084be0b8>] jffs2_write_end+0x2a8/0x4a0
+[ 393.897811] [<ffff2000081f3008>] generic_perform_write+0x1c0/0x280
+[ 393.903990] [<ffff2000081f5074>] __generic_file_write_iter+0x1c4/0x228
+[ 393.910517] [<ffff2000081f5210>] generic_file_write_iter+0x138/0x288
+[ 393.916870] [<ffff20000829ec1c>] __vfs_write+0x1b4/0x238
+[ 393.922181] [<ffff20000829ff00>] vfs_write+0xd0/0x238
+[ 393.927232] [<ffff2000082a1ba8>] SyS_write+0xa0/0x110
+[ 393.932283] [<ffff20000808429c>] __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 <yang.yang29@zte.com.cn>
+Cc: Joel Stanley <joel@jms.id.au>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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) {
--- /dev/null
+From 4fbf5d6837bf81fd7a27d771358f4ee6c4f243f8 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Thu, 22 Apr 2021 21:44:18 +0200
+Subject: Revert 337f13046ff0 ("futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op")
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+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 <tglx@linutronix.de>
+Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20210422194704.834797921@linutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/futex.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/kernel/futex.c
++++ b/kernel/futex.c
+@@ -3714,8 +3714,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;
+ }
+
sfc-farch-fix-tx-queue-lookup-in-tx-event-handling.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-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
--- /dev/null
+From 9c2dc11df50d1c8537075ff6b98472198e24438e Mon Sep 17 00:00:00 2001
+From: Steve French <stfrench@microsoft.com>
+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 <stfrench@microsoft.com>
+
+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 <sprasad@microsoft.com>
+Reviewed-By: Tom Talpey <tom@talpey.com>
+Cc: <stable@vger.kernel.org> # v5.8+
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/cifs/sess.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/fs/cifs/sess.c
++++ b/fs/cifs/sess.c
+@@ -92,6 +92,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
--- /dev/null
+From 679971e7213174efb56abc8fab1299d0a88db0e8 Mon Sep 17 00:00:00 2001
+From: Steve French <stfrench@microsoft.com>
+Date: Fri, 7 May 2021 18:24:11 -0500
+Subject: smb3: when mounting with multichannel include it in requested capabilities
+
+From: Steve French <stfrench@microsoft.com>
+
+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 <tom@talpey.com>
+Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
+Cc: <stable@vger.kernel.org> # v5.8+
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+
--- /dev/null
+From b6b4fbd90b155a0025223df2c137af8a701d53b3 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+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 <seanjc@google.com>
+
+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 <seanjc@google.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20210504225632.1532621-2-seanjc@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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. */
projects / thirdparty / kernel / stable-queue.git / commitdiff
