From: Dmitry Vyukov <dvyukov@google.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
syzkaller <syzkaller@googlegroups.com>
Subject: Re: fs: use-after-free in path_lookupat
Date: Sun, 5 Mar 2017 12:15:56 +0100 [thread overview]
Message-ID: <CACT4Y+Y23b8QhB8Hmasr5jXtwAwvvY=wVrorgRHzUWcdspURMg@mail.gmail.com> (raw)
In-Reply-To: <20170304193910.GG29622@ZenIV.linux.org.uk>
On Sat, Mar 4, 2017 at 8:39 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Sat, Mar 04, 2017 at 03:59:36PM +0100, Dmitry Vyukov wrote:
>
>> I am getting the following use-after-free reports while running
>> syzkaller fuzzer on 86292b33d4b79ee03e2f43ea0381ef85f077c760 (but also
>> happened on 6dc39c50e4aeb769c8ae06edf2b1a732f3490913 and
>> c82be9d2244aacea9851c86f4fb74694c99cd874).
>
> IOW, it's not fs/namei.c patches from this window...
>
>> unlazy_walk+0xf2/0x4b0 fs/namei.c:692
>
> Could you post disassembly (e.g. from objdump -d) of your unlazy_walk()?
> For the kernel the trace is from...
>
>> r4 = memfd_create(&(0x7f0000013000)="2f6465762f6877726e6700", 0x0)
>> name_to_handle_at(r4, &(0x7f0000003000-0x6)="2e2f62757300",
>> &(0x7f0000003000-0xd)={0xc, 0x0, "cd21"}, &(0x7f0000002000)=0x0,
>> 0x1000)
>>
>> What's strange is that dirfd passed to name_to_handle_at is memfd
>> handle (sic). And path lookup somehow does not fail early on this.
>> Does it make any sense?
>
> It doesn't, but is that the triggering call of name_to_handle_at(), or do you
> have it called elsewhere?
>
> FWIW, no LOOKUP_ROOT in filename_lookup() flags + NULL root + dfd not
> equal to AT_FDCWD + non-empty name should've ended up in
> if (!d_can_lookup(dentry)) {
> fdput(f);
> return ERR_PTR(-ENOTDIR);
> }
> in path_init() and it shouldn't have progressed any further. And in case
> of name_to_handle_at() we have user_path_at(dfd, name, lookup_flags, &path),
> i.e. user_path_at_empty(dfd, name, lookup_flags, &path, NULL), i.e.
> filename_lookup(dfd, getname_flags(name, lookup_flags, NULL), lookup_flags,
> &path, NULL). IOW, filename_lookup() is called with root equal to NULL,
> dfd and name coming straight from userland and lookup_flags containing
> nothing beyond LOOKUP_EMPTY and LOOKUP_FOLLOW...
I probably messed something. Here is a new report on
0710f3ff91ecc4a715db6e4d0690472b13c4dac6. Line numbers seem to match
now.
BUG: KASAN: use-after-free in debug_spin_lock_before
kernel/locking/spinlock_debug.c:83 [inline] at addr ffff880059c2ace4
BUG: KASAN: use-after-free in do_raw_spin_lock+0x1bb/0x1f0
kernel/locking/spinlock_debug.c:112 at addr ffff880059c2ace4
Read of size 4 by task syz-executor/21853
CPU: 0 PID: 21853 Comm: syz-executor Not tainted 4.10.0+ #293
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0x2fb/0x3fd lib/dump_stack.c:52
kasan_object_err+0x1c/0x90 mm/kasan/report.c:166
print_address_description mm/kasan/report.c:208 [inline]
kasan_report_error mm/kasan/report.c:292 [inline]
kasan_report.part.2+0x1b0/0x460 mm/kasan/report.c:314
kasan_report mm/kasan/report.c:334 [inline]
__asan_report_load4_noabort+0x29/0x30 mm/kasan/report.c:334
debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
do_raw_spin_lock+0x1bb/0x1f0 kernel/locking/spinlock_debug.c:112
__raw_spin_lock include/linux/spinlock_api_smp.h:143 [inline]
_raw_spin_lock+0x3b/0x50 kernel/locking/spinlock.c:151
spin_lock include/linux/spinlock.h:299 [inline]
lockref_get_not_dead+0x19/0x80 lib/lockref.c:179
legitimize_path.isra.36+0x7d/0x1a0 fs/namei.c:640
unlazy_walk+0xf2/0x4b0 fs/namei.c:692
complete_walk+0xb2/0x1f0 fs/namei.c:805
path_lookupat+0x1c1/0x400 fs/namei.c:2275
filename_lookup+0x282/0x540 fs/namei.c:2301
user_path_at_empty+0x40/0x50 fs/namei.c:2555
user_path_at include/linux/namei.h:55 [inline]
SYSC_name_to_handle_at fs/fhandle.c:106 [inline]
SyS_name_to_handle_at+0xff/0x720 fs/fhandle.c:92
entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x4458d9
RSP: 002b:00007f462e243b58 EFLAGS: 00000286 ORIG_RAX: 000000000000012f
RAX: ffffffffffffffda RBX: 0000000000000051 RCX: 00000000004458d9
RDX: 0000000020002ff3 RSI: 0000000020002ffa RDI: 0000000000000051
RBP: 00000000006e11b0 R08: 0000000000001000 R09: 0000000000000000
R10: 0000000020002000 R11: 0000000000000286 R12: 0000000000708000
R13: 0000000020000000 R14: 0000000000013000 R15: 0000000000000003
Object at ffff880059c2ac60, in cache dentry size: 288
Allocated:
PID = 21878
save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
save_stack+0x43/0xd0 mm/kasan/kasan.c:513
set_track mm/kasan/kasan.c:525 [inline]
kasan_kmalloc+0xaa/0xd0 mm/kasan/kasan.c:616
kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:555
kmem_cache_alloc+0x102/0x6e0 mm/slab.c:3572
__d_alloc+0xb3/0xbb0 fs/dcache.c:1571
d_alloc_pseudo+0x1d/0x30 fs/dcache.c:1692
__shmem_file_setup+0x20c/0x5a0 mm/shmem.c:4157
shmem_file_setup mm/shmem.c:4212 [inline]
SYSC_memfd_create mm/shmem.c:3672 [inline]
SyS_memfd_create+0x172/0x2c0 mm/shmem.c:3630
entry_SYSCALL_64_fastpath+0x1f/0xc2
Freed:
PID = 21878
save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
save_stack+0x43/0xd0 mm/kasan/kasan.c:513
set_track mm/kasan/kasan.c:525 [inline]
kasan_slab_free+0x6f/0xb0 mm/kasan/kasan.c:589
__cache_free mm/slab.c:3514 [inline]
kmem_cache_free+0x71/0x240 mm/slab.c:3774
__d_free fs/dcache.c:265 [inline]
dentry_free+0xd5/0x160 fs/dcache.c:314
__dentry_kill+0x471/0x6d0 fs/dcache.c:552
dentry_kill fs/dcache.c:579 [inline]
dput.part.25+0x5ce/0x7c0 fs/dcache.c:791
dput+0x1f/0x30 fs/dcache.c:753
__fput+0x538/0x800 fs/file_table.c:227
____fput+0x15/0x20 fs/file_table.c:245
task_work_run+0x197/0x260 kernel/task_work.c:116
tracehook_notify_resume include/linux/tracehook.h:191 [inline]
exit_to_usermode_loop+0x23b/0x2a0 arch/x86/entry/common.c:161
prepare_exit_to_usermode arch/x86/entry/common.c:191 [inline]
syscall_return_slowpath+0x4d3/0x570 arch/x86/entry/common.c:260
entry_SYSCALL_64_fastpath+0xc0/0xc2
Memory state around the buggy address:
ffff880059c2ab80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff880059c2ac00: 00 00 00 00 fc fc fc fc fc fc fc fc fb fb fb fb
>ffff880059c2ac80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff880059c2ad00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff880059c2ad80: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
==================================================================
next prev parent reply other threads:[~2017-03-05 11:16 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-04 14:59 fs: use-after-free in path_lookupat Dmitry Vyukov
2017-03-04 19:39 ` Al Viro
2017-03-05 11:15 ` Dmitry Vyukov [this message]
2017-03-05 11:20 ` Dmitry Vyukov
2017-03-05 11:24 ` Dmitry Vyukov
2017-03-05 11:37 ` Dmitry Vyukov
2017-03-05 15:57 ` Al Viro
2017-03-05 16:14 ` Dmitry Vyukov
2017-03-05 16:33 ` Al Viro
2017-03-05 17:33 ` Dmitry Vyukov
2017-03-05 17:38 ` Dmitry Vyukov
2017-03-05 19:18 ` Al Viro
2017-03-06 9:46 ` Dmitry Vyukov
2017-03-23 14:17 ` Dmitry Vyukov
2017-04-28 6:19 ` Dmitry Vyukov
2017-05-29 14:48 ` Dmitry Vyukov
2017-05-30 6:24 ` Al Viro
2017-05-30 8:19 ` Dmitry Vyukov
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='CACT4Y+Y23b8QhB8Hmasr5jXtwAwvvY=wVrorgRHzUWcdspURMg@mail.gmail.com' \
--to=dvyukov@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=syzkaller@googlegroups.com \
--cc=viro@zeniv.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.