graphic: 0.902
semantic: 0.898
virtual: 0.896
hypervisor: 0.889
user-level: 0.888
permissions: 0.882
peripherals: 0.877
mistranslation: 0.877
performance: 0.870
arm: 0.855
assembly: 0.851
risc-v: 0.850
architecture: 0.848
socket: 0.847
register: 0.844
device: 0.839
debug: 0.835
PID: 0.829
kernel: 0.828
ppc: 0.819
boot: 0.815
TCG: 0.810
vnc: 0.803
x86: 0.766
KVM: 0.758
network: 0.756
VMM: 0.737
files: 0.735
i386: 0.559

Socket leak on each call to qemu_socket()

On any host platform where SOCK_CLOEXEC is defined (Linux at least), a socket is leaked on each call to qemu_socket() AND the socket returned hasn't been created with the desired SOCK_CLOEXEC attribute.  The qemu_socket routine is:

Line 272 of util/osdep.c:
/*
 * Opens a socket with FD_CLOEXEC set
 */
int qemu_socket(int domain, int type, int protocol)
{
    int ret;

#ifdef SOCK_CLOEXEC
    ret = socket(domain, type | SOCK_CLOEXEC, protocol);
    if (ret != -1 || errno != EINVAL) {
        return ret;
    }
#endif
    ret = socket(domain, type, protocol);
    if (ret >= 0) {
        qemu_set_cloexec(ret);
    }

    return ret;
}

I'm not sure that my original report was distributed to the folks who need to see this.  My primary email address has a DKIM policy (DMARC) which says that all messages from my address are signed.  I received various DMARC reports which said that the bug report sent as "From: <email address hidden>" were rejected.  The bug report messages were reasonably sent with an SMTP envelope from of <email address hidden> and a "Sender: <email address hidden>".  Hmm... Maybe 163.com is rewriting message headers.  In any case, the message would have passed the DMARC check if my email address was in a "Reply-To: <email address hidden>" header (there was no Reply-To: header), and the "From:" header was a @nongnu.org address.

I have changed my account to use my users.sourceforge.com forwarding address and I'm now generating this comment so that hopefully, the whole message will be widely distributed with a from address which doesn't have the same DMARC policy.

On Sunday, October 11, 2015 at 11:58 PM. Markus Armbruster wrote:
> Mark Pizzolato <email address hidden> writes:
> 
> > Public bug reported:
> >
> > On any host platform where SOCK_CLOEXEC is defined (Linux at least), a
> > socket is leaked on each call to qemu_socket() AND the socket returned
> > hasn't been created with the desired SOCK_CLOEXEC attribute.  The
> > qemu_socket routine is:
> >
> > Line 272 of util/osdep.c:
> > /*
> >  * Opens a socket with FD_CLOEXEC set
> >  */
> > int qemu_socket(int domain, int type, int protocol)
> > {
> >     int ret;
> >
> > #ifdef SOCK_CLOEXEC
> >     ret = socket(domain, type | SOCK_CLOEXEC, protocol);
> >     if (ret != -1 || errno != EINVAL) {
> >         return ret;
> 
> If socket() succeeded (ret != -1), we return the socket.
> 
> If socket() failed with anything but EINVAL (ret == -1 && errno !=
> EINVAL), we return -1 with errno set.
> 
> >     }
> 
> Here, ret == -1 && errno == EINVAL.
> 
> > #endif
> >     ret = socket(domain, type, protocol);
> >     if (ret >= 0) {
> >         qemu_set_cloexec(ret);
> >     }
> >
> >     return ret;
> > }
> 
> How can this leak a socket?
> 
> How can this return a socket with FD_CLOEXEC not set?

All I can say is "OOPS!!"  Sorry for bothering you.  I misread the status check after the first socket() call.

I'm in the process of lifting qemu's slirp code and dropping it into another open source project.  Since I'm trying to use all the code in the slirp directory without modification I'm digging through where it now depends on other qemu code.  I quickly looked at the qemu_socket() routine and read it wrong.

Once again, sorry.

- Mark Pizzolato