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
| ||
|
Message-ID: <4CBEC30E.2040407@iki.fi> Date: Wed, 20 Oct 2010 13:23:10 +0300 From: Timo Teräs <timo.teras@....fi> To: netdev@...r.kernel.org Subject: Why RTM_NEWADDR is sent before FIB update? Hi, I'm wonder why does devinet.c:__inet_insert_ifa() (and other places) send first the RTM_NEWADDR notification and only after that calls inetaddr_chain notifiers? The reason I'm asking that this gives a race condition to user land: 1. process A changes IP address 2. kernel sends RTM_NEWADDR 3. process B gets notification 4. process B tries to bind() to new IP but that fails with EADDRNOTAVAIL because FIB is not yet updated and inet_addr_type() in inet_bind() does not recognize the IP as local 5. kernel calls inetaddr_chain notifiers which updates FIB My understanding was that RTM_NEWADDR was notification about new address being usable. But it's currently a notification about "new address will be usable soon". So should we: a) call first notifiers and after that send RTM_NEWADDR? b) synchronise inet_bind() with address changes somehow? c) live with the bad semantics of the notification in userland d) ?? - Timo -- 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