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
| ||
|
Date: Thu, 01 Apr 2010 00:23:19 -0700 (PDT) From: David Miller <davem@...emloft.net> To: xiaosuo@...il.com Cc: neilb@...e.de, shemminger@...tta.com, netdev@...r.kernel.org Subject: Re: Undefined behaviour of connect(fd, NULL, 0); From: Changli Gao <xiaosuo@...il.com> Date: Thu, 1 Apr 2010 12:16:43 +0800 > Someone may use connect() to check if the connection is established > or not. But there is no spec about the addr and addr_len value when > connect(2) is used this way. Since there is no limit of addr and > addr_len, and we supports addr is NULL to check the status of socket > (Although it is buggy). I think we should treat it like a feature, > and the problem Neil reported is a bug. 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. -- 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