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: Wed, 31 Mar 2010 22:36:37 +1100 From: Neil Brown <neilb@...e.de> To: netdev@...r.kernel.org Subject: Undefined behaviour of connect(fd, NULL, 0); Hi Netdev. We have a customer who was reporting strangely unpredictable behaviour of an in-house application that used networking. It called connect on a non-blocking socket and subsequently called connect(fd, NULL, 0) to check if the connection had succeeded. This would sometime "work" and sometimes close the connection. Looking at the code (sys_connect, move_addr_to_kernel, inet_stream_connect), it seems that in this case an uninitialised on-stack address is passed to inet_stream_connect and it makes a decision based on ->sa_family (which is uninitialised). It seems clear that connect(fd, NULL, 0) is the wrong thing to do in this circumstance, but I think it would be good if it failed consistently rather than unpredictably. Would it be appropriate for move_addr_to_kernel to zero out the remainder of the address? memset(kaddr+ulen, 0, MAX_SOCK_ADDR-ulen); ?? Then connect(fd, NULL, 0) would always break the connection. Thanks, NeilBrown -- 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