From: Andrey Tsyvarev <tsyvarev@ispras.ru>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: linux-kernel@vger.kernel.org,
Alexey Khoroshilov <khoroshilov@ispras.ru>,
linux-f2fs-devel@lists.sourceforge.net
Subject: Fwd: f2fs: Possible use-after-free when umount filesystem
Date: Mon, 21 Jul 2014 15:09:36 +0400 [thread overview]
Message-ID: <53CCF4F0.3010206@ispras.ru> (raw)
In-Reply-To: <53CCF1EC.30008@ispras.ru>
[-- Attachment #1.1: Type: text/plain, Size: 6799 bytes --]
Sorry, used old maintainers list.
-------- Исходное сообщение --------
Тема: f2fs: Possible use-after-free when umount filesystem
Дата: Mon, 21 Jul 2014 14:56:44 +0400
От: Andrey Tsyvarev <tsyvarev@ispras.ru>
Кому: Jaegeuk Kim <jaegeuk.kim@samsung.com>
Копия: linux-f2fs-devel@lists.sourceforge.net, linux-kernel
<linux-kernel@vger.kernel.org>, Alexey Khoroshilov <khoroshilov@ispras.ru>
Hello,
Using memory error detector reveals the following use-after-free error
in 3.15.0:
AddressSanitizer: heap-use-after-free in f2fs_evict_inode
Read of size 8 by thread T22279:
[<ffffffffa02d8702>] f2fs_evict_inode+0x102/0x2e0 [f2fs]
/home/tester/linux-sources/linux-kasan/fs/f2fs/f2fs.h:584
[<ffffffff812359af>] evict+0x15f/0x290
/home/tester/linux-sources/linux-kasan/fs/inode.c:550
[< inlined >] iput+0x196/0x280 iput_final
/home/tester/linux-sources/linux-kasan/fs/inode.c:1418
[<ffffffff812369a6>] iput+0x196/0x280
/home/tester/linux-sources/linux-kasan/fs/inode.c:1436
[<ffffffffa02dc416>] f2fs_put_super+0xd6/0x170 [f2fs]
/home/tester/linux-sources/linux-kasan/fs/f2fs/super.c:434
[<ffffffff81210095>] generic_shutdown_super+0xc5/0x1b0
/home/tester/linux-sources/linux-kasan/fs/super.c:406
[<ffffffff812105fd>] kill_block_super+0x4d/0xb0
/home/tester/linux-sources/linux-kasan/fs/super.c:1019
[<ffffffff81210a86>] deactivate_locked_super+0x66/0x80
/home/tester/linux-sources/linux-kasan/fs/super.c:284
[<ffffffff81211c98>] deactivate_super+0x68/0x80
/home/tester/linux-sources/linux-kasan/fs/super.c:307
[<ffffffff8123cc88>] mntput_no_expire+0x198/0x250
/home/tester/linux-sources/linux-kasan/fs/namespace.c:986 (discriminator 3)
[< inlined >] SyS_umount+0xe9/0x1a0 SYSC_umount
/home/tester/linux-sources/linux-kasan/fs/namespace.c:1424
[<ffffffff8123f1c9>] SyS_umount+0xe9/0x1a0
/home/tester/linux-sources/linux-kasan/fs/namespace.c:1392
[<ffffffff81cc8df9>] system_call_fastpath+0x16/0x1b
/home/tester/linux-sources/linux-kasan/arch/x86/kernel/entry_64.S:426
Freed by thread T3:
[<ffffffffa02dc337>] f2fs_i_callback+0x27/0x30 [f2fs]
/home/tester/linux-sources/linux-kasan/fs/f2fs/super.c:408
[< inlined >] rcu_process_callbacks+0x2d6/0x930 __rcu_reclaim
/home/tester/linux-sources/linux-kasan/kernel/rcu/rcu.h:114
[< inlined >] rcu_process_callbacks+0x2d6/0x930 rcu_do_batch
/home/tester/linux-sources/linux-kasan/kernel/rcu/tree.c:2242
[< inlined >] rcu_process_callbacks+0x2d6/0x930
invoke_rcu_callbacks
/home/tester/linux-sources/linux-kasan/kernel/rcu/tree.c:2499
[< inlined >] rcu_process_callbacks+0x2d6/0x930
__rcu_process_callbacks
/home/tester/linux-sources/linux-kasan/kernel/rcu/tree.c:2466
[<ffffffff810fd266>] rcu_process_callbacks+0x2d6/0x930
/home/tester/linux-sources/linux-kasan/kernel/rcu/tree.c:2483
[<ffffffff8107cce2>] __do_softirq+0x142/0x380
/home/tester/linux-sources/linux-kasan/kernel/softirq.c:269
[<ffffffff8107cf50>] run_ksoftirqd+0x30/0x50
/home/tester/linux-sources/linux-kasan/kernel/softirq.c:658
[<ffffffff810b2a87>] smpboot_thread_fn+0x197/0x280
/home/tester/linux-sources/linux-kasan/kernel/smpboot.c:160
[<ffffffff810a8238>] kthread+0x148/0x160
/home/tester/linux-sources/linux-kasan/kernel/kthread.c:207
[<ffffffff81cc8d4c>] ret_from_fork+0x7c/0xb0
/home/tester/linux-sources/linux-kasan/arch/x86/kernel/entry_64.S:351
Allocated by thread T22276:
[<ffffffffa02dc7dd>] f2fs_alloc_inode+0x2d/0x170 [f2fs]
/home/tester/linux-sources/linux-kasan/fs/f2fs/super.c:356
[<ffffffff8123471d>] alloc_inode+0x2d/0xe0
/home/tester/linux-sources/linux-kasan/fs/inode.c:208
[<ffffffff81235e2a>] iget_locked+0x10a/0x230
/home/tester/linux-sources/linux-kasan/fs/inode.c:1085
[<ffffffffa02d7495>] f2fs_iget+0x35/0xa80 [f2fs]
/home/tester/linux-sources/linux-kasan/fs/f2fs/inode.c:129
[<ffffffffa02e2393>] f2fs_fill_super+0xb53/0xff0 [f2fs]
/home/tester/linux-sources/linux-kasan/fs/f2fs/super.c:1021
[<ffffffff81211bce>] mount_bdev+0x1de/0x240
/home/tester/linux-sources/linux-kasan/fs/super.c:992
[<ffffffffa02dbce0>] f2fs_mount+0x10/0x20 [f2fs]
/home/tester/linux-sources/linux-kasan/fs/f2fs/super.c:1127
[<ffffffff81212a85>] mount_fs+0x55/0x220
/home/tester/linux-sources/linux-kasan/fs/super.c:1095
[<ffffffff8123c026>] vfs_kern_mount+0x66/0x200
/home/tester/linux-sources/linux-kasan/fs/namespace.c:851
[< inlined >] do_mount+0x2b4/0x1120 do_new_mount
/home/tester/linux-sources/linux-kasan/fs/namespace.c:2129
[<ffffffff812400d4>] do_mount+0x2b4/0x1120
/home/tester/linux-sources/linux-kasan/fs/namespace.c:2453
[< inlined >] SyS_mount+0xb2/0x110 SYSC_mount
/home/tester/linux-sources/linux-kasan/fs/namespace.c:2647
[<ffffffff812414a2>] SyS_mount+0xb2/0x110
/home/tester/linux-sources/linux-kasan/fs/namespace.c:2620
[<ffffffff81cc8df9>] system_call_fastpath+0x16/0x1b
/home/tester/linux-sources/linux-kasan/arch/x86/kernel/entry_64.S:426
The buggy address ffff8800587866c8 is located 48 bytes inside
of 680-byte region [ffff880058786698, ffff880058786940)
Memory state around the buggy address:
ffff880058786100: ffffffff ffffffff ffffffff ffffffff
ffff880058786200: ffffffff ffffffff ffffffrr rrrrrrrr
ffff880058786300: rrrrrrrr rrffffff ffffffff ffffffff
ffff880058786400: ffffffff ffffffff ffffffff ffffffff
ffff880058786500: ffffffff ffffffff ffffffff fffffffr
>ffff880058786600: rrrrrrrr rrrrrrrr rrrfffff ffffffff
^
ffff880058786700: ffffffff ffffffff ffffffff ffffffff
ffff880058786800: ffffffff ffffffff ffffffff ffffffff
ffff880058786900: ffffffff rrrrrrrr rrrrrrrr rrrr....
ffff880058786a00: ........ ........ ........ ........
ffff880058786b00: ........ ........ ........ ........
Legend:
f - 8 freed bytes
r - 8 redzone bytes
. - 8 allocated bytes
x=1..7 - x allocated bytes + (8-x) redzone bytes
Investigation shows, that f2fs_evict_inode, when called for
'meta_inode', uses invalidate_mapping_pages() for 'node_inode'.
But 'node_inode' is deleted before 'meta_inode' in f2fs_put_super via
iput().
It seems that in common usage scenario this use-after-free is benign,
because 'node_inode' remains partially valid data even after
kmem_cache_free().
But things may change if, while 'meta_inode' is evicted in one f2fs
filesystem, another (mounted) f2fs filesystem requests inode from cache,
and formely
'node_inode' of the first filesystem is returned.
Found by Linux File System Verification project (linuxtesting.org).
--
Best regards,
Andrey Tsyvarev
Linux Verification Center, ISPRAS
web:http://linuxtesting.org
[-- Attachment #1.2: Type: text/html, Size: 8605 bytes --]
[-- Attachment #2: Type: text/plain, Size: 362 bytes --]
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
[-- Attachment #3: Type: text/plain, Size: 179 bytes --]
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2014-07-21 11:09 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-06 5:43 f2fs: f2fs unmount hangs if f2fs_init_acl() fails during mkdir syscall Andrey Tsyvarev
2014-02-06 6:02 ` Jaegeuk Kim
2014-02-06 12:17 ` Andrey Tsyvarev
2014-02-07 0:49 ` Jaegeuk Kim
2014-02-07 5:12 ` Jaegeuk Kim
2014-02-11 8:29 ` Andrey Tsyvarev
2014-02-13 8:32 ` Gu Zheng
2014-02-13 9:40 ` Andrey Tsyvarev
2014-02-13 9:48 ` Gu Zheng
2014-02-14 2:00 ` [f2fs-dev] " Jaegeuk Kim
2014-02-14 1:58 ` Jaegeuk Kim
2014-04-14 11:12 ` f2fs: BUG_ON() is triggered when mount valid f2fs filesystem Andrey Tsyvarev
2014-04-15 11:04 ` Jaegeuk Kim
2014-04-16 9:11 ` Andrey Tsyvarev
2014-04-16 23:35 ` Jaegeuk Kim
2014-04-17 1:11 ` Alexey Khoroshilov
2014-04-17 7:45 ` Jaegeuk Kim
2014-04-18 6:04 ` Alexey Khoroshilov
2014-04-18 6:35 ` Jaegeuk Kim
2014-04-18 6:40 ` Gu Zheng
2014-07-21 10:56 ` f2fs: Possible use-after-free when umount filesystem Andrey Tsyvarev
2014-07-21 11:09 ` Andrey Tsyvarev [this message]
2014-07-22 2:17 ` Gu Zheng
2014-07-22 10:04 ` Andrey Tsyvarev
2014-07-23 2:12 ` Chao Yu
2014-07-23 3:39 ` [f2fs-dev] " Gu Zheng
2014-07-24 10:14 ` Andrey Tsyvarev
2014-07-25 3:22 ` Chao Yu
2014-07-25 5:49 ` Gu Zheng
2014-07-25 15:37 ` Jaegeuk Kim
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=53CCF4F0.3010206@ispras.ru \
--to=tsyvarev@ispras.ru \
--cc=jaegeuk@kernel.org \
--cc=khoroshilov@ispras.ru \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).