From: Greg Kroah-Hartman Date: Mon, 10 May 2021 07:56:03 +0000 (+0200) Subject: 5.4-stable patches X-Git-Tag: v5.4.118~25 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=1031c1124ea4310f456239f9af9dd5075be9b875;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: jffs2-check-the-validity-of-dstlen-in-jffs2_zlib_compress.patch revert-337f13046ff0-futex-allow-futex_clock_realtime-with-futex_wait-op.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.4/jffs2-check-the-validity-of-dstlen-in-jffs2_zlib_compress.patch b/queue-5.4/jffs2-check-the-validity-of-dstlen-in-jffs2_zlib_compress.patch new file mode 100644 index 00000000000..7fcc90d2fb4 --- /dev/null +++ b/queue-5.4/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.4/revert-337f13046ff0-futex-allow-futex_clock_realtime-with-futex_wait-op.patch b/queue-5.4/revert-337f13046ff0-futex-allow-futex_clock_realtime-with-futex_wait-op.patch new file mode 100644 index 00000000000..02c32ee6f3f --- /dev/null +++ b/queue-5.4/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 +@@ -3862,8 +3862,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.4/series b/queue-5.4/series index 34326adbbd5..0bdf88298f0 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -156,3 +156,7 @@ dm-raid-fix-inconclusive-reshape-layout-on-fast-raid4-5-6-table-reload-sequences fuse-fix-write-deadlock.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 +revert-337f13046ff0-futex-allow-futex_clock_realtime-with-futex_wait-op.patch +x86-cpu-initialize-msr_tsc_aux-if-rdtscp-or-rdpid-is-supported.patch diff --git a/queue-5.4/smb3-when-mounting-with-multichannel-include-it-in-requested-capabilities.patch b/queue-5.4/smb3-when-mounting-with-multichannel-include-it-in-requested-capabilities.patch new file mode 100644 index 00000000000..3fb0e78b586 --- /dev/null +++ b/queue-5.4/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 +@@ -869,6 +869,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) +@@ -1055,6 +1057,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.4/x86-cpu-initialize-msr_tsc_aux-if-rdtscp-or-rdpid-is-supported.patch b/queue-5.4/x86-cpu-initialize-msr_tsc_aux-if-rdtscp-or-rdpid-is-supported.patch new file mode 100644 index 00000000000..412504fb42c --- /dev/null +++ b/queue-5.4/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 +@@ -1826,7 +1826,7 @@ static 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. */