udp bind & udp_port_rover behavior

[Marc de la Gueronniere]

Hi,

I came across strange problems while porting an udp-based application.
These problems originated from very weak assumptions (no source ip/port
checking, no stream ID,...) in this application. These weaknesses are
exposed by the behavior of the udp_port_rover/udp_v4_get_port mechanism
i.e. udp_port_rover is not incremented after allocation which can cause
the immediate reallocation of a port that was just freed causing
potentially the reception of packets that were not meant for the
application opening the new port. While there is no doubt in my mind
that the application is clearly at fault, incrementing the rover feels
like a safer behavior. If a port is immediately reused this will cause:
-ICMP port unreachable message to not be sent, while the old receiving
end has died.
-any UDP applications not doing source checking to likely receive random
packets, triggering weird bugs that did not happen on other platforms.

Marc

PS: please CC me directly as I am not currently subscribed to the list.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/