linux-stable.git/drivers/staging/erofs, branch linux-5.0.y

staging: erofs: keep corrupted fs from crashing kernel in erofs_readdir()

2019-04-03T04:27:33+00:00

commit 33bac912840fe64dbc15556302537dc6a17cac63 upstream.

After commit 419d6efc50e9, kernel cannot be crashed in the namei
path. However, corrupted nameoff can do harm in the process of
readdir for scenerios without dm-verity as well. Fix it now.

Fixes: 3aa8ec716e52 ("staging: erofs: add directory operations")
Cc:  # 4.19+
Signed-off-by: Gao Xiang 
Reviewed-by: Chao Yu 
Signed-off-by: Greg Kroah-Hartman

staging: erofs: fix error handling when failed to read compresssed data

2019-04-03T04:27:33+00:00

commit b6391ac73400eff38377a4a7364bd3df5efb5178 upstream.

Complete read error handling paths for all three kinds of
compressed pages:

 1) For cache-managed pages, PG_uptodate will be checked since
    read_endio will unlock and SetPageUptodate for these pages;

 2) For inplaced pages, read_endio cannot SetPageUptodate directly
    since it should be used to mark the final decompressed data,
    PG_error will be set with page locked for IO error instead;

 3) For staging pages, PG_error is used, which is similar to
    what we do for inplaced pages.

Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
Cc:  # 4.19+
Reviewed-by: Chao Yu 
Signed-off-by: Gao Xiang 
Signed-off-by: Greg Kroah-Hartman

staging: erofs: fix to handle error path of erofs_vmap()

2019-04-03T04:27:32+00:00

commit 8bce6dcede65139a087ff240127e3f3c01363eed upstream.

erofs_vmap() wrapped vmap() and vm_map_ram() to return virtual
continuous memory, but both of them can failed due to a lot of
reason, previously, erofs_vmap()'s callers didn't handle them,
which can potentially cause NULL pointer access, fix it.

Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
Fixes: 0d40d6e399c1 ("staging: erofs: add a generic z_erofs VLE decompressor")
Cc:  # 4.19+
Signed-off-by: Gao Xiang 
Signed-off-by: Chao Yu 
Signed-off-by: Greg Kroah-Hartman

staging: erofs: compressed_pages should not be accessed again after freed

2019-03-13T21:01:31+00:00

commit af692e117cb8cd9d3d844d413095775abc1217f9 upstream.

This patch resolves the following page use-after-free issue,
z_erofs_vle_unzip:
    ...
    for (i = 0; i < nr_pages; ++i) {
        ...
        z_erofs_onlinepage_endio(page);  (1)
    }

    for (i = 0; i < clusterpages; ++i) {
        page = compressed_pages[i];

        if (page->mapping == mngda)      (2)
            continue;
        /* recycle all individual staging pages */
        (void)z_erofs_gather_if_stagingpage(page_pool, page); (3)
        WRITE_ONCE(compressed_pages[i], NULL);
    }
    ...

After (1) is executed, page is freed and could be then reused, if
compressed_pages is scanned after that, it could fall info (2) or
(3) by mistake and that could finally be in a mess.

This patch aims to solve the above issue only with little changes
as much as possible in order to make the fix backport easier.

Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
Cc:  # 4.19+
Signed-off-by: Gao Xiang 
Reviewed-by: Chao Yu 
Signed-off-by: Greg Kroah-Hartman

staging: erofs: keep corrupted fs from crashing kernel in erofs_namei()

2019-03-13T21:01:31+00:00

commit 419d6efc50e94bcf5d6b35cd8c71f79edadec564 upstream.

As Al pointed out, "
... and while we are at it, what happens to
	unsigned int nameoff = le16_to_cpu(de[mid].nameoff);
	unsigned int matched = min(startprfx, endprfx);

	struct qstr dname = QSTR_INIT(data + nameoff,
		unlikely(mid >= ndirents - 1) ?
			maxsize - nameoff :
			le16_to_cpu(de[mid + 1].nameoff) - nameoff);

	/* string comparison without already matched prefix */
	int ret = dirnamecmp(name, &dname, &matched);
if le16_to_cpu(de[...].nameoff) is not monotonically increasing?  I.e.
what's to prevent e.g. (unsigned)-1 ending up in dname.len?

Corrupted fs image shouldn't oops the kernel.. "

Revisit the related lookup flow to address the issue.

Fixes: d72d1ce60174 ("staging: erofs: add namei functions")
Cc:  # 4.19+
Suggested-by: Al Viro 
Signed-off-by: Gao Xiang 
Signed-off-by: Greg Kroah-Hartman

staging: erofs: fix illegal address access under memory pressure

2019-03-10T06:08:58+00:00

commit 1e5ceeab6929585512c63d05911d6657064abf7b upstream.

Considering a read request with two decompressed file pages,
If a decompression work cannot be started on the previous page
due to memory pressure but in-memory LTP map lookup is done,
builder->work should be still NULL.

Moreover, if the current page also belongs to the same map,
it won't try to start the decompression work again and then
run into trouble.

This patch aims to solve the above issue only with little changes
as much as possible in order to make the fix backport easier.

kernel message is:
<4>[1051408.015930s]SLUB: Unable to allocate memory on node -1, gfp=0x2408040(GFP_NOFS|__GFP_ZERO)
<4>[1051408.015930s]  cache: erofs_compress, object size: 144, buffer size: 144, default order: 0, min order: 0
<4>[1051408.015930s]  node 0: slabs: 98, objs: 2744, free: 0
  * Cannot allocate the decompression work

<3>[1051408.015960s]erofs: z_erofs_vle_normalaccess_readpages, readahead error at page 1008 of nid 5391488
  * Note that the previous page was failed to read

<0>[1051408.015960s]Internal error: Accessing user space memory outside uaccess.h routines: 96000005 [#1] PREEMPT SMP
...
<4>[1051408.015991s]Hardware name: kirin710 (DT)
...
<4>[1051408.016021s]PC is at z_erofs_vle_work_add_page+0xa0/0x17c
<4>[1051408.016021s]LR is at z_erofs_do_read_page+0x12c/0xcf0
...
<4>[1051408.018096s][] z_erofs_vle_work_add_page+0xa0/0x17c
<4>[1051408.018096s][] z_erofs_vle_normalaccess_readpages+0x1a0/0x37c
<4>[1051408.018096s][] read_pages+0x70/0x190
<4>[1051408.018127s][] __do_page_cache_readahead+0x194/0x1a8
<4>[1051408.018127s][] filemap_fault+0x398/0x684
<4>[1051408.018127s][] __do_fault+0x8c/0x138
<4>[1051408.018127s][] handle_pte_fault+0x730/0xb7c
<4>[1051408.018127s][] __handle_mm_fault+0xac/0xf4
<4>[1051408.018157s][] handle_mm_fault+0x7c/0x118
<4>[1051408.018157s][] do_page_fault+0x354/0x474
<4>[1051408.018157s][] do_translation_fault+0x40/0x48
<4>[1051408.018157s][] do_mem_abort+0x80/0x100
<4>[1051408.018310s]---[ end trace 9f4009a3283bd78b ]---

Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
Cc:  # 4.19+
Signed-off-by: Gao Xiang 
Reviewed-by: Chao Yu 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

staging: erofs: fix race of initializing xattrs of a inode at the same time

2019-03-10T06:08:58+00:00

commit 62dc45979f3f8cb0ea67302a93bff686f0c46c5a upstream.

In real scenario, there could be several threads accessing xattrs
of the same xattr-uninitialized inode, and init_inode_xattrs()
almost at the same time.

That's actually an unexpected behavior, this patch closes the race.

Fixes: b17500a0fdba ("staging: erofs: introduce xattr & acl support")
Cc:  # 4.19+
Reviewed-by: Chao Yu 
Signed-off-by: Gao Xiang 
Signed-off-by: Greg Kroah-Hartman

staging: erofs: fix memleak of inode's shared xattr array

2019-03-10T06:08:58+00:00

commit 3b1b5291f79d040d549d7c746669fc30e8045b9b upstream.

If it fails to read a shared xattr page, the inode's shared xattr array
is not freed. The next time the inode's xattr is accessed, the previously
allocated array is leaked.

Signed-off-by: Sheng Yong 
Fixes: b17500a0fdba ("staging: erofs: introduce xattr & acl support")
Cc:  # 4.19+
Reviewed-by: Gao Xiang 
Signed-off-by: Greg Kroah-Hartman

staging: erofs: fix fast symlink w/o xattr when fs xattr is on

2019-03-10T06:08:58+00:00

commit 7077fffcb0b0b65dc75e341306aeef4d0e7f2ec6 upstream.

Currently, this will hit a BUG_ON for these symlinks as follows:

- kernel message
------------[ cut here ]------------
kernel BUG at drivers/staging/erofs/xattr.c:59!
SMP PTI
CPU: 1 PID: 1170 Comm: getllxattr Not tainted 4.20.0-rc6+ #92
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014
RIP: 0010:init_inode_xattrs+0x22b/0x270
Code: 48 0f 45 ea f0 ff 4d 34 74 0d 41 83 4c 24 e0 01 31 c0 e9 00 fe ff ff 48 89 ef e8 e0 31 9e ff eb e9 89 e8 e9 ef fd ff ff 0f 0$
 <0f> 0b 48 89 ef e8 fb f6 9c ff 48 8b 45 08 a8 01 75 24 f0 ff 4d 34
RSP: 0018:ffffa03ac026bdf8 EFLAGS: 00010246
------------[ cut here ]------------
...
Call Trace:
 erofs_listxattr+0x30/0x2c0
 ? selinux_inode_listxattr+0x5a/0x80
 ? kmem_cache_alloc+0x33/0x170
 ? security_inode_listxattr+0x27/0x40
 listxattr+0xaf/0xc0
 path_listxattr+0x5a/0xa0
 do_syscall_64+0x43/0xf0
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
...
---[ end trace 3c24b49408dc0c72 ]---

Fix it by checking ->xattr_isize in init_inode_xattrs(),
and it also fixes improper return value -ENOTSUPP
(it should be -ENODATA if xattr is enabled) for those inodes.

Fixes: b17500a0fdba ("staging: erofs: introduce xattr & acl support")
Cc:  # 4.19+
Reported-by: Li Guifu 
Tested-by: Li Guifu 
Reviewed-by: Chao Yu 
Signed-off-by: Gao Xiang 
Signed-off-by: Greg Kroah-Hartman

staging: erofs: fix mis-acted TAIL merging behavior

2019-03-10T06:08:57+00:00

commit a112152f6f3a2a88caa6f414d540bd49e406af60 upstream.

EROFS has an optimized path called TAIL merging, which is designed
to merge multiple reads and the corresponding decompressions into
one if these requests read continuous pages almost at the same time.

In general, it behaves as follows:
 ________________________________________________________________
  ... |  TAIL  .  HEAD  |  PAGE  |  PAGE  |  TAIL    . HEAD | ...
 _____|_combined page A_|________|________|_combined page B_|____
        1  ]  ->  [  2                          ]  ->  [ 3
If the above three reads are requested in the order 1-2-3, it will
generate a large work chain rather than 3 individual work chains
to reduce scheduling overhead and boost up sequential read.

However, if Read 2 is processed slightly earlier than Read 1,
currently it still generates 2 individual work chains (chain 1, 2)
but it does in-place decompression for combined page A, moreover,
if chain 2 decompresses ahead of chain 1, it will be a race and
lead to corrupted decompressed page. This patch fixes it.

Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
Cc:  # 4.19+
Signed-off-by: Gao Xiang 
Reviewed-by: Chao Yu 
Signed-off-by: Greg Kroah-Hartman