Memory modified after free in "MAP ENTRY" zone (vm_map_entry_t->read_ahead)

From: Andriy Gapon <avg_at_FreeBSD.org>
Date: Wed, 10 Feb 2016 23:28:14 +0200
Over a span of approximately 3 weeks I have got two slightly different panics of
the same kind.   The affected system is a several months old amd64 head.

======================== 1 ===========================================
Unread portion of the kernel message buffer:
panic: Memory modified after free 0xfffff8008c15ac80(128) val=adc0de _at_
0xfffff8008c15acdc

KDB: stack backtrace:
db_trace_self_wrapper() at 0xffffffff8041e90b = db_trace_self_wrapper+0x2b/frame
0xfffffe04f5349530
kdb_backtrace() at 0xffffffff80669a09 = kdb_backtrace+0x39/frame 0xfffffe04f53495e0
vpanic() at 0xffffffff80634dec = vpanic+0x14c/frame 0xfffffe04f5349620
panic() at 0xffffffff80634b33 = panic+0x43/frame 0xfffffe04f5349680
trash_ctor() at 0xffffffff807de9c8 = trash_ctor+0x48/frame 0xfffffe04f5349690
uma_zalloc_arg() at 0xffffffff807da785 = uma_zalloc_arg+0x475/frame
0xfffffe04f5349720
uma_zalloc() at 0xffffffff807e44af = uma_zalloc+0xf/frame 0xfffffe04f5349730
vm_map_entry_create() at 0xffffffff807e5a2e = vm_map_entry_create+0x2e/frame
0xfffffe04f5349740
_vm_map_clip_start() at 0xffffffff807e69e3 = _vm_map_clip_start+0x123/frame
0xfffffe04f5349770
vm_map_wire() at 0xffffffff807e797d = vm_map_wire+0x11d/frame 0xfffffe04f53497f0
vslock() at 0xffffffff807e1a2b = vslock+0x6b/frame 0xfffffe04f5349810
sysctl_wire_old_buffer() at 0xffffffff8064148a =
sysctl_wire_old_buffer+0x4a/frame 0xfffffe04f5349830
sysctl_kern_proc() at 0xffffffff8062259b = sysctl_kern_proc+0x8b/frame
0xfffffe04f5349880
sysctl_root_handler_locked() at 0xffffffff80641a8e =
sysctl_root_handler_locked+0x8e/frame 0xfffffe04f53498c0
sysctl_root() at 0xffffffff806412fe = sysctl_root+0x13e/frame 0xfffffe04f5349940
userland_sysctl() at 0xffffffff8064183d = userland_sysctl+0x16d/frame
0xfffffe04f53499e0
sys___sysctl() at 0xffffffff80641694 = sys___sysctl+0x74/frame 0xfffffe04f5349a90
syscallenter() at 0xffffffff8081fa20 = syscallenter+0x320/frame 0xfffffe04f5349b00
amd64_syscall() at 0xffffffff8081f5ef = amd64_syscall+0x1f/frame 0xfffffe04f5349bf0
Xfast_syscall() at 0xffffffff80807c5b = Xfast_syscall+0xfb/frame 0xfffffe04f5349bf0
--- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x8042225ea, rsp =
0x7fffffffcef8, rbp = 0x7fffffffcf30 ---
Uptime: 14d22h38m17s
======================================================================

======================== 2 ===========================================
Unread portion of the kernel message buffer:
panic: Memory modified after free 0xfffff80176692680(128) val=adc0de _at_
0xfffff801766926dc

KDB: stack backtrace:
db_trace_self_wrapper() at 0xffffffff8041e90b = db_trace_self_wrapper+0x2b/frame
0xfffffe04f507c5a0
kdb_backtrace() at 0xffffffff80669a09 = kdb_backtrace+0x39/frame 0xfffffe04f507c650
vpanic() at 0xffffffff80634dec = vpanic+0x14c/frame 0xfffffe04f507c690
panic() at 0xffffffff80634b33 = panic+0x43/frame 0xfffffe04f507c6f0
trash_ctor() at 0xffffffff807de9c8 = trash_ctor+0x48/frame 0xfffffe04f507c700
uma_zalloc_arg() at 0xffffffff807da785 = uma_zalloc_arg+0x475/frame
0xfffffe04f507c790
uma_zalloc() at 0xffffffff807e44af = uma_zalloc+0xf/frame 0xfffffe04f507c7a0
vm_map_entry_create() at 0xffffffff807e5a2e = vm_map_entry_create+0x2e/frame
0xfffffe04f507c7b0
vm_map_insert() at 0xffffffff807e558a = vm_map_insert+0x2fa/frame 0xfffffe04f507c850
vm_map_stack_locked() at 0xffffffff807e63cb = vm_map_stack_locked+0x13b/frame
0xfffffe04f507c8b0
vm_map_find() at 0xffffffff807e65d3 = vm_map_find+0x183/frame 0xfffffe04f507c950
vm_mmap_object() at 0xffffffff807eac99 = vm_mmap_object+0x329/frame
0xfffffe04f507c9d0
sys_mmap() at 0xffffffff807ea8ec = sys_mmap+0x41c/frame 0xfffffe04f507ca90
syscallenter() at 0xffffffff8081fa20 = syscallenter+0x320/frame 0xfffffe04f507cb00
amd64_syscall() at 0xffffffff8081f5ef = amd64_syscall+0x1f/frame 0xfffffe04f507cbf0
Xfast_syscall() at 0xffffffff80807c5b = Xfast_syscall+0xfb/frame 0xfffffe04f507cbf0
--- syscall (477, FreeBSD ELF64, sys_mmap), rip = 0x80418776a, rsp =
0x7fffffffb808, rbp = 0x7fffffffb840 ---
Uptime: 4d4h36m36s
======================================================================

I have crash dumps from both panics.
It seems that it was read_ahead field that was reset to zero in both cases.
Perhaps the issue has been fixed already?
I would appreciate any suggestions. Thanks!

-- 
Andriy Gapon
Received on Wed Feb 10 2016 - 20:32:06 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:02 UTC