From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Sasha Levin <sasha.levin@oracle.com>, Davidlohr Bueso <davidlohr@hp.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Jones <davej@redhat.com>
Subject: Re: mm: NULL ptr deref in unlink_file_vma
Date: Mon, 22 Dec 2014 20:01:02 +0200 [thread overview]
Message-ID: <20141222180102.GA8072@node.dhcp.inet.fi> (raw)
In-Reply-To: <549832E2.8060609@oracle.com>
On Mon, Dec 22, 2014 at 10:04:02AM -0500, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest running the latest -next
> kernel, I've stumbled on the following spew:
>
> [ 432.376425] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
> [ 432.378876] IP: down_write (./arch/x86/include/asm/rwsem.h:105 ./arch/x86/include/asm/rwsem.h:121 kernel/locking/rwsem.c:71)
Looks like vma->vm_file->mapping is NULL. Somebody freed ->vm_file from
under us?
I suspect Davidlohr's patchset on i_mmap_lock, but I cannot find any code
path which could lead to the crash.
I've noticed one strange code path, which probably is not related to the
issue:
unmap_mapping_range()
i_mmap_lock_read(mapping);
unmap_mapping_range_tree()
unmap_mapping_range_vma()
zap_page_range_single()
unmap_single_vma()
if (unlikely(is_vm_hugetlb_page(vma))) {
i_mmap_lock_write(vma->vm_file->f_mapping);
Is it legal to down_write() semaphore while we have it taken on read?
It must be the same mapping, right?
> [ 432.380085] PGD 57e5e0067 PUD 57e5e1067 PMD 0
> [ 432.380085] Oops: 0002 [#1] PREEMPT SMP KASAN
> [ 432.380085] Dumping ftrace buffer:
> [ 432.380085] (ftrace buffer empty)
> [ 432.380085] Modules linked in:
> [ 432.380085] CPU: 4 PID: 9249 Comm: trinity-subchil Not tainted 3.18.0-next-20141219-sasha-00047-gaab33f6-dirty #1627
> [ 432.380085] task: ffff8806a88c8000 ti: ffff880664f3c000 task.ti: ffff880664f3c000
> [ 432.380085] RIP: down_write (./arch/x86/include/asm/rwsem.h:105 ./arch/x86/include/asm/rwsem.h:121 kernel/locking/rwsem.c:71)
> [ 432.380085] RSP: 0018:ffff880664f3fc98 EFLAGS: 00010292
> [ 432.380085] RAX: 0000000000000038 RBX: ffff880101aa7c00 RCX: 1ffff10020354f8f
> [ 432.380085] RDX: ffffffff00000001 RSI: 1ffff100fe326200 RDI: 0000000000000038
> [ 432.380085] RBP: ffff880664f3fcb8 R08: 0000000000000000 R09: ffff880101aa6258
> [ 432.380085] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880000025900
> [ 432.380085] R13: 0000000000000038 R14: 0000000000000000 R15: ffff880101aa7c00
> [ 432.380085] FS: 00007f21149c4700(0000) GS:ffff880216400000(0000) knlGS:0000000000000000
> [ 432.380085] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 432.380085] CR2: 0000000000000038 CR3: 000000057a4f3000 CR4: 00000000000006a0
> [ 432.380085] Stack:
> [ 432.380085] ffff880101aa7c00 ffff880101aa7c78 ffff880101aa6200 ffff880101aa7c00
> [ 432.380085] ffff880664f3fce8 ffffffffa1953e9d[ 432.400920] CONFIG_KASAN_INLINE enabled
> [ 432.400923] GPF could be caused by NULL-ptr deref or user memory access
>
> [ 432.402566] ffff880101aa7c00 00007f210f9f3000
> [ 432.402566] dfffe90000000000 ffff880101aa4600 ffff880664f3fd48 ffffffffa1937821
> [ 432.402566] Call Trace:
> [ 432.402566] unlink_file_vma (mm/mmap.c:264)
> [ 432.402566] free_pgtables (mm/memory.c:548)
> [ 432.402566] exit_mmap (mm/mmap.c:2846)
> [ 432.402566] ? kmem_cache_free (mm/slub.c:2712 mm/slub.c:2721)
> [ 432.402566] mmput (kernel/fork.c:659)
> [ 432.402566] do_exit (./arch/x86/include/asm/thread_info.h:164 kernel/exit.c:438 kernel/exit.c:732)
> [ 432.402566] ? preempt_count_sub (kernel/sched/core.c:2620)
> [ 432.402566] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
> [ 432.402566] do_group_exit (include/linux/sched.h:775 kernel/exit.c:858)
> [ 432.402566] SyS_exit_group (kernel/exit.c:886)
> [ 432.402566] system_call_fastpath (arch/x86/kernel/entry_64.S:423)
> [ 432.402566] Code: 79 05 e8 f9 e9 a6 f2 5d c3 0f 1f 80 00 00 00 00 66 66 66 66 90 48 ba 01 00 00 00 ff ff ff ff 55 48 89 f8 48 89 e5 53 48 83 ec 18 <f0> 48 0f c1 10 85 d2 74 05 e8 f7 e9 a6 f2 65 48 8b 1c 25 80 b9
> All code
> ========
> 0: 79 05 jns 0x7
> 2: e8 f9 e9 a6 f2 callq 0xfffffffff2a6ea00
> 7: 5d pop %rbp
> 8: c3 retq
> 9: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
> 10: 66 66 66 66 90 data32 data32 data32 xchg %ax,%ax
> 15: 48 ba 01 00 00 00 ff movabs $0xffffffff00000001,%rdx
> 1c: ff ff ff
> 1f: 55 push %rbp
> 20: 48 89 f8 mov %rdi,%rax
> 23: 48 89 e5 mov %rsp,%rbp
> 26: 53 push %rbx
> 27: 48 83 ec 18 sub $0x18,%rsp
> 2b:* f0 48 0f c1 10 lock xadd %rdx,(%rax) <-- trapping instruction
> 30: 85 d2 test %edx,%edx
> 32: 74 05 je 0x39
> 34: e8 f7 e9 a6 f2 callq 0xfffffffff2a6ea30
> 39: 65 gs
> 3a: 48 rex.W
> 3b: 8b .byte 0x8b
> 3c: 1c 25 sbb $0x25,%al
> 3e: 80 .byte 0x80
> 3f: b9 .byte 0xb9
> ...
>
> Code starting with the faulting instruction
> ===========================================
> 0: f0 48 0f c1 10 lock xadd %rdx,(%rax)
> 5: 85 d2 test %edx,%edx
> 7: 74 05 je 0xe
> 9: e8 f7 e9 a6 f2 callq 0xfffffffff2a6ea05
> e: 65 gs
> f: 48 rex.W
> 10: 8b .byte 0x8b
> 11: 1c 25 sbb $0x25,%al
> 13: 80 .byte 0x80
> 14: b9 .byte 0xb9
> ...
> [ 432.402566] RIP down_write (./arch/x86/include/asm/rwsem.h:105 ./arch/x86/include/asm/rwsem.h:121 kernel/locking/rwsem.c:71)
> [ 432.402566] RSP <ffff880664f3fc98>
> [ 432.402566] CR2: 0000000000000038
>
>
> Thanks,
> Sasha
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Kirill A. Shutemov
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Sasha Levin <sasha.levin@oracle.com>, Davidlohr Bueso <davidlohr@hp.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Jones <davej@redhat.com>
Subject: Re: mm: NULL ptr deref in unlink_file_vma
Date: Mon, 22 Dec 2014 20:01:02 +0200 [thread overview]
Message-ID: <20141222180102.GA8072@node.dhcp.inet.fi> (raw)
In-Reply-To: <549832E2.8060609@oracle.com>
On Mon, Dec 22, 2014 at 10:04:02AM -0500, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest running the latest -next
> kernel, I've stumbled on the following spew:
>
> [ 432.376425] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
> [ 432.378876] IP: down_write (./arch/x86/include/asm/rwsem.h:105 ./arch/x86/include/asm/rwsem.h:121 kernel/locking/rwsem.c:71)
Looks like vma->vm_file->mapping is NULL. Somebody freed ->vm_file from
under us?
I suspect Davidlohr's patchset on i_mmap_lock, but I cannot find any code
path which could lead to the crash.
I've noticed one strange code path, which probably is not related to the
issue:
unmap_mapping_range()
i_mmap_lock_read(mapping);
unmap_mapping_range_tree()
unmap_mapping_range_vma()
zap_page_range_single()
unmap_single_vma()
if (unlikely(is_vm_hugetlb_page(vma))) {
i_mmap_lock_write(vma->vm_file->f_mapping);
Is it legal to down_write() semaphore while we have it taken on read?
It must be the same mapping, right?
> [ 432.380085] PGD 57e5e0067 PUD 57e5e1067 PMD 0
> [ 432.380085] Oops: 0002 [#1] PREEMPT SMP KASAN
> [ 432.380085] Dumping ftrace buffer:
> [ 432.380085] (ftrace buffer empty)
> [ 432.380085] Modules linked in:
> [ 432.380085] CPU: 4 PID: 9249 Comm: trinity-subchil Not tainted 3.18.0-next-20141219-sasha-00047-gaab33f6-dirty #1627
> [ 432.380085] task: ffff8806a88c8000 ti: ffff880664f3c000 task.ti: ffff880664f3c000
> [ 432.380085] RIP: down_write (./arch/x86/include/asm/rwsem.h:105 ./arch/x86/include/asm/rwsem.h:121 kernel/locking/rwsem.c:71)
> [ 432.380085] RSP: 0018:ffff880664f3fc98 EFLAGS: 00010292
> [ 432.380085] RAX: 0000000000000038 RBX: ffff880101aa7c00 RCX: 1ffff10020354f8f
> [ 432.380085] RDX: ffffffff00000001 RSI: 1ffff100fe326200 RDI: 0000000000000038
> [ 432.380085] RBP: ffff880664f3fcb8 R08: 0000000000000000 R09: ffff880101aa6258
> [ 432.380085] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880000025900
> [ 432.380085] R13: 0000000000000038 R14: 0000000000000000 R15: ffff880101aa7c00
> [ 432.380085] FS: 00007f21149c4700(0000) GS:ffff880216400000(0000) knlGS:0000000000000000
> [ 432.380085] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 432.380085] CR2: 0000000000000038 CR3: 000000057a4f3000 CR4: 00000000000006a0
> [ 432.380085] Stack:
> [ 432.380085] ffff880101aa7c00 ffff880101aa7c78 ffff880101aa6200 ffff880101aa7c00
> [ 432.380085] ffff880664f3fce8 ffffffffa1953e9d[ 432.400920] CONFIG_KASAN_INLINE enabled
> [ 432.400923] GPF could be caused by NULL-ptr deref or user memory access
>
> [ 432.402566] ffff880101aa7c00 00007f210f9f3000
> [ 432.402566] dfffe90000000000 ffff880101aa4600 ffff880664f3fd48 ffffffffa1937821
> [ 432.402566] Call Trace:
> [ 432.402566] unlink_file_vma (mm/mmap.c:264)
> [ 432.402566] free_pgtables (mm/memory.c:548)
> [ 432.402566] exit_mmap (mm/mmap.c:2846)
> [ 432.402566] ? kmem_cache_free (mm/slub.c:2712 mm/slub.c:2721)
> [ 432.402566] mmput (kernel/fork.c:659)
> [ 432.402566] do_exit (./arch/x86/include/asm/thread_info.h:164 kernel/exit.c:438 kernel/exit.c:732)
> [ 432.402566] ? preempt_count_sub (kernel/sched/core.c:2620)
> [ 432.402566] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
> [ 432.402566] do_group_exit (include/linux/sched.h:775 kernel/exit.c:858)
> [ 432.402566] SyS_exit_group (kernel/exit.c:886)
> [ 432.402566] system_call_fastpath (arch/x86/kernel/entry_64.S:423)
> [ 432.402566] Code: 79 05 e8 f9 e9 a6 f2 5d c3 0f 1f 80 00 00 00 00 66 66 66 66 90 48 ba 01 00 00 00 ff ff ff ff 55 48 89 f8 48 89 e5 53 48 83 ec 18 <f0> 48 0f c1 10 85 d2 74 05 e8 f7 e9 a6 f2 65 48 8b 1c 25 80 b9
> All code
> ========
> 0: 79 05 jns 0x7
> 2: e8 f9 e9 a6 f2 callq 0xfffffffff2a6ea00
> 7: 5d pop %rbp
> 8: c3 retq
> 9: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
> 10: 66 66 66 66 90 data32 data32 data32 xchg %ax,%ax
> 15: 48 ba 01 00 00 00 ff movabs $0xffffffff00000001,%rdx
> 1c: ff ff ff
> 1f: 55 push %rbp
> 20: 48 89 f8 mov %rdi,%rax
> 23: 48 89 e5 mov %rsp,%rbp
> 26: 53 push %rbx
> 27: 48 83 ec 18 sub $0x18,%rsp
> 2b:* f0 48 0f c1 10 lock xadd %rdx,(%rax) <-- trapping instruction
> 30: 85 d2 test %edx,%edx
> 32: 74 05 je 0x39
> 34: e8 f7 e9 a6 f2 callq 0xfffffffff2a6ea30
> 39: 65 gs
> 3a: 48 rex.W
> 3b: 8b .byte 0x8b
> 3c: 1c 25 sbb $0x25,%al
> 3e: 80 .byte 0x80
> 3f: b9 .byte 0xb9
> ...
>
> Code starting with the faulting instruction
> ===========================================
> 0: f0 48 0f c1 10 lock xadd %rdx,(%rax)
> 5: 85 d2 test %edx,%edx
> 7: 74 05 je 0xe
> 9: e8 f7 e9 a6 f2 callq 0xfffffffff2a6ea05
> e: 65 gs
> f: 48 rex.W
> 10: 8b .byte 0x8b
> 11: 1c 25 sbb $0x25,%al
> 13: 80 .byte 0x80
> 14: b9 .byte 0xb9
> ...
> [ 432.402566] RIP down_write (./arch/x86/include/asm/rwsem.h:105 ./arch/x86/include/asm/rwsem.h:121 kernel/locking/rwsem.c:71)
> [ 432.402566] RSP <ffff880664f3fc98>
> [ 432.402566] CR2: 0000000000000038
>
>
> Thanks,
> Sasha
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Kirill A. Shutemov
next prev parent reply other threads:[~2014-12-22 18:01 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-22 15:04 mm: NULL ptr deref in unlink_file_vma Sasha Levin
2014-12-22 15:04 ` Sasha Levin
2014-12-22 18:01 ` Kirill A. Shutemov [this message]
2014-12-22 18:01 ` Kirill A. Shutemov
2014-12-22 18:04 ` Kirill A. Shutemov
2014-12-22 18:04 ` Kirill A. Shutemov
2014-12-22 19:04 ` Davidlohr Bueso
2014-12-22 19:04 ` Davidlohr Bueso
2014-12-22 20:38 ` Sasha Levin
2014-12-22 20:38 ` Sasha Levin
2014-12-22 18:05 ` Sasha Levin
2014-12-22 18:05 ` Sasha Levin
2014-12-22 19:14 ` Kirill A. Shutemov
2014-12-22 19:14 ` Kirill A. Shutemov
2014-12-22 22:12 ` Davidlohr Bueso
2014-12-22 22:12 ` Davidlohr Bueso
2015-02-10 18:42 ` Konstantin Khlebnikov
2015-02-10 18:42 ` Konstantin Khlebnikov
2015-02-11 12:22 ` Kirill A. Shutemov
2015-02-11 12:22 ` Kirill A. Shutemov
2015-02-12 13:42 ` Konstantin Khlebnikov
2015-02-12 13:42 ` Konstantin Khlebnikov
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=20141222180102.GA8072@node.dhcp.inet.fi \
--to=kirill@shutemov.name \
--cc=akpm@linux-foundation.org \
--cc=davej@redhat.com \
--cc=davidlohr@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sasha.levin@oracle.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 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.