| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 24 Jun 2015 23:54:56 +0000 (UTC) From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Thomas Gleixner <tglx@...utronix.de>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>, the arch/x86 maintainers <x86@...nel.org> Subject: Re: [RFC PATCH] Fix: x86 unaligned __memcpy to/from virtual memory ----- On Jun 24, 2015, at 3:15 PM, Linus Torvalds torvalds@...ux-foundation.org wrote: > On Wed, Jun 24, 2015 at 11:49 AM, Mathieu Desnoyers > <mathieu.desnoyers@...icios.com> wrote: >> >> Here is the output. I added the printk just after the initial range >> check within vmalloc_fault. > > Good. Can you add printk's to the error return paths too, so that we > see which one it is that triggers. OK, see below. This time the fault occurred at an unaligned address. It fails on the !pte_present(*pte_ref) check. > > If it is a valid vmalloc address, then vmalloc_fault() _should_ just > fix it up and return 0. Clearly it doesn't, and hits one of the > "return -1" cases instead. > > In particular, that > > pgd_ref = pgd_offset_k(address); > > should return the reference page table pointer for init_mm, which is > what vmalloc() itself *should* be populating. > > The fact that it sounds like one of the "pud/pmd/pte_none()" checks > for the reference ends up returning true, seems to indicate that the > page tables haven't been filled in even for the reference address. > Which is really really odd. > > I'm really inclined to think that it's something in lttng, because > it's so odd. A race with vunmap() on another CPU? How could > vmalloc_fault() not see the reference page table contents? [ 69.719102] DEBUG: vmalloc_fault at address 0xffffc900077e0f3b [ 69.720216] DEBUG: !pte_present(*pte_ref) error [ 69.720216] BUG: unable to handle kernel paging request at ffffc900077e0f3b [ 69.720216] IP: [<ffffffff81316f72>] __memcpy+0x12/0x20 [ 69.720216] PGD 236c92067 PUD 236c93067 PMD 22cc87067 PTE 0 [ 69.720216] Oops: 0000 [#1] SMP [ 69.720216] Modules linked in: lttng_probe_workqueue(O) lttng_probe_vmscan(O) lttng_probe_udp(O) lttng_probe_timer(O) lttng_probe_sunrpc(O) lttng_probe_statedump(O) lttng_probe_sock(O) lttng_probe_skb(O) lttng_probe_signal(O) lttng_probe_scsi(O) lttng_probe_sched(O) lttng_probe_regmap(O) lttng_probe_rcu(O) lttng_probe_random(O) lttng_probe_power(O) lttng_probe_net(O) lttng_probe_napi(O) lttng_probe_module(O) lttng_probe_kmem(O) lttng_probe_jbd2(O) lttng_probe_irq(O) lttng_probe_ext4(O) lttng_probe_compaction(O) lttng_probe_block(O) lttng_types(O) lttng_ring_buffer_metadata_mmap_client(O) lttng_ring_buffer_client_mmap_overwrite(O) lttng_ring_buffer_client_mmap_discard(O) lttng_ring_buffer_metadata_client(O) lttng_ring_buffer_client_overwrite(O) lttng_ring_buffer_client_discard(O) lttng_tracer(O) lttng_statedump(O) lttng_kprobes(O) lttng_lib_ring_buffer(O) lttng_kretprobes(O) virtio_net virtio_blk virtio_pci virtio_ring virtio [last unloaded: lttng_statedump] [ 69.720216] CPU: 12 PID: 3536 Comm: lttng-consumerd Tainted: G O 4.1.0+ #11 [ 69.720216] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [ 69.720216] task: ffff8800bab3b660 ti: ffff88023344c000 task.ti: ffff88023344c000 [ 69.720216] RIP: 0010:[<ffffffff81316f72>] [<ffffffff81316f72>] __memcpy+0x12/0x20 [ 69.720216] RSP: 0018:ffff88023344fda0 EFLAGS: 00010246 [ 69.720216] RAX: ffff880233135025 RBX: 0000000000000fd8 RCX: 00000000000001fb [ 69.720216] RDX: 0000000000000000 RSI: ffffc900077e0f3b RDI: ffff880233135025 [ 69.720216] RBP: ffff88023344fdb8 R08: ffff880037ae3a00 R09: 0000000000005000 [ 69.720216] R10: 0000000000000000 R11: 0000000000000246 R12: ffff88023344fdc8 [ 69.720216] R13: ffff8800bb33f000 R14: 0000000000000fd8 R15: 0000000000000fd8 [ 69.720216] FS: 00007fb2d28ae700(0000) GS:ffff880237380000(0000) knlGS:0000000000000000 [ 69.720216] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 69.720216] CR2: ffffc900077e0f3b CR3: 000000023329d000 CR4: 00000000000006e0 [ 69.720216] Stack: [ 69.720216] ffffffffa05a6797 ffff88023527ad00 ffff88023527ad50 ffff88023344fe48 [ 69.720216] ffffffffa046d060 ffff8800bb33f000 0000000000000000 0000000000000fd8 [ 69.720216] ffffffff00000001 ffff880037ae3a00 0000000000000fd8 0000000000005025 [ 69.720216] Call Trace: [ 69.720216] [<ffffffffa05a6797>] ? lttng_event_write+0x87/0xb0 [lttng_ring_buffer_metadata_client] [ 69.720216] [<ffffffffa046d060>] lttng_metadata_output_channel+0xd0/0x120 [lttng_tracer] [ 69.720216] [<ffffffffa046f5f9>] lttng_metadata_ring_buffer_ioctl+0x79/0xd0 [lttng_tracer] [ 69.720216] [<ffffffff8117ba70>] do_vfs_ioctl+0x2e0/0x4e0 [ 69.720216] [<ffffffff812b3627>] ? file_has_perm+0x87/0xa0 [ 69.720216] [<ffffffff8117bcf1>] SyS_ioctl+0x81/0xa0 [ 69.720216] [<ffffffff810115d1>] ? syscall_trace_leave+0xd1/0xe0 [ 69.720216] [<ffffffff818bbdb7>] tracesys_phase2+0x84/0x89 [ 69.720216] Code: 5b 5d c3 66 0f 1f 44 00 00 e8 6b fc ff ff eb e1 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 <f3> 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 [ 69.720216] RIP [<ffffffff81316f72>] __memcpy+0x12/0x20 [ 69.720216] RSP <ffff88023344fda0> [ 69.720216] CR2: ffffc900077e0f3b [ 69.720216] ---[ end trace c35549bf8e0386a2 ]--- -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists