Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1700646
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [GIT PULL] Please pull NFS client changes for Linux 4.13 |
| Date | 2017-08-01 07:40 +0200 |
| Message-ID | <u9y4p-7Cw-1@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <u3Z7l-4i4-41@gated-at.bofh.it> <u40G6-58Y-13@gated-at.bofh.it> <u44A4-7UE-21@gated-at.bofh.it> <u4jz4-zE-11@gated-at.bofh.it> <u9l7b-82B-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Mon, Jul 31, 2017 at 8:43 AM, davej@codemonkey.org.uk
<davej@codemonkey.org.uk> wrote:
> Another NFSv4 KASAN splat, this time from rc3.
>
> BUG: KASAN: use-after-free in nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4]
Ugh. It's really hard to tell what access that it - KASAN doesn't
actually give enough information. There's lots of 8-byte accesses
there in that function.
Any chance of getting the output from
./scripts/faddr2line vmlinux nfs4_exchange_id_done+0x3d7/0x8e0
or something? That would be extremely useful in general for
stacktraces, but it's doubly useful for KASAN because most *other*
stacktraces tend to have a very limited number of things that can warn
(ie there's one or two WARN_ON() calls in a function), but KASAN can
have tens or hundreds..
Linus
> Read of size 8 at addr ffff8804508af528 by task kworker/2:1/34
>
> CPU: 2 PID: 34 Comm: kworker/2:1 Not tainted 4.13.0-rc3-think+ #1
> Workqueue: rpciod rpc_async_schedule [sunrpc]
> Call Trace:
> dump_stack+0x68/0xa1
> print_address_description+0xd9/0x270
> kasan_report+0x257/0x370
> ? nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4]
> check_memory_region+0x13a/0x1a0
> __asan_loadN+0xf/0x20
> nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4]
> ? nfs4_exchange_id_release+0xb0/0xb0 [nfsv4]
> rpc_exit_task+0x69/0x110 [sunrpc]
> ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc]
> ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc]
> __rpc_execute+0x1a0/0x840 [sunrpc]
> ? rpc_wake_up_queued_task+0x50/0x50 [sunrpc]
> ? __lock_is_held+0x9a/0x100
> ? debug_lockdep_rcu_enabled.part.16+0x1a/0x30
> rpc_async_schedule+0x12/0x20 [sunrpc]
> process_one_work+0x4d5/0xa70
> ? flush_delayed_work+0x70/0x70
> ? lock_acquire+0xfc/0x220
> worker_thread+0x88/0x630
> ? pci_mmcfg_check_reserved+0xc0/0xc0
> kthread+0x1a6/0x1f0
> ? process_one_work+0xa70/0xa70
> ? kthread_create_on_node+0xc0/0xc0
> ret_from_fork+0x27/0x40
>
> Allocated by task 1:
> save_stack_trace+0x1b/0x20
> save_stack+0x46/0xd0
> kasan_kmalloc+0xad/0xe0
> kasan_slab_alloc+0x12/0x20
> kmem_cache_alloc+0xe0/0x2f0
> getname_flags+0x43/0x220
> getname+0x12/0x20
> do_sys_open+0x14c/0x2b0
> SyS_open+0x1e/0x20
> do_syscall_64+0xea/0x260
> return_from_SYSCALL_64+0x0/0x7a
>
> Freed by task 1:
> save_stack_trace+0x1b/0x20
> save_stack+0x46/0xd0
> kasan_slab_free+0x72/0xc0
> kmem_cache_free+0xa8/0x300
> putname+0x80/0x90
> do_sys_open+0x22f/0x2b0
> SyS_open+0x1e/0x20
> do_syscall_64+0xea/0x260
> return_from_SYSCALL_64+0x0/0x7a
>
> The buggy address belongs to the object at ffff8804508aeac0\x0a which belongs to the cache names_cache of size 4096
> The buggy address is located 2664 bytes inside of\x0a 4096-byte region [ffff8804508aeac0, ffff8804508afac0)
> The buggy address belongs to the page:
> page:ffffea0011422a00 count:1 mapcount:0 mapping: (null) index:0x0
> [CONT START] compound_mapcount: 0
> flags: 0x8000000000008100(slab|head)
> raw: 8000000000008100 0000000000000000 0000000000000000 0000000100070007
> raw: ffffea00113d6020 ffffea001136e220 ffff8804664f8040 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8804508af400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8804508af480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>ffff8804508af500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff8804508af580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8804508af600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
>
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [GIT PULL] Please pull NFS client changes for Linux 4.13 "davej@codemonkey.org.uk" <davej@codemonkey.org.uk> - 2017-07-31 17:50 +0200
Re: [GIT PULL] Please pull NFS client changes for Linux 4.13 Linus Torvalds <torvalds@linux-foundation.org> - 2017-08-01 07:40 +0200
Re: [GIT PULL] Please pull NFS client changes for Linux 4.13 "davej@codemonkey.org.uk" <davej@codemonkey.org.uk> - 2017-08-01 18:00 +0200
Re: [GIT PULL] Please pull NFS client changes for Linux 4.13 Linus Torvalds <torvalds@linux-foundation.org> - 2017-08-01 19:30 +0200
Re: [GIT PULL] Please pull NFS client changes for Linux 4.13 Trond Myklebust <trondmy@primarydata.com> - 2017-08-01 19:40 +0200
Re: [GIT PULL] Please pull NFS client changes for Linux 4.13 "davej@codemonkey.org.uk" <davej@codemonkey.org.uk> - 2017-08-01 20:00 +0200
Re: [GIT PULL] Please pull NFS client changes for Linux 4.13 Trond Myklebust <trondmy@primarydata.com> - 2017-08-01 20:00 +0200
Re: [GIT PULL] Please pull NFS client changes for Linux 4.13 Linus Torvalds <torvalds@linux-foundation.org> - 2017-08-01 20:00 +0200
csiph-web