From 265667a799eb9f6792b5e2e5a11eee81ed7b9ba8 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 10 May 2021 09:55:16 +0200 Subject: [PATCH] 4.9-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 --- ...ity-of-dstlen-in-jffs2_zlib_compress.patch | 103 ++++++++++++++++++ ...ex_clock_realtime-with-futex_wait-op.patch | 46 ++++++++ queue-4.9/series | 2 + 3 files changed, 151 insertions(+) create mode 100644 queue-4.9/jffs2-check-the-validity-of-dstlen-in-jffs2_zlib_compress.patch create mode 100644 queue-4.9/revert-337f13046ff0-futex-allow-futex_clock_realtime-with-futex_wait-op.patch diff --git a/queue-4.9/jffs2-check-the-validity-of-dstlen-in-jffs2_zlib_compress.patch b/queue-4.9/jffs2-check-the-validity-of-dstlen-in-jffs2_zlib_compress.patch new file mode 100644 index 00000000000..7fcc90d2fb4 --- /dev/null +++ b/queue-4.9/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-4.9/revert-337f13046ff0-futex-allow-futex_clock_realtime-with-futex_wait-op.patch b/queue-4.9/revert-337f13046ff0-futex-allow-futex_clock_realtime-with-futex_wait-op.patch new file mode 100644 index 00000000000..41c10aa03ec --- /dev/null +++ b/queue-4.9/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 +@@ -3860,8 +3860,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-4.9/series b/queue-4.9/series index d0461bc4942..a20d16a21c5 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -53,3 +53,5 @@ nfsv4-don-t-discard-segments-marked-for-return-in-_pnfs_return_layout.patch jffs2-fix-kasan-slab-out-of-bounds-problem.patch powerpc-eeh-fix-eeh-handling-for-hugepages-in-ioremap-space.patch powerpc-fix-edeadlock-redefinition-error-in-uapi-asm-errno.h.patch +jffs2-check-the-validity-of-dstlen-in-jffs2_zlib_compress.patch +revert-337f13046ff0-futex-allow-futex_clock_realtime-with-futex_wait-op.patch -- 2.47.3