qemu-devel
[Top][All Lists]
Advanced

[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

Attachment: patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]