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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <w2n412e6f7f1004050223j3e15df91tcdf133670c636a85@mail.gmail.com>
Date:	Mon, 5 Apr 2010 17:23:50 +0800
From:	Changli Gao <xiaosuo@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	neilb@...e.de, shemminger@...tta.com, netdev@...r.kernel.org
Subject: Re: Undefined behaviour of connect(fd, NULL, 0);

On Thu, Apr 1, 2010 at 3:23 PM, David Miller <davem@...emloft.net> wrote:
>
> This seems logical, but I believe it is wrong.
>
> We already know for a fact that it is guarenteed to not work
> reliably for every single kernel in existence in the world
> right now.
>
> Every system.  Ones that have been deployed for 10 years as
> well as those built from GIT 10 seconds ago.
>
> So you tell me, if you put this into an application that you
> wish to deploy anywhere, are you not being completely stupid?
>
> Therefore, if it's illogical to use this in an application, what value
> is there in starting to support it now in the kernel?
>
> I'll tell you, the value is absolutely zero.
>
> Yes we need to add the length check, but the behavior we give to this
> case as a result, is completely arbitrary.  And I would in fact argue
> for a hard error in these cases.
>
> Simply mark it as invalid to call connect() this way.
>

I found this from the man page of FreeBSD's connect(2).

     Generally, stream sockets may successfully connect() only
     once; datagram sockets may use connect() multiple times to change their
     association.  Datagram sockets may dissolve the association by connecting
     to an invalid address, such as a null address.

And this from the man page of Darwin's connect(2).

     Datagram sockets may dissolve the association by connecting to an
     invalid address, such as a null address or an address with the address
     family set to AF_UNSPEC (the error EAFNOSUPPORT will be harmlessly
     returned).

Since null address behavior has been defined by the others. I think
Linux should be compatible with the others. So the  patch submitted on
this by me should not been applied. I'll work out another patch later.

-- 
Regards,
Changli Gao(xiaosuo@...il.com)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ