<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/fs/jffs2, branch linux-4.4.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.4.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.4.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2021-05-22T08:38:19Z</updated>
<entry>
<title>jffs2: check the validity of dstlen in jffs2_zlib_compress()</title>
<updated>2021-05-22T08:38:19Z</updated>
<author>
<name>Yang Yang</name>
</author>
<published>2021-01-28T10:55:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b846e5b7fafddea690d6a0d69b71adcaa5a2beab'/>
<id>urn:sha1:b846e5b7fafddea690d6a0d69b71adcaa5a2beab</id>
<content type='text'>
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] [&lt;ffff20000808c700&gt;] dump_backtrace+0x0/0x2f0
[  393.835721] [&lt;ffff20000808ca04&gt;] show_stack+0x14/0x20
[  393.840774] [&lt;ffff2000086ef700&gt;] dump_stack+0x90/0xb0
[  393.845829] [&lt;ffff20000827b19c&gt;] kasan_object_err+0x24/0x80
[  393.851402] [&lt;ffff20000827b404&gt;] kasan_report_error+0x1b4/0x4d8
[  393.857323] [&lt;ffff20000827bae8&gt;] kasan_report+0x38/0x40
[  393.862548] [&lt;ffff200008279d44&gt;] __asan_store1+0x4c/0x58
[  393.867859] [&lt;ffff2000084ce2ec&gt;] jffs2_rtime_compress+0x214/0x2f0
[  393.873955] [&lt;ffff2000084bb3b0&gt;] jffs2_selected_compress+0x178/0x2a0
[  393.880308] [&lt;ffff2000084bb530&gt;] jffs2_compress+0x58/0x478
[  393.885796] [&lt;ffff2000084c5b34&gt;] jffs2_write_inode_range+0x13c/0x450
[  393.892150] [&lt;ffff2000084be0b8&gt;] jffs2_write_end+0x2a8/0x4a0
[  393.897811] [&lt;ffff2000081f3008&gt;] generic_perform_write+0x1c0/0x280
[  393.903990] [&lt;ffff2000081f5074&gt;] __generic_file_write_iter+0x1c4/0x228
[  393.910517] [&lt;ffff2000081f5210&gt;] generic_file_write_iter+0x138/0x288
[  393.916870] [&lt;ffff20000829ec1c&gt;] __vfs_write+0x1b4/0x238
[  393.922181] [&lt;ffff20000829ff00&gt;] vfs_write+0xd0/0x238
[  393.927232] [&lt;ffff2000082a1ba8&gt;] SyS_write+0xa0/0x110
[  393.932283] [&lt;ffff20000808429c&gt;] __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] &gt;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 &lt;yang.yang29@zte.com.cn&gt;
Cc: Joel Stanley &lt;joel@jms.id.au&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>jffs2: Fix kasan slab-out-of-bounds problem</title>
<updated>2021-05-22T08:38:19Z</updated>
<author>
<name>lizhe</name>
</author>
<published>2021-03-18T03:06:57Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8a86df43fe1524e91c6df35d339962afa4ec53b9'/>
<id>urn:sha1:8a86df43fe1524e91c6df35d339962afa4ec53b9</id>
<content type='text'>
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-&gt;name and we check crc with length rd-&gt;nsize. If checkedlen
is less than rd-&gt;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:
 [&lt;ffffffff815befef&gt;] dump_stack+0x59/0x7e
 [&lt;ffffffff812d1d65&gt;] print_trailer+0x125/0x1b0
 [&lt;ffffffff812d82c8&gt;] object_err+0x34/0x40
 [&lt;ffffffff812dadef&gt;] kasan_report.part.1+0x21f/0x534
 [&lt;ffffffff81132401&gt;] ? vprintk+0x2d/0x40
 [&lt;ffffffff815f1ee2&gt;] ? crc32_le+0x1ce/0x260
 [&lt;ffffffff812db41a&gt;] kasan_report+0x26/0x30
 [&lt;ffffffff812d9fc1&gt;] __asan_load1+0x3d/0x50
 [&lt;ffffffff815f1ee2&gt;] crc32_le+0x1ce/0x260
 [&lt;ffffffff814764ae&gt;] ? jffs2_alloc_full_dirent+0x2a/0x40
 [&lt;ffffffff81485cec&gt;] jffs2_scan_eraseblock+0x1d0c/0x3b64
 [&lt;ffffffff81488813&gt;] ? jffs2_scan_medium+0xccf/0xfe0
 [&lt;ffffffff81483fe0&gt;] ? jffs2_scan_make_ino_cache+0x14c/0x14c
 [&lt;ffffffff812da3e9&gt;] ? kasan_unpoison_shadow+0x35/0x50
 [&lt;ffffffff812da3e9&gt;] ? kasan_unpoison_shadow+0x35/0x50
 [&lt;ffffffff812da462&gt;] ? kasan_kmalloc+0x5e/0x70
 [&lt;ffffffff812d5d90&gt;] ? kmem_cache_alloc_trace+0x10c/0x2cc
 [&lt;ffffffff818169fb&gt;] ? mtd_point+0xf7/0x130
 [&lt;ffffffff81487dc9&gt;] jffs2_scan_medium+0x285/0xfe0
 [&lt;ffffffff81487b44&gt;] ? jffs2_scan_eraseblock+0x3b64/0x3b64
 [&lt;ffffffff812da3e9&gt;] ? kasan_unpoison_shadow+0x35/0x50
 [&lt;ffffffff812da3e9&gt;] ? kasan_unpoison_shadow+0x35/0x50
 [&lt;ffffffff812da462&gt;] ? kasan_kmalloc+0x5e/0x70
 [&lt;ffffffff812d57df&gt;] ? __kmalloc+0x12b/0x300
 [&lt;ffffffff812da462&gt;] ? kasan_kmalloc+0x5e/0x70
 [&lt;ffffffff814a2753&gt;] ? jffs2_sum_init+0x9f/0x240
 [&lt;ffffffff8148b2ff&gt;] jffs2_do_mount_fs+0x5fb/0x1bbc
 [&lt;ffffffff8148ad04&gt;] ? jffs2_del_noinode_dirent+0x640/0x640
 [&lt;ffffffff812da462&gt;] ? kasan_kmalloc+0x5e/0x70
 [&lt;ffffffff81127c5b&gt;] ? __init_rwsem+0x97/0xac
 [&lt;ffffffff81492349&gt;] jffs2_do_fill_super+0x245/0x6f0
 [&lt;ffffffff81493c5b&gt;] jffs2_fill_super+0x287/0x2e0
 [&lt;ffffffff814939d4&gt;] ? jffs2_parse_options+0x594/0x594
 [&lt;ffffffff81819bea&gt;] mount_mtd_aux.isra.0+0x9a/0x144
 [&lt;ffffffff81819eb6&gt;] mount_mtd+0x222/0x2f0
 [&lt;ffffffff814939d4&gt;] ? jffs2_parse_options+0x594/0x594
 [&lt;ffffffff81819c94&gt;] ? mount_mtd_aux.isra.0+0x144/0x144
 [&lt;ffffffff81258757&gt;] ? free_pages+0x13/0x1c
 [&lt;ffffffff814fa0ac&gt;] ? selinux_sb_copy_data+0x278/0x2e0
 [&lt;ffffffff81492b35&gt;] jffs2_mount+0x41/0x60
 [&lt;ffffffff81302fb7&gt;] mount_fs+0x63/0x230
 [&lt;ffffffff8133755f&gt;] ? alloc_vfsmnt+0x32f/0x3b0
 [&lt;ffffffff81337f2c&gt;] vfs_kern_mount.part.6+0x6c/0x1f4
 [&lt;ffffffff8133ceec&gt;] do_mount+0xae8/0x1940
 [&lt;ffffffff811b94e0&gt;] ? audit_filter_rules.constprop.6+0x1d10/0x1d10
 [&lt;ffffffff8133c404&gt;] ? copy_mount_string+0x40/0x40
 [&lt;ffffffff812cbf78&gt;] ? alloc_pages_current+0xa4/0x1bc
 [&lt;ffffffff81253a89&gt;] ? __get_free_pages+0x25/0x50
 [&lt;ffffffff81338993&gt;] ? copy_mount_options.part.17+0x183/0x264
 [&lt;ffffffff8133e3a9&gt;] SyS_mount+0x105/0x1d0
 [&lt;ffffffff8133e2a4&gt;] ? copy_mnt_ns+0x560/0x560
 [&lt;ffffffff810e8391&gt;] ? msa_space_switch_handler+0x13d/0x190
 [&lt;ffffffff81be184a&gt;] entry_SYSCALL_64_fastpath+0x1e/0x97
 [&lt;ffffffff810e9274&gt;] ? 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
&gt;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 &lt;xukunkun1@huawei.com&gt;
Signed-off-by: lizhe &lt;lizhe67@huawei.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>jffs2: fix use after free in jffs2_sum_write_data()</title>
<updated>2021-03-03T15:44:17Z</updated>
<author>
<name>Tom Rix</name>
</author>
<published>2020-12-30T14:56:04Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=340ac6924e92520dbf223a1d6affdc0c0acd2a92'/>
<id>urn:sha1:340ac6924e92520dbf223a1d6affdc0c0acd2a92</id>
<content type='text'>
[ Upstream commit 19646447ad3a680d2ab08c097585b7d96a66126b ]

clang static analysis reports this problem

fs/jffs2/summary.c:794:31: warning: Use of memory after it is freed
                c-&gt;summary-&gt;sum_list_head = temp-&gt;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 &lt;trix@redhat.com&gt;
Reviewed-by: Nathan Chancellor &lt;natechancellor@gmail.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>jffs2: Fix GC exit abnormally</title>
<updated>2020-12-29T12:42:44Z</updated>
<author>
<name>Zhe Li</name>
</author>
<published>2020-05-29T03:37:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b644402f029bf69d8741310bc5558c2c68db4696'/>
<id>urn:sha1:b644402f029bf69d8741310bc5558c2c68db4696</id>
<content type='text'>
commit 9afc9a8a4909fece0e911e72b1060614ba2f7969 upstream.

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)-&gt;nhash == new-&gt;nhash &amp;&amp; !strcmp((*prev)-&gt;name, new-&gt;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: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Zhe Li &lt;lizhe67@huawei.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>jffs2: fix UAF problem</title>
<updated>2020-08-26T08:27:09Z</updated>
<author>
<name>Zhe Li</name>
</author>
<published>2020-06-19T09:06:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6156e6259c3d707fbafbedb017f334f5e19bf214'/>
<id>urn:sha1:6156e6259c3d707fbafbedb017f334f5e19bf214</id>
<content type='text'>
[ Upstream commit 798b7347e4f29553db4b996393caf12f5b233daf ]

The log of UAF problem is listed below.
BUG: KASAN: use-after-free in jffs2_rmdir+0xa4/0x1cc [jffs2] at addr c1f165fc
Read of size 4 by task rm/8283
=============================================================================
BUG kmalloc-32 (Tainted: P    B      O   ): kasan: bad access detected
-----------------------------------------------------------------------------

INFO: Allocated in 0xbbbbbbbb age=3054364 cpu=0 pid=0
        0xb0bba6ef
        jffs2_write_dirent+0x11c/0x9c8 [jffs2]
        __slab_alloc.isra.21.constprop.25+0x2c/0x44
        __kmalloc+0x1dc/0x370
        jffs2_write_dirent+0x11c/0x9c8 [jffs2]
        jffs2_do_unlink+0x328/0x5fc [jffs2]
        jffs2_rmdir+0x110/0x1cc [jffs2]
        vfs_rmdir+0x180/0x268
        do_rmdir+0x2cc/0x300
        ret_from_syscall+0x0/0x3c
INFO: Freed in 0x205b age=3054364 cpu=0 pid=0
        0x2e9173
        jffs2_add_fd_to_list+0x138/0x1dc [jffs2]
        jffs2_add_fd_to_list+0x138/0x1dc [jffs2]
        jffs2_garbage_collect_dirent.isra.3+0x21c/0x288 [jffs2]
        jffs2_garbage_collect_live+0x16bc/0x1800 [jffs2]
        jffs2_garbage_collect_pass+0x678/0x11d4 [jffs2]
        jffs2_garbage_collect_thread+0x1e8/0x3b0 [jffs2]
        kthread+0x1a8/0x1b0
        ret_from_kernel_thread+0x5c/0x64
Call Trace:
[c17ddd20] [c02452d4] kasan_report.part.0+0x298/0x72c (unreliable)
[c17ddda0] [d2509680] jffs2_rmdir+0xa4/0x1cc [jffs2]
[c17dddd0] [c026da04] vfs_rmdir+0x180/0x268
[c17dde00] [c026f4e4] do_rmdir+0x2cc/0x300
[c17ddf40] [c001a658] ret_from_syscall+0x0/0x3c

The root cause is that we don't get "jffs2_inode_info.sem" before
we scan list "jffs2_inode_info.dents" in function jffs2_rmdir.
This patch add codes to get "jffs2_inode_info.sem" before we scan
"jffs2_inode_info.dents" to slove the UAF problem.

Signed-off-by: Zhe Li &lt;lizhe67@huawei.com&gt;
Reviewed-by: Hou Tao &lt;houtao1@huawei.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>jffs2: fix use-after-free on symlink traversal</title>
<updated>2019-05-16T17:45:01Z</updated>
<author>
<name>Al Viro</name>
</author>
<published>2019-03-26T01:39:50Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=90a015d4d782371571058672be7fecbc685e34ec'/>
<id>urn:sha1:90a015d4d782371571058672be7fecbc685e34ec</id>
<content type='text'>
[ Upstream commit 4fdcfab5b5537c21891e22e65996d4d0dd8ab4ca ]

free the symlink body after the same RCU delay we have for freeing the
struct inode itself, so that traversal during RCU pathwalk wouldn't step
into freed memory.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>jffs2: Fix use of uninitialized delayed_work, lockdep breakage</title>
<updated>2019-01-26T08:42:53Z</updated>
<author>
<name>Daniel Santos</name>
</author>
<published>2018-10-19T08:30:20Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4d919739df1f044cd4f1b8e2b36f0144a0995967'/>
<id>urn:sha1:4d919739df1f044cd4f1b8e2b36f0144a0995967</id>
<content type='text'>
[ Upstream commit a788c5272769ddbcdbab297cf386413eeac04463 ]

jffs2_sync_fs makes the assumption that if CONFIG_JFFS2_FS_WRITEBUFFER
is defined then a write buffer is available and has been initialized.
However, this does is not the case when the mtd device has no
out-of-band buffer:

int jffs2_nand_flash_setup(struct jffs2_sb_info *c)
{
        if (!c-&gt;mtd-&gt;oobsize)
                return 0;
...

The resulting call to cancel_delayed_work_sync passing a uninitialized
(but zeroed) delayed_work struct forces lockdep to become disabled.

[   90.050639] overlayfs: upper fs does not support tmpfile.
[   90.652264] INFO: trying to register non-static key.
[   90.662171] the code is fine but needs lockdep annotation.
[   90.673090] turning off the locking correctness validator.
[   90.684021] CPU: 0 PID: 1762 Comm: mount_root Not tainted 4.14.63 #0
[   90.696672] Stack : 00000000 00000000 80d8f6a2 00000038 805f0000 80444600 8fe364f4 805dfbe7
[   90.713349]         80563a30 000006e2 8068370c 00000001 00000000 00000001 8e2fdc48 ffffffff
[   90.730020]         00000000 00000000 80d90000 00000000 00000106 00000000 6465746e 312e3420
[   90.746690]         6b636f6c 03bf0000 f8000000 20676e69 00000000 80000000 00000000 8e2c2a90
[   90.763362]         80d90000 00000001 00000000 8e2c2a90 00000003 80260dc0 08052098 80680000
[   90.780033]         ...
[   90.784902] Call Trace:
[   90.789793] [&lt;8000f0d8&gt;] show_stack+0xb8/0x148
[   90.798659] [&lt;8005a000&gt;] register_lock_class+0x270/0x55c
[   90.809247] [&lt;8005cb64&gt;] __lock_acquire+0x13c/0xf7c
[   90.818964] [&lt;8005e314&gt;] lock_acquire+0x194/0x1dc
[   90.828345] [&lt;8003f27c&gt;] flush_work+0x200/0x24c
[   90.837374] [&lt;80041dfc&gt;] __cancel_work_timer+0x158/0x210
[   90.847958] [&lt;801a8770&gt;] jffs2_sync_fs+0x20/0x54
[   90.857173] [&lt;80125cf4&gt;] iterate_supers+0xf4/0x120
[   90.866729] [&lt;80158fc4&gt;] sys_sync+0x44/0x9c
[   90.875067] [&lt;80014424&gt;] syscall_common+0x34/0x58

Signed-off-by: Daniel Santos &lt;daniel.santos@pobox.com&gt;
Reviewed-by: Hou Tao &lt;houtao1@huawei.com&gt;
Signed-off-by: Boris Brezillon &lt;boris.brezillon@bootlin.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>jffs2: free jffs2_sb_info through jffs2_kill_sb()</title>
<updated>2018-11-21T08:27:30Z</updated>
<author>
<name>Hou Tao</name>
</author>
<published>2018-10-06T09:09:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=85b89ccf86cececb3e562b071d078a3cf50a54cc'/>
<id>urn:sha1:85b89ccf86cececb3e562b071d078a3cf50a54cc</id>
<content type='text'>
commit 92e2921f7eee63450a5f953f4b15dc6210219430 upstream.

When an invalid mount option is passed to jffs2, jffs2_parse_options()
will fail and jffs2_sb_info will be freed, but then jffs2_sb_info will
be used (use-after-free) and freeed (double-free) in jffs2_kill_sb().

Fix it by removing the buggy invocation of kfree() when getting invalid
mount options.

Fixes: 92abc475d8de ("jffs2: implement mount option parsing and compression overriding")
Cc: stable@kernel.org
Signed-off-by: Hou Tao &lt;houtao1@huawei.com&gt;
Reviewed-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Boris Brezillon &lt;boris.brezillon@bootlin.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>jffs2: return -ERANGE when xattr buffer is too small</title>
<updated>2018-10-20T07:52:35Z</updated>
<author>
<name>Hou Tao</name>
</author>
<published>2018-10-12T06:01:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5ac147ebfa1c50cc0f25e3c7f42862cfe6b40d0d'/>
<id>urn:sha1:5ac147ebfa1c50cc0f25e3c7f42862cfe6b40d0d</id>
<content type='text'>
When a file have multiple xattrs and the passed buffer is
smaller than the required size, jffs2_listxattr() should
return -ERANGE instead of continue, else Oops may occur
due to memory corruption.

Also remove the unnecessary check ("rc &lt; 0"), because
xhandle-&gt;list(...) will not return an error number.

Spotted by generic/377 in xfstests-dev.

NB: The problem had been fixed by commit 764a5c6b1fa4 ("xattr
handlers: Simplify list operation") in v4.5-rc1, but the
modification in that commit may be too much because it modifies
all file-systems which implement xattr, so I create a single
patch for jffs2 to fix the problem.

Signed-off-by: Hou Tao &lt;houtao1@huawei.com&gt;
Cc: David Woodhouse &lt;dwmw2@infradead.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>jffs2: Fix use-after-free bug in jffs2_iget()'s error handling path</title>
<updated>2018-05-30T05:48:54Z</updated>
<author>
<name>Jake Daryll Obina</name>
</author>
<published>2017-09-21T16:00:14Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b222aa1cbd87e17821d96fbbd7fae5ed8321ad70'/>
<id>urn:sha1:b222aa1cbd87e17821d96fbbd7fae5ed8321ad70</id>
<content type='text'>
[ Upstream commit 5bdd0c6f89fba430e18d636493398389dadc3b17 ]

If jffs2_iget() fails for a newly-allocated inode, jffs2_do_clear_inode()
can get called twice in the error handling path, the first call in
jffs2_iget() itself and the second through iget_failed(). This can result
to a use-after-free error in the second jffs2_do_clear_inode() call, such
as shown by the oops below wherein the second jffs2_do_clear_inode() call
was trying to free node fragments that were already freed in the first
jffs2_do_clear_inode() call.

[   78.178860] jffs2: error: (1904) jffs2_do_read_inode_internal: CRC failed for read_inode of inode 24 at physical location 0x1fc00c
[   78.178914] Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b6b7b
[   78.185871] pgd = ffffffc03a567000
[   78.188794] [6b6b6b6b6b6b6b7b] *pgd=0000000000000000, *pud=0000000000000000
[   78.194968] Internal error: Oops: 96000004 [#1] PREEMPT SMP
...
[   78.513147] PC is at rb_first_postorder+0xc/0x28
[   78.516503] LR is at jffs2_kill_fragtree+0x28/0x90 [jffs2]
[   78.520672] pc : [&lt;ffffff8008323d28&gt;] lr : [&lt;ffffff8000eb1cc8&gt;] pstate: 60000105
[   78.526757] sp : ffffff800cea38f0
[   78.528753] x29: ffffff800cea38f0 x28: ffffffc01f3f8e80
[   78.532754] x27: 0000000000000000 x26: ffffff800cea3c70
[   78.536756] x25: 00000000dc67c8ae x24: ffffffc033d6945d
[   78.540759] x23: ffffffc036811740 x22: ffffff800891a5b8
[   78.544760] x21: 0000000000000000 x20: 0000000000000000
[   78.548762] x19: ffffffc037d48910 x18: ffffff800891a588
[   78.552764] x17: 0000000000000800 x16: 0000000000000c00
[   78.556766] x15: 0000000000000010 x14: 6f2065646f6e695f
[   78.560767] x13: 6461657220726f66 x12: 2064656c69616620
[   78.564769] x11: 435243203a6c616e x10: 7265746e695f6564
[   78.568771] x9 : 6f6e695f64616572 x8 : ffffffc037974038
[   78.572774] x7 : bbbbbbbbbbbbbbbb x6 : 0000000000000008
[   78.576775] x5 : 002f91d85bd44a2f x4 : 0000000000000000
[   78.580777] x3 : 0000000000000000 x2 : 000000403755e000
[   78.584779] x1 : 6b6b6b6b6b6b6b6b x0 : 6b6b6b6b6b6b6b6b
...
[   79.038551] [&lt;ffffff8008323d28&gt;] rb_first_postorder+0xc/0x28
[   79.042962] [&lt;ffffff8000eb5578&gt;] jffs2_do_clear_inode+0x88/0x100 [jffs2]
[   79.048395] [&lt;ffffff8000eb9ddc&gt;] jffs2_evict_inode+0x3c/0x48 [jffs2]
[   79.053443] [&lt;ffffff8008201ca8&gt;] evict+0xb0/0x168
[   79.056835] [&lt;ffffff8008202650&gt;] iput+0x1c0/0x200
[   79.060228] [&lt;ffffff800820408c&gt;] iget_failed+0x30/0x3c
[   79.064097] [&lt;ffffff8000eba0c0&gt;] jffs2_iget+0x2d8/0x360 [jffs2]
[   79.068740] [&lt;ffffff8000eb0a60&gt;] jffs2_lookup+0xe8/0x130 [jffs2]
[   79.073434] [&lt;ffffff80081f1a28&gt;] lookup_slow+0x118/0x190
[   79.077435] [&lt;ffffff80081f4708&gt;] walk_component+0xfc/0x28c
[   79.081610] [&lt;ffffff80081f4dd0&gt;] path_lookupat+0x84/0x108
[   79.085699] [&lt;ffffff80081f5578&gt;] filename_lookup+0x88/0x100
[   79.089960] [&lt;ffffff80081f572c&gt;] user_path_at_empty+0x58/0x6c
[   79.094396] [&lt;ffffff80081ebe14&gt;] vfs_statx+0xa4/0x114
[   79.098138] [&lt;ffffff80081ec44c&gt;] SyS_newfstatat+0x58/0x98
[   79.102227] [&lt;ffffff800808354c&gt;] __sys_trace_return+0x0/0x4
[   79.106489] Code: d65f03c0 f9400001 b40000e1 aa0103e0 (f9400821)

The jffs2_do_clear_inode() call in jffs2_iget() is unnecessary since
iget_failed() will eventually call jffs2_do_clear_inode() if needed, so
just remove it.

Fixes: 5451f79f5f81 ("iget: stop JFFS2 from using iget() and read_inode()")
Reviewed-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Jake Daryll Obina &lt;jake.obina@gmail.com&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
