linux-stable.git/fs/jffs2, branch linux-5.11.y

jffs2: check the validity of dstlen in jffs2_zlib_compress()

2021-05-12T06:37:35+00:00

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

jffs2: Hook up splice_write callback

2021-05-12T06:37:33+00:00

commit 42984af09afc414d540fcc8247f42894b0378a91 upstream.

overlayfs using jffs2 as the upper filesystem would fail in some cases
since moving to v5.10. The test case used was to run 'touch' on a file
that exists in the lower fs, causing the modification time to be
updated. It returns EINVAL when the bug is triggered.

A bisection showed this was introduced in v5.9-rc1, with commit
36e2c7421f02 ("fs: don't allow splice read/write without explicit ops").
Reverting that commit restores the expected behaviour.

Some digging showed that this was due to jffs2 lacking an implementation
of splice_write. (For unknown reasons the warn_unsupported that should
trigger was not displaying any output).

Adding this patch resolved the issue and the test now passes.

Cc: stable@vger.kernel.org
Fixes: 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops")
Signed-off-by: Joel Stanley 
Reviewed-by: Christoph Hellwig 
Tested-by: Lei YU 
Signed-off-by: Richard Weinberger 
Signed-off-by: Greg Kroah-Hartman

jffs2: Fix kasan slab-out-of-bounds problem

2021-05-12T06:37:33+00:00

commit 960b9a8a7676b9054d8b46a2c7db52a0c8766b56 upstream.

KASAN report a slab-out-of-bounds problem. The logs are listed below.
It is because in function jffs2_scan_dirent_node, we alloc "checkedlen+1"
bytes for fd->name and we check crc with length rd->nsize. If checkedlen
is less than rd->nsize, it will cause the slab-out-of-bounds problem.

jffs2: Dirent at *** has zeroes in name. Truncating to %d char
==================================================================
BUG: KASAN: slab-out-of-bounds in crc32_le+0x1ce/0x260 at addr ffff8800842cf2d1
Read of size 1 by task test_JFFS2/915
=============================================================================
BUG kmalloc-64 (Tainted: G    B      O   ): kasan: bad access detected
-----------------------------------------------------------------------------
INFO: Allocated in jffs2_alloc_full_dirent+0x2a/0x40 age=0 cpu=1 pid=915
	___slab_alloc+0x580/0x5f0
	__slab_alloc.isra.24+0x4e/0x64
	__kmalloc+0x170/0x300
	jffs2_alloc_full_dirent+0x2a/0x40
	jffs2_scan_eraseblock+0x1ca4/0x3b64
	jffs2_scan_medium+0x285/0xfe0
	jffs2_do_mount_fs+0x5fb/0x1bbc
	jffs2_do_fill_super+0x245/0x6f0
	jffs2_fill_super+0x287/0x2e0
	mount_mtd_aux.isra.0+0x9a/0x144
	mount_mtd+0x222/0x2f0
	jffs2_mount+0x41/0x60
	mount_fs+0x63/0x230
	vfs_kern_mount.part.6+0x6c/0x1f4
	do_mount+0xae8/0x1940
	SyS_mount+0x105/0x1d0
INFO: Freed in jffs2_free_full_dirent+0x22/0x40 age=27 cpu=1 pid=915
	__slab_free+0x372/0x4e4
	kfree+0x1d4/0x20c
	jffs2_free_full_dirent+0x22/0x40
	jffs2_build_remove_unlinked_inode+0x17a/0x1e4
	jffs2_do_mount_fs+0x1646/0x1bbc
	jffs2_do_fill_super+0x245/0x6f0
	jffs2_fill_super+0x287/0x2e0
	mount_mtd_aux.isra.0+0x9a/0x144
	mount_mtd+0x222/0x2f0
	jffs2_mount+0x41/0x60
	mount_fs+0x63/0x230
	vfs_kern_mount.part.6+0x6c/0x1f4
	do_mount+0xae8/0x1940
	SyS_mount+0x105/0x1d0
	entry_SYSCALL_64_fastpath+0x1e/0x97
Call Trace:
 [] dump_stack+0x59/0x7e
 [] print_trailer+0x125/0x1b0
 [] object_err+0x34/0x40
 [] kasan_report.part.1+0x21f/0x534
 [] ? vprintk+0x2d/0x40
 [] ? crc32_le+0x1ce/0x260
 [] kasan_report+0x26/0x30
 [] __asan_load1+0x3d/0x50
 [] crc32_le+0x1ce/0x260
 [] ? jffs2_alloc_full_dirent+0x2a/0x40
 [] jffs2_scan_eraseblock+0x1d0c/0x3b64
 [] ? jffs2_scan_medium+0xccf/0xfe0
 [] ? jffs2_scan_make_ino_cache+0x14c/0x14c
 [] ? kasan_unpoison_shadow+0x35/0x50
 [] ? kasan_unpoison_shadow+0x35/0x50
 [] ? kasan_kmalloc+0x5e/0x70
 [] ? kmem_cache_alloc_trace+0x10c/0x2cc
 [] ? mtd_point+0xf7/0x130
 [] jffs2_scan_medium+0x285/0xfe0
 [] ? jffs2_scan_eraseblock+0x3b64/0x3b64
 [] ? kasan_unpoison_shadow+0x35/0x50
 [] ? kasan_unpoison_shadow+0x35/0x50
 [] ? kasan_kmalloc+0x5e/0x70
 [] ? __kmalloc+0x12b/0x300
 [] ? kasan_kmalloc+0x5e/0x70
 [] ? jffs2_sum_init+0x9f/0x240
 [] jffs2_do_mount_fs+0x5fb/0x1bbc
 [] ? jffs2_del_noinode_dirent+0x640/0x640
 [] ? kasan_kmalloc+0x5e/0x70
 [] ? __init_rwsem+0x97/0xac
 [] jffs2_do_fill_super+0x245/0x6f0
 [] jffs2_fill_super+0x287/0x2e0
 [] ? jffs2_parse_options+0x594/0x594
 [] mount_mtd_aux.isra.0+0x9a/0x144
 [] mount_mtd+0x222/0x2f0
 [] ? jffs2_parse_options+0x594/0x594
 [] ? mount_mtd_aux.isra.0+0x144/0x144
 [] ? free_pages+0x13/0x1c
 [] ? selinux_sb_copy_data+0x278/0x2e0
 [] jffs2_mount+0x41/0x60
 [] mount_fs+0x63/0x230
 [] ? alloc_vfsmnt+0x32f/0x3b0
 [] vfs_kern_mount.part.6+0x6c/0x1f4
 [] do_mount+0xae8/0x1940
 [] ? audit_filter_rules.constprop.6+0x1d10/0x1d10
 [] ? copy_mount_string+0x40/0x40
 [] ? alloc_pages_current+0xa4/0x1bc
 [] ? __get_free_pages+0x25/0x50
 [] ? copy_mount_options.part.17+0x183/0x264
 [] SyS_mount+0x105/0x1d0
 [] ? copy_mnt_ns+0x560/0x560
 [] ? msa_space_switch_handler+0x13d/0x190
 [] entry_SYSCALL_64_fastpath+0x1e/0x97
 [] ? msa_space_switch+0xb0/0xe0
Memory state around the buggy address:
 ffff8800842cf180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff8800842cf200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff8800842cf280: fc fc fc fc fc fc 00 00 00 00 01 fc fc fc fc fc
                                                 ^
 ffff8800842cf300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff8800842cf380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================

Cc: stable@vger.kernel.org
Reported-by: Kunkun Xu 
Signed-off-by: lizhe 
Signed-off-by: Richard Weinberger 
Signed-off-by: Greg Kroah-Hartman

jffs2: fix use after free in jffs2_sum_write_data()

2021-03-04T11:14:28+00:00

[ Upstream commit 19646447ad3a680d2ab08c097585b7d96a66126b ]

clang static analysis reports this problem

fs/jffs2/summary.c:794:31: warning: Use of memory after it is freed
                c->summary->sum_list_head = temp->u.next;
                                            ^~~~~~~~~~~~

In jffs2_sum_write_data(), in a loop summary data is handles a node at
a time.  When it has written out the node it is removed the summary list,
and the node is deleted.  In the corner case when a
JFFS2_FEATURE_RWCOMPAT_COPY is seen, a call is made to
jffs2_sum_disable_collecting().  jffs2_sum_disable_collecting() deletes
the whole list which conflicts with the loop's deleting the list by parts.

To preserve the old behavior of stopping the write midway, bail out of
the loop after disabling summary collection.

Fixes: 6171586a7ae5 ("[JFFS2] Correct handling of JFFS2_FEATURE_RWCOMPAT_COPY nodes.")
Signed-off-by: Tom Rix 
Reviewed-by: Nathan Chancellor 
Signed-off-by: Richard Weinberger 
Signed-off-by: Sasha Levin

jffs2: Fix NULL pointer dereference in rp_size fs option parsing

2020-12-13T20:57:21+00:00

syzkaller found the following JFFS2 splat:

  Unable to handle kernel paging request at virtual address dfffa00000000001
  Mem abort info:
    ESR = 0x96000004
    EC = 0x25: DABT (current EL), IL = 32 bits
    SET = 0, FnV = 0
    EA = 0, S1PTW = 0
  Data abort info:
    ISV = 0, ISS = 0x00000004
    CM = 0, WnR = 0
  [dfffa00000000001] address between user and kernel address ranges
  Internal error: Oops: 96000004 [#1] SMP
  Dumping ftrace buffer:
     (ftrace buffer empty)
  Modules linked in:
  CPU: 0 PID: 12745 Comm: syz-executor.5 Tainted: G S                5.9.0-rc8+ #98
  Hardware name: linux,dummy-virt (DT)
  pstate: 20400005 (nzCv daif +PAN -UAO BTYPE=--)
  pc : jffs2_parse_param+0x138/0x308 fs/jffs2/super.c:206
  lr : jffs2_parse_param+0x108/0x308 fs/jffs2/super.c:205
  sp : ffff000022a57910
  x29: ffff000022a57910 x28: 0000000000000000
  x27: ffff000057634008 x26: 000000000000d800
  x25: 000000000000d800 x24: ffff0000271a9000
  x23: ffffa0001adb5dc0 x22: ffff000023fdcf00
  x21: 1fffe0000454af2c x20: ffff000024cc9400
  x19: 0000000000000000 x18: 0000000000000000
  x17: 0000000000000000 x16: ffffa000102dbdd0
  x15: 0000000000000000 x14: ffffa000109e44bc
  x13: ffffa00010a3a26c x12: ffff80000476e0b3
  x11: 1fffe0000476e0b2 x10: ffff80000476e0b2
  x9 : ffffa00010a3ad60 x8 : ffff000023b70593
  x7 : 0000000000000003 x6 : 00000000f1f1f1f1
  x5 : ffff000023fdcf00 x4 : 0000000000000002
  x3 : ffffa00010000000 x2 : 0000000000000001
  x1 : dfffa00000000000 x0 : 0000000000000008
  Call trace:
   jffs2_parse_param+0x138/0x308 fs/jffs2/super.c:206
   vfs_parse_fs_param+0x234/0x4e8 fs/fs_context.c:117
   vfs_parse_fs_string+0xe8/0x148 fs/fs_context.c:161
   generic_parse_monolithic+0x17c/0x208 fs/fs_context.c:201
   parse_monolithic_mount_data+0x7c/0xa8 fs/fs_context.c:649
   do_new_mount fs/namespace.c:2871 [inline]
   path_mount+0x548/0x1da8 fs/namespace.c:3192
   do_mount+0x124/0x138 fs/namespace.c:3205
   __do_sys_mount fs/namespace.c:3413 [inline]
   __se_sys_mount fs/namespace.c:3390 [inline]
   __arm64_sys_mount+0x164/0x238 fs/namespace.c:3390
   __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]
   invoke_syscall arch/arm64/kernel/syscall.c:48 [inline]
   el0_svc_common.constprop.0+0x15c/0x598 arch/arm64/kernel/syscall.c:149
   do_el0_svc+0x60/0x150 arch/arm64/kernel/syscall.c:195
   el0_svc+0x34/0xb0 arch/arm64/kernel/entry-common.c:226
   el0_sync_handler+0xc8/0x5b4 arch/arm64/kernel/entry-common.c:236
   el0_sync+0x15c/0x180 arch/arm64/kernel/entry.S:663
  Code: d2d40001 f2fbffe1 91002260 d343fc02 (38e16841)
  ---[ end trace 4edf690313deda44 ]---

This is because since ec10a24f10c8, the option parsing happens before
fill_super and so the MTD device isn't associated with the filesystem.
Defer the size check until there is a valid association.

Fixes: ec10a24f10c8 ("vfs: Convert jffs2 to use the new mount API")
Cc: 
Cc: David Howells 
Signed-off-by: Jamie Iles 
Signed-off-by: Richard Weinberger

jffs2: remove trailing semicolon in macro definition

2020-12-13T20:57:20+00:00

The macro use will already have a semicolon.

Signed-off-by: Tom Rix 
Signed-off-by: Richard Weinberger

jffs2: Allow setting rp_size to zero during remounting

2020-12-13T20:56:24+00:00

Set rp_size to zero will be ignore during remounting.

The method to identify whether we input a remounting option of
rp_size is to check if the rp_size input is zero. It can not work
well if we pass "rp_size=0".

This patch add a bool variable "set_rp_size" to fix this problem.

Reported-by: Jubin Zhong 
Signed-off-by: lizhe 
Signed-off-by: Richard Weinberger

jffs2: Fix ignoring mounting options problem during remounting

2020-12-13T20:55:59+00:00

The jffs2 mount options will be ignored when remounting jffs2.
It can be easily reproduced with the steps listed below.
1. mount -t jffs2 -o compr=none /dev/mtdblockx /mnt
2. mount -o remount compr=zlib /mnt

Since ec10a24f10c8, the option parsing happens before fill_super and
then pass fc, which contains the options parsing results, to function
jffs2_reconfigure during remounting. But function jffs2_reconfigure do
not update c->mount_opts.

This patch add a function jffs2_update_mount_opts to fix this problem.

By the way, I notice that tmpfs use the same way to update remounting
options. If it is necessary to unify them?

Cc: 
Fixes: ec10a24f10c8 ("vfs: Convert jffs2 to use the new mount API")
Signed-off-by: lizhe 
Signed-off-by: Richard Weinberger

jffs2: Fix GC exit abnormally

2020-12-13T20:55:39+00:00

The log of this problem is:
jffs2: Error garbage collecting node at 0x***!
jffs2: No space for garbage collection. Aborting GC thread

This is because GC believe that it do nothing, so it abort.

After going over the image of jffs2, I find a scene that
can trigger this problem stably.
The scene is: there is a normal dirent node at summary-area,
but abnormal at corresponding not-summary-area with error
name_crc.

The reason that GC exit abnormally is because it find that
abnormal dirent node to GC, but when it goes to function
jffs2_add_fd_to_list, it cannot meet the condition listed
below:

if ((*prev)->nhash == new->nhash && !strcmp((*prev)->name, new->name))

So no node is marked obsolete, statistical information of
erase_block do not change, which cause GC exit abnormally.

The root cause of this problem is: we do not check the
name_crc of the abnormal dirent node with summary is enabled.

Noticed that in function jffs2_scan_dirent_node, we use
function jffs2_scan_dirty_space to deal with the dirent
node with error name_crc. So this patch add a checking
code in function read_direntry to ensure the correctness
of dirent node. If checked failed, the dirent node will
be marked obsolete so GC will pass this node and this
problem will be fixed.

Cc: 
Signed-off-by: Zhe Li 
Signed-off-by: Richard Weinberger

jffs2: Fix if/else empty body warnings

2020-12-13T20:51:54+00:00

When debug (print) macros are not enabled, change them to use the
no_printk() macro instead of . This fixes gcc warnings when
-Wextra is used:

../fs/jffs2/nodelist.c:255:37: warning: suggest braces around empty body in an ‘else’ statement [-Wempty-body]
../fs/jffs2/nodelist.c:278:38: warning: suggest braces around empty body in an ‘else’ statement [-Wempty-body]
../fs/jffs2/nodelist.c:558:52: warning: suggest braces around empty body in an ‘else’ statement [-Wempty-body]
../fs/jffs2/xattr.c:1247:58: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
../fs/jffs2/xattr.c:1281:65: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]

Builds without warnings on all 3 levels of CONFIG_JFFS2_FS_DEBUG.

Signed-off-by: Randy Dunlap 
Cc: David Woodhouse 
Cc: Richard Weinberger 
Cc: linux-mtd@lists.infradead.org
Signed-off-by: Richard Weinberger