[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Crashing in tcp_close
From: |
Samuel Thibault |
Subject: |
Re: [Qemu-devel] Crashing in tcp_close |
Date: |
Sun, 6 Nov 2016 19:04:01 +0100 |
User-agent: |
Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30) |
Hello,
Stefan Hajnoczi, on Fri 04 Nov 2016 11:14:19 +0000, wrote:
> CCing slirp maintainers to get attention on this bug
Thanks!
> > Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
> > 0x00007ffff6a1bb5b in _int_free (av=0x7ffff6d5fb20 <main_arena>,
> > p=<optimised out>, have_lock=0) at malloc.c:4006
> > 4006 malloc.c: No such file or directory.
> > (gdb) bt
> > #0 0x00007ffff6a1bb5b in _int_free (av=0x7ffff6d5fb20 <main_arena>,
> > p=<optimised out>, have_lock=0)
> > at malloc.c:4006
> > #1 0x00007ffff6a1fabc in __GI___libc_free (mem=<optimised out>) at
> > malloc.c:2969
> > #2 0x00005555559a6c0f in tcp_close (address@hidden) at
> > slirp/tcp_subr.c:334
> > #3 0x00005555559a6c8f in tcp_drop (address@hidden,
> > err=<optimised out>) at slirp/tcp_subr.c:298
> > #4 0x00005555559a816b in tcp_timers (timer=<optimised out>,
> > tp=0x555556621ed0) at slirp/tcp_timer.c:179
> > #3 0x00005555559a6c8f in tcp_drop (address@hidden,
> > err=<optimised out>) at slirp/tcp_subr.c:298
> > #4 0x00005555559a816b in tcp_timers (timer=<optimised out>,
> > tp=0x555556621ed0) at slirp/tcp_timer.c:179
> > #5 tcp_slowtimo (address@hidden) at slirp/tcp_timer.c:89
> > * If so, what additional gdb output would you like me to provide?
>
> I wonder if this connection has already been closed/freed before and the
> timer fires shortly afterward. That's just a guess based on the
> backtrace.
That's very unlikely: soclose removes the socket from the list, so
tcp_slowtimo wouldn't be able to find it. That'd rather be a buffer
overflow. But it's hard to believe it could come from the socket
structure since it doesn't contain any buffer.
Brian, could you run it with
export MALLOC_CHECK_=2
and also this could be useful:
export MALLOC_PERTURB_=1234
Also, to rule out the double-free scenario, and try to catch a buffer
overflow coming from the socket structure itself, I have attached a
patch which adds some debugging.
> > * If developers want to reproduce this, let me know and I can probably send
> > the VM qcow2 file and/or packer source privately off-list [I need to check
> > permission for that]
That could be useful.
Samuel
patch
Description: Text document
- Re: [Qemu-devel] Crashing in tcp_close, Stefan Hajnoczi, 2016/11/04
- Re: [Qemu-devel] Crashing in tcp_close,
Samuel Thibault <=
- Re: [Qemu-devel] Crashing in tcp_close, Brian Candler, 2016/11/07
- Re: [Qemu-devel] Crashing in tcp_close, Brian Candler, 2016/11/07
- Re: [Qemu-devel] Crashing in tcp_close, Stefan Hajnoczi, 2016/11/07
- Re: [Qemu-devel] Crashing in tcp_close, Brian Candler, 2016/11/07
- Re: [Qemu-devel] Crashing in tcp_close, Stefan Hajnoczi, 2016/11/07
- Re: [Qemu-devel] Crashing in tcp_close, Brian Candler, 2016/11/07
- Re: [Qemu-devel] Crashing in tcp_close, Stefan Hajnoczi, 2016/11/08
- Re: [Qemu-devel] Crashing in tcp_close, Brian Candler, 2016/11/08
- Re: [Qemu-devel] Crashing in tcp_close, Brian Candler, 2016/11/08
- Re: [Qemu-devel] Crashing in tcp_close, Stefan Hajnoczi, 2016/11/09