public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: "libaokun (A)" <libaokun1@huawei.com>
To: <richard@nod.at>, <dwmw2@infradead.org>,
	<christian.brauner@ubuntu.com>, <linux-mtd@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Cc: <yukuai3@huawei.com>, <stable@vger.kernel.org>,
	Hulk Robot <hulkci@huawei.com>, Baokun Li <libaokun1@huawei.com>
Subject: Re: [PATCH -next] jffs2: fix use-after-free in jffs2_clear_xattr_subsystem
Date: Thu, 10 Mar 2022 16:35:18 +0800	[thread overview]
Message-ID: <8a175ec6-1555-8575-1f03-0002efac1740@huawei.com> (raw)
In-Reply-To: <20211228125430.1880252-1-libaokun1@huawei.com>

A gentle ping, sorry for the noise.

在 2021/12/28 20:54, Baokun Li 写道:
> When we mount a jffs2 image, assume that the first few blocks of
> the image are normal and contain at least one xattr-related inode,
> but the next block is abnormal. As a result, an error is returned
> in jffs2_scan_eraseblock(). jffs2_clear_xattr_subsystem() is then
> called in jffs2_build_filesystem() and then again in
> jffs2_do_fill_super().
>
> Finally we can observe the following report:
>   ==================================================================
>   BUG: KASAN: use-after-free in jffs2_clear_xattr_subsystem+0x95/0x6ac
>   Read of size 8 at addr ffff8881243384e0 by task mount/719
>
>   Call Trace:
>    dump_stack+0x115/0x16b
>    jffs2_clear_xattr_subsystem+0x95/0x6ac
>    jffs2_do_fill_super+0x84f/0xc30
>    jffs2_fill_super+0x2ea/0x4c0
>    mtd_get_sb+0x254/0x400
>    mtd_get_sb_by_nr+0x4f/0xd0
>    get_tree_mtd+0x498/0x840
>    jffs2_get_tree+0x25/0x30
>    vfs_get_tree+0x8d/0x2e0
>    path_mount+0x50f/0x1e50
>    do_mount+0x107/0x130
>    __se_sys_mount+0x1c5/0x2f0
>    __x64_sys_mount+0xc7/0x160
>    do_syscall_64+0x45/0x70
>    entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
>   Allocated by task 719:
>    kasan_save_stack+0x23/0x60
>    __kasan_kmalloc.constprop.0+0x10b/0x120
>    kasan_slab_alloc+0x12/0x20
>    kmem_cache_alloc+0x1c0/0x870
>    jffs2_alloc_xattr_ref+0x2f/0xa0
>    jffs2_scan_medium.cold+0x3713/0x4794
>    jffs2_do_mount_fs.cold+0xa7/0x2253
>    jffs2_do_fill_super+0x383/0xc30
>    jffs2_fill_super+0x2ea/0x4c0
>   [...]
>
>   Freed by task 719:
>    kmem_cache_free+0xcc/0x7b0
>    jffs2_free_xattr_ref+0x78/0x98
>    jffs2_clear_xattr_subsystem+0xa1/0x6ac
>    jffs2_do_mount_fs.cold+0x5e6/0x2253
>    jffs2_do_fill_super+0x383/0xc30
>    jffs2_fill_super+0x2ea/0x4c0
>   [...]
>
>   The buggy address belongs to the object at ffff8881243384b8
>    which belongs to the cache jffs2_xattr_ref of size 48
>   The buggy address is located 40 bytes inside of
>    48-byte region [ffff8881243384b8, ffff8881243384e8)
>   [...]
>   ==================================================================
>
> The triggering of the BUG is shown in the following stack:
> -----------------------------------------------------------
> jffs2_fill_super
>    jffs2_do_fill_super
>      jffs2_do_mount_fs
>        jffs2_build_filesystem
>          jffs2_scan_medium
>            jffs2_scan_eraseblock        <--- ERROR
>          jffs2_clear_xattr_subsystem    <--- free
>      jffs2_clear_xattr_subsystem        <--- free again
> -----------------------------------------------------------
>
> An error is returned in jffs2_do_mount_fs(). If the error is returned
> by jffs2_sum_init(), the jffs2_clear_xattr_subsystem() does not need to
> be executed. If the error is returned by jffs2_build_filesystem(), the
> jffs2_clear_xattr_subsystem() also does not need to be executed again.
> So move jffs2_clear_xattr_subsystem() from 'out_inohash' to 'out_root'
> to fix this UAF problem.
>
> Fixes: aa98d7cf59b5 ("[JFFS2][XATTR] XATTR support on JFFS2 (version. 5)")
> Cc: stable@vger.kernel.org
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: Baokun Li <libaokun1@huawei.com>
> ---
>   fs/jffs2/fs.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/jffs2/fs.c b/fs/jffs2/fs.c
> index 2ac410477c4f..71f03a5d36ed 100644
> --- a/fs/jffs2/fs.c
> +++ b/fs/jffs2/fs.c
> @@ -603,8 +603,8 @@ int jffs2_do_fill_super(struct super_block *sb, struct fs_context *fc)
>   	jffs2_free_ino_caches(c);
>   	jffs2_free_raw_node_refs(c);
>   	kvfree(c->blocks);
> - out_inohash:
>   	jffs2_clear_xattr_subsystem(c);
> + out_inohash:
>   	kfree(c->inocache_list);
>    out_wbuf:
>   	jffs2_flash_cleanup(c);

-- 
With Best Regards,
Baokun Li


  parent reply	other threads:[~2022-03-10  8:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-28 12:54 [PATCH -next] jffs2: fix use-after-free in jffs2_clear_xattr_subsystem Baokun Li
2022-02-18  6:12 ` libaokun (A)
2022-03-10  8:35 ` libaokun (A) [this message]
2022-03-16 22:01   ` Richard Weinberger
2022-03-17  1:29     ` libaokun (A)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8a175ec6-1555-8575-1f03-0002efac1740@huawei.com \
    --to=libaokun1@huawei.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=dwmw2@infradead.org \
    --cc=hulkci@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    --cc=stable@vger.kernel.org \
    --cc=yukuai3@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox